Re: O/R Address format in the routing document

Allan Cargille <Allan.Cargille@cs.wisc.edu> Fri, 05 February 1993 16:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07734; 5 Feb 93 11:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07730; 5 Feb 93 11:53 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa13405; 5 Feb 93 11:53 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 5 Feb 1993 10:51:48 +0000
Date: Fri, 05 Feb 1993 10:51:48 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..997:05.01.93.16.51.48]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 5 Feb 1993 10:51:47 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allan Cargille <Allan.Cargille@cs.wisc.edu>
Message-ID: <930205105132*/G=Allan/S=Cargille/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS>
To: Urs Eppenberger <Eppenberger@switch.ch>
Cc: "Allan C." <Allan.Cargille@cs.wisc.edu>, pays@mars.emse.fr, ietf-osi-x400ops@cs.wisc.edu
In-Reply-To: <"580 */S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/"@MHS>
References: <575*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=A/C=CH/@MHS>, <580*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
Subject: Re: O/R Address format in the routing document

[Background: I mailed Urs about the way that X.400 address components
are ordered in his Internet Draft, draft-ietf-x400ops-mhs-service-03.txt,
"Routing coordination for X.400 MHS services..."   I think that the ISO
standard which the document references basically uses an ordering of
/PN/O/OU*/PRMD/ADMD/C/.  The routing document is referencing the ISO
standard, but is reversing the O and OU fields, resulting in an
ordering of /PN/OU*/O/PRMD/ADMD/C/.  Here's Urs' reply, and then my
response.]

} Hello Allan,
} 
} Since the keys are unique it does not really matter.
} I had it first as in ISO. Then I discussed it with PAP. He proposed to
} modify it to use the hierarchical and logical ordering and I agreed even
} if this is slightly against the ISO proposal. Technically it does not matter.
} 
} That's why I have it in the hierarchical ordering in the newest routing doc
} draft.
} 
} Kind regards,
} 
} Urs.
} 
} PS: I had 'private' discussions about detail issues in the routing documents
}     with a lot of people. If they send in direct comments, I keep the issue
}     generally between us unless I think it is controversial, but this will
}     be my subjective judgement. So if I'm in agreement with someone else,
}     his proposal will make it into the document without anyone else seeing
}     it until a new draft is released  ;-)

Hi Urs,

Thanks for the response.

I'd like to address your second point first -- I know you need to make
editorial decisions in private on the document.  However, the document
is also the result of work by a working group.  Therefore, I would
prefer if you would inform the group when technical decisions and
changes are made.  This could be done just by summarizing the issues
and your proposed decision.  Others may be able to raise issues or
problems which have been overlooked and which may possibly change the
decision.

Secondly, I'd like to address Appendix B, "OR Address Representation."
The Appendix starts off by claiming

}     This Appendix defines the OR address representation to be used
}   throughout the documents. It is based on the following CCITT
}   recommendation
}       
}       Annex to CCITT Rec. F.401 and ISO/IEC 10021-2
}       ANNEX F REPRESENTATION OF O/R ADDRESSES FOR HUMAN USAGE
}     
}     and on a document written by Paul-Andre Pays which defines a
}   subset of the CCITT recommendation to limit the options and
}   automatic processable addresses. The definitions for the routing
}   documents are even more strict than proposed by P-A Pays which to
}   allow for easier parsing tools.

I believe that this statement is inaccurate and misleading.  There is a
big difference between *restricting* a recommendation to simplify
parsing, and *modifying* the standard which claiming to be based on
it.

I think we need to decide if we want to follow the standard or not.  I
have no strong feelings on the matter, I'm not real crazy about the
standard address ordering.  But I think we should be honest about our
decision, and document it.  If we need to restrict the format for
parsing, fine.  But I think the re-ordering the O and OU values is a
rejection of the standard.  Obviously there's no "technical difference."
However, there's also no technical difference between using the ISO
standard or creating our own entirely new standard.

PAP (Paul-Andre Pays) has previously made very strong points
that networking work is based on standards, and that if a standard
exists, then we should align our efforts with them.  I think he has a
good point, so I think we should accept his advice and conform to the
standard.  In fact, I am quite surprised that PAP would support
departing from the standard, when he was the one who made such a strong
case for using it!

If we choose to reorder the O and OU values, this should be clearly
indicated in the introduction to Appendix B.  We should state that the
appendix is *loosely* based on the ISO standard, but also clearly
identify the departure from the standard that we have used instead
(swapping O and OUs).

Lastly, Urs mentioned above that "Since the keys are unique it does not
really matter..."   The O/R address format is used in describing X.400
addresses in for persons, email servers, and echo servers, as well as
the <UniquePersonKey>.  Since it is used to describe actual email
addresses, not just the <UniquePersonKey>, I think that it is worthwhile
strongly considering that we adopt the ISO format.

Again, I have no strong feelings about the format we choose.  I just
want to see us be honest.  The two choices are to follow the standard or
define our own format.  I don't think there's such a thing as "slightly
modifying the standard."

Best regards,

allan

PS - Urs, I'm sure you're thoroughly sick of my comments by now!