Re:

[Skip Slone <[e-mail]>]

In message <9306091714.AA09007@tag>  writes:
> >From P.Furniss Wed Jun  9 16:56:13 BST 1993 remote from ulcc.ac.uk
> Subject: Problem with oid root used in RFC 1274
> To: [e-mail] (Steve Hardcastle-Kille)
> Date: Wed, 9 Jun 93 16:56:13 BST
>  
> 
> RFC 1274 (The COSINE and Internet X.500 Schema) defines Directory 
> objects and attributes which have the following object id root for their 
> identifications:
> 
>       {ccitt(0) data(9) pss(2342) ucl(19200300) pilot(100)}
> 
> However, it appears that this is not a valid object id, as annex C of
> ISO/IEC 8824:1990 identifies only four arcs below ccitt(0). CCITT (now
> ITU-TS) have not assigned any new arcs. (as far as I can make out)
>
> The OSI-tg interest is because some of the attributes cover transition 
> from the UK NRS scheme to Directory. The problem is whether the oid 
> root should be changed to a valid one, or we just carry on and don't 
> worry.
> 
> If we don't change, there is some risk that some (commercial)
> Directory implementation may include something that refuses to allow
> invalid oids, and which therefore could not accept or access entries

Unless I'm way off base in my understanding, OIDs are, by design, extensible.  
Anyone who has a legitimately assigned OID has the right and authority to assign
further OIDs using the first one as the base.  From this perspective, a 
conformant implementation is obligated to accept a syntactically correct OID as 
an OID whether it understands the semantics or not.

This is partially covered in the "Rules for extensibility" clauses in X.519 
(9594 part 5), where it says things like "...shall not consider the receipt of 
unknown attribute types and attribute values as a protocol violation..."  This 
text is in the 93 edition and the same concept was incorporated into 88 as 
defect report 052.  Loosely translated, this says "just because you don't 
recognize the OID identifying the attribute type (or the attribute value 
identifying the OID of the object class), you can't assume the OID is invalid."

What this means to me when I put on my "DUA developer" hat is an implementation 
that croaks when it encounters an unknown OID is simply non-conformant to the 
standard, end of discussion.  Further, an implementation that can handle unknown
OIDs, but that doesn't allow me to define new semantics for previously unknown 
OIDs may be conformant, but it's basically useless to me over the long haul.

> using the 1274 schema. Since the awkward implementation could claim to
> be a more accurate implementation of the CCITT/ISO standard, this
> might produce some strange arguments.  We would be propagating
> something that is nearly, but not quite osi.
> 
> There would obviously be some difficulty with a change-over to 
> synonymous valid oids. It will be extremely difficult unless Directory 
> implementations can handle synonyms - but I believe many can.
> 
> If the oid root is changed, it would be possible to make it appreciably 
> shorter - using an additional, IANA-assigned, arc from the same root as 
> SNMP uses would seem sensible.
> 
> What should be done ?
> 

For new work, people can do what makes the most sense knowing what we 
(collectively) know now, but for existing stuff, let's not rock the boat.  It's 
working.  It's legitimate.  Let's not "fix" it.

  -- Skip Slone