Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!orion.oac.uci.edu!ucivax!gateway From: mdb@esd.3com.COM ("Mark D. Baushke") Newsgroups: comp.protocols.iso.x400.gateway Subject: RFC987 gateways and illegal RFC822 domainname characters Message-ID: Date: 7 Dec 90 19:32:34 GMT Organization: 3Com Corp., Santa Clara, CA. Lines: 69 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: comp-protocols-iso-x400-gateway@ames.arc.nasa.GOV ReSent-To: ifip-gtwy@ICS.UCI.EDU I apologize if this is not the appropriate forum for this messge. Please feel free to forward this posting to the appropriate group or to tell me where I should raise my concern. I am not normally involved with X.400, but I have been noticing a disturbing trend in how some X.400 address are mapped into RFC822 addresses. The trend is to take name components which contain spaces (eg, /O=Field Service/), and either map them into underscore (_) characters or actually leave them as spaces in the domain address. That is, the address was mapped into something like Joe.User@somewhere.Field_Service.that.company.country or in one case an non-repliable address for which the postmaster suggested an address like: Joe.User@somewhere."Field Service".that.company.country and noted that an underscore could be used for the space if my company could not use quotes in a domainname, but that the underscore form of the address would be going away soon. I have sent individual messages to the postmasters in charge of such gateways for their consideration. I hope that they choose to 'fix' their sites by converting to only legal characters in domainnames. Some gateways seem content to take either underscores (_) or dashes (-) in an RFC822 address and map them to spaces in the X.400 addresses. That direction of mapping is fine. It is a case of being liberal in whay you accept. You may ask why I believe it is technically 'illegal' to have either an underscore or a space in a domainname. It is because I do not see them in the set of characters permitted in a domainname as defined by the RFCs. What follows is fragments of what I believe to be the appropriate RFCs. If I have missed something, please feel free to point it out to me. In RFC 1123, | 2.1 Host Names and Numbers | | The syntax of a legal Internet host name was specified in RFC-952 | [DNS:4]. One aspect of host name syntax is hereby changed: the | restriction on the first character is relaxed to allow either a | letter or a digit. Host software MUST support this more liberal | syntax. | | Host software MUST handle host names of up to 63 characters and | SHOULD handle host names of up to 255 characters. In RFC 952, | ASSUMPTIONS | | 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up | to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus | sign (-), and period (.). Note that periods are only allowed when | they serve to delimit components of "domain style names". (See | RFC-921, "Domain Name System Implementation Schedule", for | background). No blank or space characters are permitted as part of a | name. No distinction is made between upper and lower case. The first | character must be an alpha character. The last character must not be | a minus sign or period. [...] Thank you for your consideration of this matter, -- Mark D. Baushke mdb@ESD.3Com.COM