[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] OIDs in LDAP Internet-Drafts
I see a couple of flaws in your rationale for OID versioning
in "works in progress". The main one is that early
implementations do not adhere strictly to one particular
revision of the "work in progress". That is, aside from the
specification being a "work in progress", often so are early
implementations. Consistency is hard in the early stages of
development of an extension specification and its implementations.
It seems far easier for a single implementor wanting to develop
peers to use a locally assigned OID. This is what the OpenLDAP
Project does, it seems to work fine. We have a special branch
for this, known the "devil made me do it" branch. The assignment
practice in this branch is that each OID identifies a "work in
progress" (or portion thereof) as currently implemented. Again,
no consistency guaranteed. It's a work in progress after all.
For this and other reasons, we avoid advertising support for
"works in progress", even in development codes.
For those wanting to do some interop testing, those participating
in the testing should easily be able to reach some adhoc agreement
as what OID to use. Since we talking early implementation here, I
presume that changing OIDs to test is no big deal.
That all said, if you want to provide an OID, you may use
Experimental OIDs (see Section 3.1 of BCP 64). These MUST be
replaced prior to publication as an RFC. I see no reason why
you could version assignments under the OID. BCP 64 certainly
does not preclude that.
I would not recommend updating OIDs on each revision. That just
creates unnecessary change. Instead only update the OIDs when
the new semantics are not backwards compatible with the old
semantics.
Personally, I think I'll stick to my current approach. Avoid OIDs
in I-Ds.
At 04:46 PM 2/25/2005, Jim Sermersheim wrote:
>All,
>
>While a specification progresses through its life cycle as an
>Internet-Draft, Implementations of it may need to issue OIDs for schema
>elements, extension names, etc.
>
>Ideally, any time an implementation is updated to match a semantic
>change in a newer version of the specification, it will revise the OID
>it's using. This would have the effect of indicating support for the
>semantics defined in the particular revision implemented.
>
>I know some implementations use their own experimental OID arc for
>implementations of pre-RFC specifications. I don't know what their
>policy is in terms of updating OIDs as semantics of the specification
>change.
>
>It would be very useful if, instead of each implementation doing this,
>it could be done in the I-D itself. Ideally, one would procure a
>"proposed OID arc" from IANA. The I-D editor would then update OID
>assignements in the specification, and rev them anytime a semantic
>change would cause an interoperability problem. Alternately (more
>simply) the editor could update them all everytime the I-D was revised.
>To make it easy, they could even assign an arc below the IANA-assigned
>arc which adopts the I-D revision number. i.e. if the IANA assigned arc
>is 1.2.3.4, the OIDs in the I-D would be 1.2.3.4.0.x for the -00
>revision, and 1.2.3.4.1.x for the -01 revision.
>
>When the I-D is progressed to an RFC, IANA could do its usual
>assignment / replacement.
>
>The two benefits I see are that multiple interoperable implementations
>may be produced while a specification is being progressed, and that the
>experimental/temporary OIDs being used will match a specific incarnation
>of the specification.
>
>What think ye?
>
>Jim
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext