Subject: trimming listed syntaxes in RFC 2252bis

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 15:04:26 -0800

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.

I note that of those listed as "Include" may need to be excluded
for other reasons (such as implementation report findings).

Comments?

   Value being represented        Deposition IDENTIFIER
   =================================================================
   ACI Item                        N  1.3.6.1.4.1.1466.115.121.1.1    
   Access Point                    N  1.3.6.1.4.1.1466.115.121.1.2  
   Attribute Type Description      Y  1.3.6.1.4.1.1466.115.121.1.3     
   Audio                           N  1.3.6.1.4.1.1466.115.121.1.4   
   Binary                          Y  1.3.6.1.4.1.1466.115.121.1.5
   Bit String                      Y  1.3.6.1.4.1.1466.115.121.1.6
   Boolean                         Y  1.3.6.1.4.1.1466.115.121.1.7   
   Certificate                     Y  1.3.6.1.4.1.1466.115.121.1.8 
   Certificate List                Y  1.3.6.1.4.1.1466.115.121.1.9     
   Certificate Pair                Y  1.3.6.1.4.1.1466.115.121.1.10   
   Country String                  Y  1.3.6.1.4.1.1466.115.121.1.11  
   DN                              Y  1.3.6.1.4.1.1466.115.121.1.12   
   Data Quality Syntax             N  1.3.6.1.4.1.1466.115.121.1.13
   Delivery Method                 Y  1.3.6.1.4.1.1466.115.121.1.14
   Directory String                Y  1.3.6.1.4.1.1466.115.121.1.15
   DIT Content Rule Description    Y  1.3.6.1.4.1.1466.115.121.1.16
   DIT Structure Rule Description  Y  1.3.6.1.4.1.1466.115.121.1.17     
   DL Submit Permission            N  1.3.6.1.4.1.1466.115.121.1.18  
   DSA Quality Syntax              N  1.3.6.1.4.1.1466.115.121.1.19
   DSE Type                        N  1.3.6.1.4.1.1466.115.121.1.20
   Enhanced Guide                  Y  1.3.6.1.4.1.1466.115.121.1.21
   Facsimile Telephone Number      Y  1.3.6.1.4.1.1466.115.121.1.22
   Fax                             Y  1.3.6.1.4.1.1466.115.121.1.23
   Generalized Time                Y  1.3.6.1.4.1.1466.115.121.1.24
   Guide                           Y  1.3.6.1.4.1.1466.115.121.1.25     
   IA5 String                      Y  1.3.6.1.4.1.1466.115.121.1.26     
   INTEGER                         Y  1.3.6.1.4.1.1466.115.121.1.27    
   JPEG                            Y  1.3.6.1.4.1.1466.115.121.1.28     
   LDAP Syntax Description         Y  1.3.6.1.4.1.1466.115.121.1.54
   LDAP Schema Definition          N  1.3.6.1.4.1.1466.115.121.1.56
   LDAP Schema Description         N  1.3.6.1.4.1.1466.115.121.1.57  
   Master And Shadow Access Points N  1.3.6.1.4.1.1466.115.121.1.29   
   Matching Rule Description       Y  1.3.6.1.4.1.1466.115.121.1.30
   Matching Rule Use Description   Y  1.3.6.1.4.1.1466.115.121.1.31
   Mail Preference                 N  1.3.6.1.4.1.1466.115.121.1.32 
   MHS OR Address                  Y  1.3.6.1.4.1.1466.115.121.1.33
   Modify Rights                   N  1.3.6.1.4.1.1466.115.121.1.55
   Name And Optional UID           Y  1.3.6.1.4.1.1466.115.121.1.34
   Name Form Description           Y  1.3.6.1.4.1.1466.115.121.1.35
   Numeric String                  Y  1.3.6.1.4.1.1466.115.121.1.36
   Object Class Description        Y  1.3.6.1.4.1.1466.115.121.1.37
   Octet String                    Y  1.3.6.1.4.1.1466.115.121.1.40
   OID                             Y  1.3.6.1.4.1.1466.115.121.1.38
   Other Mailbox                   Y  1.3.6.1.4.1.1466.115.121.1.39     
   Postal Address                  Y  1.3.6.1.4.1.1466.115.121.1.41
   Protocol Information            M  1.3.6.1.4.1.1466.115.121.1.42     
   Presentation Address            Y  1.3.6.1.4.1.1466.115.121.1.43
   Printable String                Y  1.3.6.1.4.1.1466.115.121.1.44
   Substring Assertion             Y  1.3.6.1.4.1.1466.115.121.1.58  
   Subtree Specification           N  1.3.6.1.4.1.1466.115.121.1.45
   Supplier Information            N  1.3.6.1.4.1.1466.115.121.1.46    
   Supplier Or Consumer            N  1.3.6.1.4.1.1466.115.121.1.47   
   Supplier And Consumer           N  1.3.6.1.4.1.1466.115.121.1.48  
   Supported Algorithm             Y  1.3.6.1.4.1.1466.115.121.1.49   
   Telephone Number                Y  1.3.6.1.4.1.1466.115.121.1.50
   Teletex Terminal Identifier     Y  1.3.6.1.4.1.1466.115.121.1.51
   Telex Number                    Y  1.3.6.1.4.1.1466.115.121.1.52
   UTC Time                        Y  1.3.6.1.4.1.1466.115.121.1.53

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 15:35:44 -0800

>for other reasons (such as implementation report findings).

        O - Depends on Obsolete specification
        I - Depends on non-Standard Track specification
        D - Deprecated syntax

>   Guide                           D  1.3.6.1.4.1.1466.115.121.1.25     
>   MHS OR Address                  O  1.3.6.1.4.1.1466.115.121.1.33
>   Presentation Address            I  1.3.6.1.4.1.1466.115.121.1.43
>   UTC Time                        D  1.3.6.1.4.1.1466.115.121.1.53

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 23 Feb 2001 16:26:36 +1100

Kurt,

> >                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 - Depends on non-Standard Track specification

Are you going to use these in combination with Y, N and M ? Otherwise what
is the implied fate in each case ?

> >   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.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 21:59:20 -0800

>fully defined, in other RFCs under ldapext, or do you expect them to

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.

>is the implied fate in each case ?

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

>In the syntax survey I noted the most recent specification, RFC 2156, for

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).

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Feb 2001 10:40:15 -0500

I am also in favoring of removing some of the non-essential syntaxes
(simpler is better).  I am not sure if the your "Deposition" column is
100% correct, but at a glance it looks good to me.  BTW, shouldn't that
be "disposition?"

-Mark Smith
 Netscape