pollanen@csc.fi (01/15/91)
Hello How can I send mail to x400 network from internet side In what format must the address be? Yoours Raimo Pollanen pollanen@csc.fi
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (01/15/91)
> How can I send mail to x400 network from internet side > In what format must the address be? Raimo, Again: contact your local FUNET person: Marko Kaittola. He will probably tell you that the address seen from RFC 822 will have different mapping dependent on the destination country. Ex from Norway and USA: You can send a message from your Internet Mailbox to the X.400 address c=no; admd= ; prmd=uninett; o=sintef; ou=elab-runit; pn=Alf.Hansen; by typing: Alf.Hansen@elab-runit.sintef.no .. and you can reach the X.400 address c=us; admd= ; prmd=xnren; o=UW-Madison; ou=cs; pn=Alf.Hansen; by typing: Alf.Hansen@pilot.cs.wisc.edu Easy, isn't it? The strategy in the R&D MHS Service so far has been to publish both forms (the X.400 and the RFC 822 form), and to coordinate internationally the mapping tables everywhere. There are two alternatives to this solution: 1) Agree internationally on ONE mapping (probably unrealistic) 2) Use DDAs as described in RFC 987/1148. If 2), the above X.400 addresses would look like (seen from Internet Mail in Finland): "c=no;admd= ;prmd=uninett;o=sintef;ou=elab-runit;pn=Alf.Hansen;"@x400gw.fi and "c=us;admd= ;prmd=xnren;o=UW-Madison;ou=cs;pn=Alf.Hansen;"@x400gw.fi where x400gw.fi is pointing to your local gateway. RARE WG1 and the R&D MHS Managers are discussing their current strategy right now in Brussels. This will also be an important issue at the meeting in the IETF X.400 Operations Working Group meeting in February. Best regards, Alf H.
Stef@ICS.UCI.EDU (Einar Stefferud) (01/16/91)
Hello Alf -- Thought that in RFC987/1148, we used "/" instead of ";", just because ";" is much more troublesome in RFC822 addresses. When did this change? I have been seeing the ";" used exclusively in examples now for several months? What is going on here? Best...\Stef "c=us;admd= ;prmd=xnren;o=UW-Madison;ou=cs;pn=Alf.Hansen;"@x400gw.fi vs "/c=us/admd= /prmd=xnren/o=UW-Madison/ou=cs/pn=Alf.Hansen/"@x400gw.fi
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (01/16/91)
> Hello Alf -- Thought that in RFC987/1148, we used "/" instead of ";", > just because ";" is much more troublesome in RFC822 addresses. When did > this change? I have been seeing the ";" used exclusively in examples > now for several months? What is going on here? Best...\Stef Stef, I try to make my examples as implementation-independent as possible. We should try to avoid linkage to user-intefaces when we exchange X.400 Standard Attribute addresses between persons, because the actual user intaface may differ considerably from implementation to implementation. The only implementation independent "standard" covering this issue, that I know about, is the RARE document (I forgot the name) written by Ruediger Grimm and Denise Heagerty about X.400 address notation. This document says ; Therfore I am using it in my examples. The document also says: ADMD instead of A and PRMD instead of P. I am not sure what RFC 987/1148 says, but that is just a technical mapping document, and the formats described there, is not a recommendation intended for exchange of addresses between human beings. Best regards, Alf H. BTW I think / is more human readable than ; and I am sure people will understand both...
stef@ICS.UCI.EDU (Einar Stefferud) (01/16/91)
Hi Alf -- The only reason I asked was because what you wrote in your message was a actual example of what a user should put in a real RFC822 address field. You were not writing about an abstract case, but a rela RFC822 address, which would supposedly be handled correctly by and RFC987 gateway. Cheers...\Stef
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (01/16/91)
>> Hello Alf -- Thought that in RFC987/1148, we used "/" instead of ";", >> just because ";" is much more troublesome in RFC822 addresses. When did >> this change? I have been seeing the ";" used exclusively in examples >> now for several months? What is going on here? Best...\Stef > >Stef, > >I try to make my examples as implementation-independent as possible. >.....The only implementation independent "standard" >covering this issue, that I know about, is the RARE document >(I forgot the name) written by Ruediger Grimm and Denise Heagerty >about X.400 address notation. Alf, You must be kidding! The whole discussion was about mapping between X.400 and RFC-822 addresses. And the relevant documents here, at least for the RFC-822 side, are RFC-987 and RFC-1048. There is a lot of difference between: /C=xx/ADMD=yy/PRMD=pp/O=foo/S=bar/@random.gateway.top and "C=xx; ADMD=yy; PRMD=pp; O=foo; S=bar;"@random.gateway.top when seen from a third party gateway "other.gateway.pot". The first form will get map to: <C=xx; ADMD=yy; PRMD=pp; O=foo; S=bar;> while the other one will just baffle the gateway and get map to something like <DD.RFC-822=(q)C=xx(059) ADMD=yy(059) PRMD=pp(059) O=foo(059) S=bar(059)(q)(a)random.gateway.top; ORG=other; PRMD=gateway; ADMD=aaa; C=cc;> In fact, you are precisely mixing user interfaces and network forms, making the assumption that the gateway works "through the user interface"! A big boy like you! Tuut tuut! Christian Huitema
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (01/17/91)
Christian, Of course you are right. I made a fool of myself. I did not know all the details about the user-interface I used in my example. But if you disregard my ignorance about user interfaces, I hope you all got my point regarding address mapping. My point was not at all the difference between / and ;. WHen I replied to Stef regarding RFC 987, I was talking about formats in internal tables, not user interfaces. Sorry for the confusion. Best regards, Alf H.
Stef@ICS.UCI.EDU (Einar Stefferud) (01/17/91)
Hi Alf -- You have my sympathies for the understandable error. You will recall that my query asked whether there has been a change in either RFC987/1148, or a change in the agreed upon notation for business cards that was adopted by RARE (prepared by CERN). I have noted that lately the ";" has been most often used in the discussion about DDAs and RFC987 mapping. You are not the first, nor probably not going to be the last person to make the same error. To clear the record, can someone who has the text handy, resend a copy of the published rules for RFC822 left hand side encoding of X.400 Standard Attributes, and a copy of the text from the RARE agreement on business card representation of the same SA information? I do not have any handy access to the published electronic texts. Best...\Stef
buclin%CLSEPF51.bitnet@relay.eu.NET (01/17/91)
> The only implementation independent "standard" > covering this issue, that I know about, is the RARE document > (I forgot the name) written by Ruediger Grimm and Denise Heagerty > about X.400 address notation. This document says ; Therfore I am > using it in my examples. The document also says: ADMD instead of > A and PRMD instead of P. The document reference is ISO/IEC JTC 1/SC 18/WG N1042, "Recommendation for a short hand notation for X.400 address notation". It is aimed to define in implementation independant notation to help exchanging X.400 OR/addresses, like for example on business cards. The document clearly says : "The short hand notation described here is intended for communities of experienced X.400 users. When exchanging addresses with those unfamiliar with X.400 O/R-addresses, a longer self-explanatory form is more appropriate ." So, this document must not be used to make statement about X.400 user interfaces (although it could be useful to have the same notation for business cards and user interfaces). > > I am not sure what RFC 987/1148 says, but that is just a technical > mapping document, and the formats described there, is not a recommendation > intended for exchange of addresses between human beings. > RFC987 defines the mapping between RFC 822 and X.400. It your user interface (on most unix systems the sendmail/mail pair) uses RFC822 notation, then you MUST use RFC987 notation to specify your addresses. Furthermore, since on Internet, the official mail protocol is SMTP with RFC 822, it is more appropriate to show "real world example" using the defined RFC 822 mapping, which is RFC 987. In other word, on Internet, the preferred notation should be the slash (/) instead of the semi-colon (;). It also has the advantage to prevent the use of quotes around the local-part. Our users already have a lot of trouble to understand the mixture of X.400 and RFC 822, and I think it is not the time to add more confusion when giving them not accurate examples... Bertrand Buclin SWITCH Mail WG Chairman
buclin%CLSEPF51.bitnet@relay.eu.NET (01/17/91)
> To clear the record, can someone who has the text handy, resend a copy > of the published rules for RFC822 left hand side encoding of X.400 > Standard Attributes, and a copy of the text from the RARE agreement on > business card representation of the same SA information? I do not have > any handy access to the published electronic texts. > The RFC 822 left hand side mapping is defined in RFC 987 chapter 4. I have included below the OSI documentation. Regards, Bertrand Buclin Swiss Federal Institute of Technology CH-1015 Lausanne ------------------------ RECOMMENDATION FOR A SHORT HAND X.400 ADDRESS NOTATION Reference: WG1-MHS-89.02.14 Status: Final Date: 14 Feb 1989 Authors: R.Grimm, GMD, Darmstadt, W. Germany D. Heagerty, CERN, Switzerland Abstract -------- This recommendation describes a short hand notation for writing X.400 addresses, thus allowing experienced X.400 users to exchange their addresses in a single, precise format. An example X.400 address written in the recommended notation is: C=uk; ADMD=gold 400; PRMD=funny-films; O=cartoons; S=rabbit; G=tabatha Aims of this Recommendation --------------------------- In X.400, messages are addressed to recipients by giving values to what are termed "attributes of the O/R-address (Originator/Recipient address)". The general attributes (1988) include Country code, Admin- istration Management Domain, X121 address, Terminal identifier, Termi- nal type, Private Management Domain, Organisation Name, Organisational Units, Unique user agent identifier, Common name, Personal Name, Sur- name, Given Name, Initials and Generation Qualifier. X.400 does not however define a user interface for entering values for these attri- butes. Some X.400 systems prompt for values via menus, others define their own differing syntax for assigning values to attributes. This has the consequence that there is no standard textual representation for people to exchange their X.400 addresses, for example, on the back of a business card or attendance lists at meetings. If each attribute name is written in full then deducing the values is rather obvious, however the tendency is to use a short hand representation. The objectives of this recommendation are therefore: * To suggest a preferred short hand notation for writing X.400 addresses which could be used and understood by any experienced X.400 user. * To simplify local X.400 user guides which should define the mapping between the recommended notation and the local user interface. (Note that the recommended notation is not intended to replace the local user interface.) * To give a meaning to some alternative notations already known to be in use. The short hand notation described here is intended for communities of experienced X.400 users. When exchanging addresses with those unfamil- iar with X.400 O/R-addresses, a longer self-explanatory form is more appropriate, as discussed in the section 'Guidelines for Business Cards' at the end of this recommendation. Examples of the Recommended Notation ------------------------------------ C=de; ADMD=dbp; PRMD=gmd; OU=darmstadt; S=grimm C=fr; ADMD=atlas; PRMD=aristote; O=inria; OU=mirsa; S=huitema C=gb; ADMD=gold 400; PRMD=uk.ac; O=rutherford; S=craigie; G=jim Definition of the Notation -------------------------- The notation takes the form: <keyword>=<value>; <keyword>=<value>; ... <keyword>=<value> where <keyword> can be: C Country name ADMD Administration management domain name X121 X121 address (network address) T-ID Terminal identifier T-TY Terminal type PRMD Private management domain name O Organisation name OU Organisational unit name UA-ID Unique user agent identifier (numeric user identifier) CN Common name S Surname G Given name I Initials GQ Generation Qualifier Note: 1. Keywords and their values should be written in hierarchically descending order starting with country name. (C>ADMD>X121>T-ID>T-TY>PRMD>O>OU>UA-ID>CN>S>G>I>GQ). 2. Organisation Units are written in their natural hierarchically descending order (i.e. OU1>OU2...>OUn). 3. Keywords with empty values are omitted. 4. No distinction is made between upper and lower case although key- words in upper case and their values in lower case gives a clearer display. 5. Consecutive spaces inside <value> are interpreted as a single space. Leading or trailing spaces inside <value> along with all other space characters are considered as insignificant. 6. No keyword abbreviation is given for the personal name attribute since it is more completely described by the 4 attributes: S,G,I and GQ. Why use the recommended notation? --------------------------------- Agreeing to use a single notation for expressing X.400 addresses has the obvious result of simplifying exchange of addresses for people who should not have to be knowledgeable about the internal structure of X.400 messages. Some reasons for selecting the recommended notation defined in this paper are outlined below. * The keywords match those defined in recommendation RFC 987 (Mapping between X.400 and RFC 822). RFC 987 will play an important role in the migration phase towards X.400 and consistent use of keywords were chosen to minimise any confusion. * Descending order of keywords (C>ADMD>X121>T-ID>T-TY>PRMD>O>OU>UA-ID>CN>S>G>I>GQ) gives the most natural order for organisational units (O>OU1>OU2...>OUn). In addi- tion, descending order seems to be preferred by the members of stan- dards bodies who have used this order in their examples of X.400 addresses. * Semicolon (;) was chosen as a separator since, unlike slash (/), it is unlikely to cause conflict with characters forming part of a key- word value and comma (,) is often used as a separator in a list of addresses. * The notation is brief, complete, unambiguous and simple to under- stand. Formal Description: ------------------- DEFINITIONS ::= BEGIN --- An address of X.400 standard attributes is represented by a --- hierarchically descending ordered list of Standard Attribute --- Value Assertions. --- List of Standard Attribute Value Assertions: SAVAList ::= SAVA | SAVA ";" Spaces SAVAList --- Standard Attribute Value Assertion: SAVA ::= KeywordRepresentation "=" ValueRepresentation KeywordRepresentation ::= "C" | "ADMD" | "X121" | "T-ID" | "T-TY"| "PRMD" | "O" | "OU" | "UA-ID" | "CN" | "S" | "G" | "I" | "GQ" ValueRepresentation ::= PrintableCharacter | PrintableCharacter ValueRepresentation | empty Spaces ::= Space | Space Spaces | empty Space ::= SPACE | TAB | CR | LF --- No formal end of SAVAList is defined here. The start and stop --- delimiter of a SAVAList must be made clear by the context. --- (It is considered to be outside the scope of this description). END Domain Defined Attributes ------------------------- Domain defined attributes are not standard attributes and will not nor- mally form part of an X.400 address. They are used to express non-X.400 addresses. As some implementations of X.400 are unable to generate domain defined attributes their use should be avoided however when no X.400 address with standard attributes is possible, domain defined attributes can be written after any general attributes with the nota- tion: DD.<type>=<value>; DD.<type>=<value>; ... e.g. C=us; ADMD=xyz; PRMD=gw; DD.rfc-822=user(a)subdomains.domain C=nl; ADMD=abc; PRMD=gw; DD.uucp=host!user C=gb; ADMD=gold 400; PRMD=gw; DD.jnt-mail=user(a)domain.subdomains (Note that '@' is not a valid character for X.400 attribute values and is replaced by '(a)') The simple <keyword> = <value> notation has been extended to <keyword>.<type> = <value> since domain defined attributes (unlike standard attributes) are composed of a type as well as a value. Alternative Notations --------------------- For technical or historical reasons you may find X.400 addresses writ- ten in alternative notations. These are not recommended notations but are mentioned here with the aim of clarifying their interpretation. Most alternative notations follow the idea of using keyword expressions (keyword = value) but with many variations in the keywords used and the separator/delimiter between the expressions. Some alternative keywords you may need to understand are: Country name C CO COUNTRY CTN Administration domain name ADMD A ADM X121 address X121 X Terminal identifier T-ID T Terminal Type T-TY TT Private domain name PRMD P PMD PRI Organisational name O ON ORG Organisational unit name OU OU1 OU2 ... OUN Unique UA identifier UA-ID U Common name CN COM Surname S SN SUR Given name G GI GN GIV Initials I IN INI Generation Qualifier GQ GE GEN Domain defined attributes, DDV type XXX DD.XXX D.XXX DDT Numeric User Identifier NUS Network Address for telex TLX teletex TTX facsimile FAX videotex VTX Alternative Separators/delimiters you may see are: ";" "/" "," Keywords are sometimes expressed in ascending order, rather than the preferred hierarchically descending order (C>ADMD>X121>T-ID>T-TY>PRMD>O >OU ..). You should note that in ascending order the organisation units should be interpreted with the least significant appearing first (OUn...<OU2<OU1<O). You may therefore see the recommended address notation: C=ch; ADMD=arcom; PRMD=ski; O=zermatt; OU=chairlift; S=mouse; G=mickey written in some of the following ways: /C=ch /ADMD=arcom /PRMD=ski /O=zermatt /OU=chairlift /S=mouse /G=mickey C=CH; A=ARCOM; P=SKI; O=ZERMATT; OU=CHAIRLIFT; S=MOUSE; G=mickey G=mickey, S=mouse, OU=chairlift, O=zermatt, PRMD=ski, ADMD=arcom, C=ch CO=ch; ADMD=arcom; PRMD=ski; ON=zermatt; OU1=chairlift; SN=mouse; GN=mickey Guidelines for Business Cards ----------------------------- Since business cards are mass produced, it might not be so important that the address is short to write, and the cards may be seen by a wide range of people, not all of them familiar with the short hand notation described in this recommendation. A longer form of X.400 address may then be more appropriate. This longer form should be self-explanatory so there is no need to define a precise format, however some general guidelines are: * choose attribute names which are obvious and unambiguous * clearly separate attribute names from their values * print attributes in descending order (i.e. country code first) so that the organisational units appear in their natural sequence. If attributes are printed in ascending order and include more than one organisational unit, the least significant should appear first (...OU2<OU1<O). Below is an example format suggested, for use on the back of a business card, by the UK research community. Country GB ADMD Gold 400 PRMD UK.AC Organisation Rutherford Surname Bloggs Given-name Joe
schicker@clients.switch.ch (Pietro Schicker) (01/25/91)
Stef, CCITT is currently working on a recommendation specifying how to represent X.400 O/RAddresses on business cards. It includes the elements already present in the RARE document but adds all the others defined for the various X.400 address forms (e.g., for postal delivery). One difference I noted: the keyword for ADMD is "A", the one for PRMD is "P". Cheers - Peter
stef@ICS.UCI.EDU (Einar Stefferud) (01/25/91)
Hi Peter -- I would lobby for ADMD and PRMD over A and P, but I don't think the world will come to a stop on this issue. My preference is based on the probabilities of an error in use due to the greater ambiguity of A or P vs ADMD or PRMD. In the end, users are going to need to know that A means ADMD and P means PRMD, so what is the point of saving the ink and real estate for 3 characters in each? Cheers...\Stef
Stef@ICS.UCI.EDU (Einar Stefferud) (01/26/91)
Hello Maria -- The fact that various instances of A and P can be found in various 987 tables and other cases does not diminish the logic that A and P are more ambiguous that ADMD and PRMD when written on a business card or on a list of attendees addresses at a meeting, or where/when-ever. The issue is actually quite minor, but then, so is the cost of the ink and the business-card-real-estate required to carry the addtional 3 characters in each attribute name. I don't quite see why the standards bodies should suddenly become so concerned with trading terseness and brevity for clarity when it comes to printing other people's business cards. They cerainly don't take this (conservation oriented) position when it comes to counting the characters in PDUs that consume bandwidth in their protocols? Anyway, I am only trying to highlight the relationship between clarity of understanding of the mass of users and the potential savings (of ink and paper) to be achieved by using more cryptic codes. Cheers...\Stef
dimou@cernvax.cern.ch (Maria Dimou) (01/26/91)
There is a RARE WG1 recommendation for short hand address notation (Ref WG1-MHS-89.02.14). There it is clearly stated that ADMD and PRMD should not be further abbreviated. However, I 've seen documents, RFC 987 tables and X.400 products' user interfaces where this rule is not kept. Cheers - maria > > Hi Peter -- I would lobby for ADMD and PRMD over A and P, but I don't > think the world will come to a stop on this issue. My preference is > based on the probabilities of an error in use due to the greater > ambiguity of A or P vs ADMD or PRMD. In the end, users are going to > need to know that A means ADMD and P means PRMD, so what is the point of > saving the ink and real estate for 3 characters in each? Cheers...\Stef > -- Maria Dimou CERN CN/CS CH-1211 Geneva 23 Switzerland Email : dimou@cernvax.cern.ch X.400 : C=ch; ADMD=arcom; PRMD=cern; O=cern; OU=cernvax; S=dimou; Tel. : +41-22-7673356
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (01/28/91)
Stef, Maria, You should not forget the original reason for the insistance on ADMD and PRMD in the RARE notation, i.e. lobbying by the authors of RFC-987 so that exactly the same abbreviations are used in 987 and RARE short-hand format. This is only remotely related to clarity; in fact, if one was consistant, one should either ban all single letter abbreviations, including "C", "O", "S" and "G", or allow also a single letter abbreviation for "A" and "P". Moreover, the "clarity" of the codes "ADMD" and "PRMD" is far from obvious. It is most clear for users which are very familiar with the standard; it is just a syntactic token for the plain users. Christian Huitema PS. Our RFC-987 code is already geared to swallow both "/ADMD=" and "/A=" notations, under the general "be generous with what you accept" rule...
pays@mars.emse.fr (Paul-Andre Pays) (01/28/91)
Stef
I am really surprised by your campain against A and P (in place of ADMD
and PRMD). I used to see your messages for real "causeS" or for
authoritative statements.
Why this fight against a proposal and concern about such a secondary
item?
kAt this level the only imporatant thing is to aggree
on one (only one) commoly accepted and used representation.
Your arguments about ADMD "readability" fall short.:
Is
S=pays; OU1=mars; O=emse; P=emse; A=Atlas; C=FR;
less readable (understandable) than
C=FR/ADMD=ATLAS/PRMD=emse/O=emse/OU=mars/S=pays/
Either the user has a minimal knowledge of what is an ORaddress (thus no p
problem) or for him it is a mere convention (but that will be used
as such in the user manual of his prefered X.400 product).
A novice or dumb user will soon no longer manipulate any ORAddress
but Directory names.
Besides you should remember that all of us are not american
C is not really nice to remind "pays" (country in french)
we don't mind it. It is a convention.
Why not expend O to ORG?
My own point of view is
1. only the fact that there is ONE convention is important
2. I prefer personaly the A and P notation but I will not
fight for this.
-- PAPdimou@cernvax.cern.ch (Maria Dimou) (01/28/91)
I agree with you Stef and I think it is fortunate that the RARE recommenda- tion coincides with what you say (ADMD and PRMD instead of A and P). It is true that RFC 987 entries are not a problem. They are only seen by the MTA manager , who is supposed to know well enough not to be confused. The user interfaces are more important, because they can drive users away from X.400, which I understand and sympathise (with the users :-)) Cheers Maria Dimou CERN CN/CS CH-1211 Geneva 23 Switzerland Email : dimou@cernvax.cern.ch X.400 : C=ch; ADMD=arcom; PRMD=cern; O=cern; OU=cernvax; S=dimou; Tel. : +41-22-7673356