IETF Logo Mail Archive

Re: Ommitted components in the 1327 mapping

"Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no> Thu, 10 March 1994 10:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01065; 10 Mar 94 5:30 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01061; 10 Mar 94 5:30 EST
Received: from [129.179.91.44] by CNRI.Reston.VA.US id aa03037; 10 Mar 94 5:30 EST
Received: from mercury91.udev.cdc.com by sequoia.udev.cdc.com; Thu, 10 Mar 94 04:16:29 +0600
Received: by mercury.udev.cdc.com; Thu, 10 Mar 94 04:14:59 -0600
X-From: Harald.T.Alvestrand@uninett.no Thu Mar 10 04:14 CST 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Thu, 10 Mar 94 04:14:52 -0600
Received: from domen.uninett.no by zeus.cdc.com; Thu, 10 Mar 94 04:14:51 -0600
Received: from localhost by domen.uninett.no with SMTP (PP) id <00867-0@domen.uninett.no>; Thu, 10 Mar 1994 11:14:29 +0100
To: Steve Kille <S.Kille@isode.com>
cc: mhs-ds@mercury.udev.cdc.com
Subject: Re: Ommitted components in the 1327 mapping
In-reply-to: Your message of "Wed, 09 Mar 1994 13:43:30 GMT." <6403.763220610@glengoyne.isode.com>
Date: Thu, 10 Mar 1994 11:14:26 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no>
Message-Id: <2d7ef31d0aa4002@zeus.cdc.com>

Steve,
one thing I am not sure about:
Your approach still changes the "Representing O/R names"
document, doesn't it? So that the actual structure changes?

Otherwise, I kind of disagree with your conclusion:

I must agree with Michael in that I don't like an approach where
the strategy for handling a missing component in an RDN-O/R name
is radically different from the strategy for representing the
same missing component in an O/R name.

My favourite would still be 2) with "SPACE" (my favourite
interpretation of the battles over SPACE in ISO was that it is
only a placeholder because they couldn't agree to declare it
OPTIONAL, so that there is precedent for this usage).
Or $$$MISSING$$$.

It's not a show-stopper, but I think it actually makes the spec
more complex to read and to implement if we add another OID-valued
special case to the naming tree.

                    Harald A

v2.8.7 | Report a Bug | By Email