ASN.1 (was: Where are we now?)

[Graham Klyne <GK@xxxxxxx>]

Ted,

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:
>Graham,
>	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
>namespace.

OK...

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

GK.
---


------------
Graham Klyne