[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: rfc2277 compliance



I should have stated that I'm not really concerned with how much we do
for RFC2277 compliance myself.  I just thought from the passwords/
SASLprep thread that at least you & Jim might be.  Anyway,

Kurt D. Zeilenga writes:
> The specification (as a whole) should be reasonably clear as to whether
> a protocol element is character data or not.   We need not, however,
> state the obvious.  That is, I don't think we need to add "values of
> the Directory String syntax are character data".  However, if there
> are cases where you believe the specification is not clear as to whether
> values of a syntax are character data or not, please note so to the list.

It's not clear to me if all syntaxes in [Syntaxes] except JPEG contain
text in the rfc2277 sense, or if just the ones matching the string
matching rules listed in [Syntaxes] 4.2 are text.

>>> 4.2.  Requirement for language tagging
>>>
>>>   Protocols that transfer text MUST provide for carrying information
>>>   about the language of that text.
>>
>> This implies that LDAP needs something like an Accept-Language extended
>> operation similar to the HTTP Accept-Language: header.
>> It would specify which languages the client prefers for
>> LDAPResult.diagnosticMessage and text in unsolicited notifications.
> 
> While not a complete solution, LDAP addresses this through language tags
> options (RFC 2596).

I know.  That's why I just mentioned elements that can not be associated
with language tags.

> Additionally, servers can use other information
> (such as associated with authenticated users) to localize such text.

Check if that his entry has something like a preferredLanguage
attribute, you mean?  OK, but it doesn't help other users, or
unauthenticated users.

> While certainly one could develop an extension to address this issue,
> and I would encourage those interested to propose such an extension
> to the IETF, I think LDAPBIS should view such as a new feature and
> hence beyond our scope.

Fine by me.  (And I don't think it will be me who proposes it.)

-- 
Hallvard