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

RE: trimming listed syntaxes in RFC 2252bis



At 04:26 PM 2/23/01 +1100, Steven Legg wrote:
>Kurt D. Zeilenga wrote:
>> At 03:04 PM 2/22/01 -0800, Kurt D. Zeilenga wrote:
>> >I suggest the table of syntaxes provided in RFC 2252, 4.3.2 be trimmed
>> >to only those which are specified in the TS.  Below is a table which
>> >indicates the deposition I recommend where "Deposition" is:
>> >        Y - Include
>> >        N - Not part of the LDAP "core" specification, remove
>> >        M - Not part of the LDAP "core" specification, it and
>> >                dependent matching rule should be removed.
>
>Out of curiosity, do you expect these removed things will resurface later,
>fully defined, in other RFCs under ldapext, or do you expect them to
>disappear
>forever ?

I suspect that any syntax of value will not disappear forever.
But I make no value judgement, here.  In my view that they were
not specified in the LDAPv3 "core" PS and hence should not be
specified in the LDAPv3 "core" DS.  My suggestion is list only
those syntaxes actually specified in the TS.

>> >I note that of those listed as "Include" may need to be excluded
>> >for other reasons (such as implementation report findings).
>>
>>         O - Depends on Obsolete specification
>>         I - Depends on non-Standard Track specification
>>         D - Deprecated syntax
>
>Are you going to use these in combination with Y, N and M ? Otherwise what
>is the implied fate in each case ?

I meant to imply that all codes except Y should to be removed.


>>
>> >Comments?
>> >
>> >
>> >   Value being represented        Deposition IDENTIFIER
>> >   =================================================================
>
>> >   MHS OR Address                  O  1.3.6.1.4.1.1466.115.121.1.33
>
>In the syntax survey I noted the most recent specification, RFC 2156, for
>this one.

Okay, maybe:
        X - dependent on 'expired in grade' PS

(implying removal) would be more appropriate.  As taking 2156 is
beyond the scope of this WG, removal of the non-critical schema
item is best (IMO).