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

Re: models-09 comments



Kurt D. Zeilenga writes:
>At 08:45 AM 12/21/2003, Hallvard B Furuseth wrote:
>>draft-ietf-ldapbis-models-09.txt says:

>>>   While the <descr> form is generally preferred when the usage is
>>>   restricted to short names referring to object identifiers which
>>>   identify like kinds of objects (e.g., attribute type descriptions,
>>>   matching rule descriptions, object class descriptions), (...)
>>>
>>>   When the <descr> form is used, the representation SHALL be considered
>>>   invalid if the usage is not restricted as discussed above or the
>>>   implementation cannot determine unambiguously which object identifier
>>    ^^^^^^^^^^^^^^
>>>   the <descr> refers to.
>>
>> This requires client implementations to fail if they don't maintain
>> descr->numericoid mappings.
>> Suggest to replace "the implementation" with "the server", or maybe
>> "an implementation which uses numericoids as the primary key to the
>> above objects (e.g. an LDAP server)".
> 
> I think "implementation" here is correct.  The problems of
> short name mapping to multiple numericoids (of like or different
> kinds of objects) is a problem which servers and clients both
> face.  The language used here implies that if the client knows
> that x-foo could be 1.1.1 or 1.1.2 depending on context.  It
> then is provided x-foo absent of context, which is it to use?

That's why I suggested "an implementation which uses numericoids as the
primary key to the above objects".  None of the above applies to clients
that only deal with descriptors and don't know their numericoids.

> The SHALL here says that it cannot arbitrarily select one or
> the other, it MUST treat x-foo as invalid.

Well, as you can see, I think it says more than that.

> Note that just because a descriptor is "invalid" does not mean
> the client fails.  In most cases, invalid descriptors are simply
> ignored.

That's a strange loophole to use.  These clients won't want to
ignore the descriptors, and they may have some idea of invalid
descriptors (e.g. descriptors with invalid syntax) which are
treated differently from the descriptors that they do use.

> Now, maybe it would be better to say implementations must treat
> ambiguous descriptors as it would a descriptor it does not recognized.

Good idea.  That avoids the problem.  Since this only applies to
implementations that _know_ that the descriptor is ambiguous, clients
which don't know anything about OIDs are not affected by the
requirement.  At the same time, clients that do know that a particular
attribute needs to contain numericoids and not descriptors because it
has no disambiguating information, are required to do the right thing.

-- 
Hallvard