Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/15/89)
>The three people referenced had very strong views, and dominated the >discussion. However, I detected support for both views among the >remainder. Stef kept us off each others throats! >As editor/author, I've chosen to go the way I want. I'd appreciate comments >on this. Please read the text, and don't just base discussion on this >message. >I have a very strong feeling of deja vu here. 8 years ago, the UK and US >picked opposite domain orders, each arguing "naturalness" as the reason for >choice. It doesn't really matter that much. However, having a mixture is >an absolute disaster. I fear that we are about to relive our history. Hi all ... I want to be on record as supporting Steve's view on this item. In my role as throat-protector-of-the-day I must have conveyed a more neutral postition than I actually hold. I am against arbitrary style based anarchy generators. This is a case where allowing it to be a local matter creates global network interworking problems. But, as Steve says, read the text bewfore you coment! Best...\Stef
pv@SUN.COM (Peter Vanderbilt) (07/15/89)
In my opinion, compatibility with RFC987/1026 should be foremost.
Users should not need to know whether a given address is to be
processed by a 987 gateway or a 987-88 gateway (unless they are using
88 features). Although some may not like the order specified by 1026,
we're stuck with it now.
1026 states:
1) On the text encoding (std-orname) of P1.ORName as used in the
local-part of an RFC-822 address, the most significant component
must be on the RHS. This applies only to those components which
may have multiple values (Organisational Unit, and Domain
Defined Attributes). Other attributes may be presented in any
order.
Because of the ordering clause, a 987 gateway must generate OUs right
to left. So should 987-88 gateways. Thus I support View 2 (Kille's).
(I'd recommend that gateways generate all components right to left.)
Because of the last sentence, the 987 address fragment
/O=org/OU=ou2/OU=ou1/ must be interpreted as ou1 being the most
significant component. Thus I oppose the proposed heuristic for 987-88
addresses:
- If there is an Organisation attribute to the left of
any Org Unit attribute, assume that the hierarchy is
inverted.
(I don't understand the second part:
- If an inversion of the Org Unit hierarchy generates a
valid address, when the preferred order does not,
assume that the hierarchy is inverted.
How could the gateway know whether the preferred order leads to a valid
address?)
If there's an incompatibilty with the RARE WG1 mapping and the RARE
people care, the RARE mapping should be changed.
(I don't understand the "naturalness" argument. In the US, postal
addresses go from least to most significant. Is this different in
other countries? The fact that ASN.1 encodes the attributes in the
other order is a fact of interest to only a tiny percent of X.400
users.)
PeteSXKAC@ALASKA.BITNET ("Kurt Carlson") (07/17/89)
> View 1 (Huitema + Craigie). > > The gateway should be allowed to generate attributes in any order. This > would allow them to use their respective preferred orders (most significant > on the left, and most signficant in the middle). Gateway output could then > be aligned with user expectation. > > View 2 (Kille) > > Consistency between gateways is very important. (RFC 822) Users should > expect to see the same form of X.400 address from different gateways. > Message IDs should always be generated in the same way. Therefore, this > specification should require an order when generating addresses. Please note the smtp translation log below from a message posted 7/15: < 220 UK.AC.RL.IB Columbia MAILER X1.25 BSMTP service ready. < 050 HELO UKACRL < 250 UK.AC.RL.IB Hello UKACRL < 050 MAIL FROM:<SXKAC@EARN.ALASKA> < 250 <SXKAC@EARN.ALASKA>... sender OK. < 050 RCPT TO:<p02@UK.AC.RL.IB> < 250 <p02@UK.AC.RL.IB>... recipient OK. < 050 DATA < 354 Start mail input. End with <crlf>.<crlf> This resulted from a message from SXKAC@ALASKA.BITNET to P02@IB.RL.AC.UK; the domain type specifications have been inverted by somebody's mailer. This message resulted from several hours of research following a request >from PO2@IB.RL.AC.UK to "correct" our mailer which s/he felt was garbling messages to be "user@EARN.ALASKA" instead of "user@ALASKA.EARN". In reality, something elsewhere and as yet undefined is reponsible. While I'm not sure this has any direct relation with RFC987, it may serve as an example (as if we should need any) of what results when somebody elects to do things in an inverted fashion. In my opinion, an order should be required and follow rfc987/1026. The purpose of the standards is to communicate. Perhaps it is "natural" for humans to fail to communicate, but that is not the objective of x.400 or the revisions to rfc987. Consider me a strong advocate for "View 2 (Kille)" to generate in a consistant and documented manner. If a particular subset of the world defines "naturalness" differently (which they will) it should be their responsibility to implement their natural order within their local user agents but not to extend / inflict that upon the gateways to other agents. Kurt Kurt Carlson, University of Alaska Computer Network, <SXKAC@ALASKA.BITNET>