RE: LAST CALL: draft-ietf-ldapext-lang-00.txt

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

Isn't this covered by RFC2251?  All I can find is a requirement for
servers to treat unknown options as unknown attribute types.  Shouldn't
the same requirement apply to clients?

Extensions ought to be made in such a way as not to break existing
conforming clients.  If a client might be broken by an unexpected option
(such as "cn;lang-fr" when "cn" was requested), then there ought to be
an explicit enabling action taken by the client before a server returns
these tags.  


> ----------
> From: 	Tim Howes[SMTP:howes@netscape.com]
> Sent: 	Friday, February 27, 1998 1:18 PM
> To: 	Steve Kille
> Cc: 	ietf-ldapext@netscape.com
> Subject: 	Re: LAST CALL: draft-ietf-ldapext-lang-00.txt
> 
> Steve Kille wrote:
> 
> >  >> 1) Backwards compatibility with LDAPv3 clients that do not
> support
> >  >> this specification.   In particular, what is the conformant
> action of
> >  >> an LDAPv3 client getting back language information.
> >  >
> >  >Attributes with unknown tags should be treated as unknown
> >  >attribute types. Just like if a client asked for the name
> attribute
> >  >and got back cn, sn, givenName, and nickName, but did
> >  >not know anything about the nickName attribute. If a client
> >  >asks for cn and gets back cn and cn;lang-fr, it should just
> >  >ignore it (or display it - the client's choice, obviously).
> >
> > My gut reaction is that this will cause interoperability problems
> for some
> > LDAP clients.  I'd certainly be interested in the views of those
> that are
> > implemented client side products (we are server focused).
> 
> It may, yes, I agree. Just as attribute subtyping may cause
> interoperability problems for some clients. My gut feel,
> though, validated by my experience with clients I have seen
> so far, is that the problems will be minor, and that this is
> the best approach to achieve this important new functionality.
> Do you have a suggestion for mitigating these potential
> problems further? Should we add an explicit note to the
> document about it?
> 
> 
> >  >> 2) X.500(97) also defines language tagging.  I think that there
> should
> >  >> be information which ties this together.    Can LDAP language
> tags be
> >  >> mapped onto X.500 tags in some/any circumstances.
> >  >
> >  >X.500 does this with contexts (my understanding). I'd be
> >  >happy to see someone more familiar with X.500 define
> >  >what this mapping should be.                         -- Tim
> >
> > I think that this would be useful.  I have not looked at the
> details.  If
> > someone has, I think a short note to this list, with summary added
> to the
> > text would be very very useful.
> 
> If someone wants to turn Kevin's note, forwarded by David,
> into a short section of the document, I think that would be
> fine. Or, if it was going to be a lot of work, not done soon,
> etc., we could publish a separate document.            -- Tim
>