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!
- Re: O/R Address format in the routing document Allan Cargille
- O/R Address format in the routing document Urs Eppenberger
- Re: O/R Address format in the routing document Marina Arseniev
- Re: O/R Address format in the routing document Urs Eppenberger
- Re: O/R Address format in the routing document Harald Tveit Alvestrand