[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ASN.1 (was: Where are we now?)
Taking the ASN.1 issue from your response. I don't yet have a strong view
-- still exploring the options...
At 15:02 16/03/98 -0800, Ted Hardie wrote:
> Thanks for your summary below. I agree with you that we need
>to resolve the ASN.1 issue, but I think we differ on how to do so.
>Your concern, as I understand it, is that the same feature might be
>assigned different ASN.1 OIDs by different organizations, and that
>this might lead to problems when these are used in a feature exchange.
>I would expect that allowing the registering organization to
>give its ASN.1 designation for the feature as it registered it would
>be enough to avoid conflict. If a registered feature had an ASN.1 OID
>associated with it, that could be used in the negotiation; otherwise,
>negotiation would have to proceed with the name. I don't think it is
>necessary for IANA to assign the OIDs, and I don't really want to
>require others to assign them, as many registrants may not want to go
>through the hassle of managing a delegated portion of the ASN.1
Given that we are talking about assigning meanings to tokens, the important
thing from a cross-protocol PoV seems to be agreement on the "meaning", and
as long as participants in a given protocol use the same refering "token".
There's little harm if different protocols use different tokens. (I see
there is practical value in having a common textual syntax, because the
descriptions tend to be longer and a common reference saves design effort.)
So I can agree that ASN.1 OID designations do not need to be mandatory.
(I don't really feel that your suggestion to use the textual form wthin
ASN.1 protocols is a Good Idea -- it seems to me to be a "worst of all
worlds" type of approach. But not being an expert here I am prepared to
bow to better-informed opinion.)
QUESTION: should the registration provide for an *optional* ASN.1
assignment in a standard IANA sub-tree? This would not involve the
registering party in "the hassle of managing a delegated portion of the
ASN.1 namespace", but if the registration *were* made then it could save
others from precisely this hassle in the futire if they wish to use the
feature with ASN.1-based protocols.
As I see it, the IANA responsibility here would be (1) to assign a sub-tree
of IANA-managed OID-space (a one-off activity), and (2) assign a unique
integer identifier for each feature which is registered with an OID.
Something which I can imagine might prove problematic is allowing
organizations to define their own OIDs in a registration -- what are the
guarantees that the corresponding OID sub-namespace will be appropriately
managed in the future?
ANOTHER QUESTION: if we do not address the OID issue now, how difficult
would it be to retrospectively add OIDs to feature registrations in the
future? I suspect that the answer is "not too difficult" (e.g. an update
to the registration document and a simple separate OID/feature-name
register might do the trick).