Re: Problem with oid root used in RFC1274

[Skip Slone <[e-mail]>]

In message <[e-mail]>  writes:
> 
> The problem is "legitimately assigned OID". It is quite correct that
> an implementation should handle unrecognised attribute names, even if
> it hasn't the foggiest idea who it belongs to. The problem is that the
> 1274 root isnt valid - ccitt(0) 9 has not been assigned. Worse (I
> should have made this the main point perhaps), {0 9} might one day be
> assigned (by ITU-TS) to some sub-authority or list.
> 

(With expressions and intonations that say "Now, I get it," I respond...)

I certainly missed the implied point, since it never dawned on me it was the 
second arc you were concerned with.  It's easy to assume a certain amount of 
legitimacy that high in the tree.


> Despite which, your practical solution:
> 
> > 
> > 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.
> 
> maybe best, if naughty.
> 

While we're on the topic of being naughty, I've heard it said many times that 
"possession is nine-tenths of the law."  In that spirit, what's the likelihood 
of convincing CCITT (or whatever they call themselves now) that the prudent 
course for everyone is to find some mechanism/loophole that allows them to 
simply assign {0 9} to "us." (Perhaps they could designate it on a registry as 
"reserved" or something like that, so that collisions don't happen with the 
residue that will undoubtedly be left behind after a migration.)  I know *I* 
wouldn't want to be on the committee that discovers that all of its OIDs collide
before they're even assigned!

This kind of approach might require some grovelling and repentant promises not 
to repeat the behaviour, but that could certainly be less painful than 
migrating.

Oh, well.  I'll be quiet.


  -- Skip