[Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Alex Karasulu <ao...@bellsouth.net>]

I am expecting a proposal on how we can implement this feature.  :)

Alex

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Emmanuel Lecharny <el...@gmail.com>]

Stefan Seelmann a écrit :

>Very interesting.
>
>RFC4520 section 3.5 says:
>
>   Options beginning with "x-" are for Private Use and cannot be
>   registered.
>
>So if ADS would accept such private options the user could define
>his/her own options.
>street;x-home
>street;x-work
>
>Regards,
>Stefan
>  
>
Yes. The main pb with x- started options is that they are very server 
specific, and they can't be registred at all.

I think it would be better to use e- options if the user want to have 
it's own options.

Note that we still have two main concerns with this solution :
- I don't know if we support options at all in ADS right now ;)
- We may have an interopability problem with other server and more 
important, with current clients (thunderbird, etc)

I just wanted to express the idea about using those options, because it 
comes at the top of my head, but we have to gather all the pros and 
cons, and also consider performance impact of such a choice (not to 
mention the added complexity of the current search engine ;)

Alos, if the families specification pointed by Ersin cover the needs, 
then this could be seen as a good starting point : if some people have 
spent time and energy to deliver a spec, I think we should not discard 
this effort as useless. (I must admit that I just browsed the doco so 
far ...)

Emmanuel

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Ersin Er <er...@gmail.com>]

Well, I think the X- stuff is used for different purposes. It's for
schema definitions themselves. We are using X-IS-HUMAN-READABLE and
X-SCHEMA extensions in schema element definitions. But I may be
missing something here so I am not talking being sure.

On 1/22/07, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
> Very interesting.
>
> RFC4520 section 3.5 says:
>
>    Options beginning with "x-" are for Private Use and cannot be
>    registered.
>
> So if ADS would accept such private options the user could define
> his/her own options.
> street;x-home
> street;x-work
>
> Regards,
> Stefan
>
>
>
> Enrique Rodriguez schrieb:
> > On 1/21/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> >> Well, I don't know to much about famillies, but I think that we might
> >> workaround the problem of first email, second email, etc by using
> >> attribute descriptions options :
> >>
> >> mail;primary: my.primary.email@apache.org
> >> mail;office: my.office.email@iktek.com
> >
> > Could this technique also be used for multiple attributes that are
> > typically grouped together?  As a specific example, would you do this
> > with addresses, say for a shipping address vs. a secondary shipping
> > address?
> >
> > In RFC 2596 the technique is used for language codes:
> >
> > streetAddress: 1 University Street
> > streetAddress;lang-en: 1 University Street
> > streetAddress;lang-fr: 1 rue Universite
> >
> > Would it make sense to handle shipping address vs. secondary shipping
> > address attributes (from RFC 2256:  X.500 User Schema) this way?
> >
> > street;home: 5 Main St.
> > street;work: 10 Commercial Way
> > ... similarly for st, l, and c (state, locality, and country).
> >
> > Enrique
>
>


-- 
Ersin

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Stefan Seelmann <ma...@stefan-seelmann.de>]

Very interesting.

RFC4520 section 3.5 says:

   Options beginning with "x-" are for Private Use and cannot be
   registered.

So if ADS would accept such private options the user could define
his/her own options.
street;x-home
street;x-work

Regards,
Stefan



Enrique Rodriguez schrieb:
> On 1/21/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
>> Well, I don't know to much about famillies, but I think that we might
>> workaround the problem of first email, second email, etc by using
>> attribute descriptions options :
>>
>> mail;primary: my.primary.email@apache.org
>> mail;office: my.office.email@iktek.com
>
> Could this technique also be used for multiple attributes that are
> typically grouped together?  As a specific example, would you do this
> with addresses, say for a shipping address vs. a secondary shipping
> address?
>
> In RFC 2596 the technique is used for language codes:
>
> streetAddress: 1 University Street
> streetAddress;lang-en: 1 University Street
> streetAddress;lang-fr: 1 rue Universite
>
> Would it make sense to handle shipping address vs. secondary shipping
> address attributes (from RFC 2256:  X.500 User Schema) this way?
>
> street;home: 5 Main St.
> street;work: 10 Commercial Way
> ... similarly for st, l, and c (state, locality, and country).
>
> Enrique

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Ersin Er <er...@gmail.com>]

The thing proposed by Emmanuel is called Contexts in X.500 and they
are only used for language tags in LDAP. (Please correct if I am
wrong.) In fact, Contexts can be used for anything and they are
subject to X.500 facilities like Access Control. However LDAP only
took them as language tags and there is no reason to extend the intent
to use them in a generic manner.

BTW, about the Families of Entries, I had noted down some links here:

http://cwiki.apache.org/confluence/display/DIRxSRVx11/The+need+for+Families+of+Entries+in+LDAP

They can be used for much wider purposes than Contexts. I hope we have
time to implement them.

On 1/22/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 1/21/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> > Well, I don't know to much about famillies, but I think that we might
> > workaround the problem of first email, second email, etc by using
> > attribute descriptions options :
> >
> > mail;primary: my.primary.email@apache.org
> > mail;office: my.office.email@iktek.com
>
> Could this technique also be used for multiple attributes that are
> typically grouped together?  As a specific example, would you do this
> with addresses, say for a shipping address vs. a secondary shipping
> address?
>
> In RFC 2596 the technique is used for language codes:
>
> streetAddress: 1 University Street
> streetAddress;lang-en: 1 University Street
> streetAddress;lang-fr: 1 rue Universite
>
> Would it make sense to handle shipping address vs. secondary shipping
> address attributes (from RFC 2256:  X.500 User Schema) this way?
>
> street;home: 5 Main St.
> street;work: 10 Commercial Way
> ... similarly for st, l, and c (state, locality, and country).
>
> Enrique
>


-- 
Ersin

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Enrique Rodriguez <en...@gmail.com>]

On 1/21/07, Emmanuel Lecharny <el...@gmail.com> wrote:
...
> Well, I don't know to much about famillies, but I think that we might
> workaround the problem of first email, second email, etc by using
> attribute descriptions options :
>
> mail;primary: my.primary.email@apache.org
> mail;office: my.office.email@iktek.com

Could this technique also be used for multiple attributes that are
typically grouped together?  As a specific example, would you do this
with addresses, say for a shipping address vs. a secondary shipping
address?

In RFC 2596 the technique is used for language codes:

streetAddress: 1 University Street
streetAddress;lang-en: 1 University Street
streetAddress;lang-fr: 1 rue Universite

Would it make sense to handle shipping address vs. secondary shipping
address attributes (from RFC 2256:  X.500 User Schema) this way?

street;home: 5 Main St.
street;work: 10 Commercial Way
... similarly for st, l, and c (state, locality, and country).

Enrique

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Alex Karasulu <ak...@apache.org>]

Emmanuel Lecharny wrote:
> Alex Karasulu a écrit :
> 
>> I am expecting a proposal on how we can implement this feature.  :)
>>
>> Alex
> 
> Well, I don't know to much about famillies, but I think that we might 
> workaround the problem of first email, second email, etc by using 
> attribute descriptions options :
> 
> mail;primary: my.primary.email@apache.org
> mail;office: my.office.email@iktek.com

Interesting idea for that.  We probably can use special tags for things 
like that like the lang tag but this would be built in instead of user 
configured.  Like for example ou;lang-en or ou;lang-fr etc.

That's perhaps the difference.

> Searching for a primary email is then very easy, supposing that the 
> client accept such attribute description options (btw, they are really 
> close to what we can do with languages). The filter would be :
> (mail;primary=*)
> 
> Looking for all email is equally easy :
> (mail=*)
> 
> It seems to be simple, not depending on anything else that basic ldap 
> features, and quite logical to me.
> 
> wdyt ?

I think doing this tag feature thing is ok if it's just one thing but 
it's hard coded and not too flexible.  Maybe I'm missing something too.

Alex

Re: [Fwd: [ldap] Re: AW: Re: LDAP Addressbook / schema selection]

[Emmanuel Lecharny <el...@gmail.com>]

Alex Karasulu a écrit :

> I am expecting a proposal on how we can implement this feature.  :)
>
> Alex

Well, I don't know to much about famillies, but I think that we might 
workaround the problem of first email, second email, etc by using 
attribute descriptions options :

mail;primary: my.primary.email@apache.org
mail;office: my.office.email@iktek.com

etc.

Searching for a primary email is then very easy, supposing that the 
client accept such attribute description options (btw, they are really 
close to what we can do with languages). The filter would be :
(mail;primary=*)

Looking for all email is equally easy :
(mail=*)

It seems to be simple, not depending on anything else that basic ldap 
features, and quite logical to me.

wdyt ?

Emmanuel