denise@priam.CERN (Denise Heagerty) (09/15/88)
Rather than respond individually to the comments so far, I would like
to answer the following questions:
1. Why should RARE recommend a notation?
2. What the notation is NOT intended to be?
3. What is the real issue?
1. Why should RARE recommend a notation?
-------------------------------------
A number of tightly linked research groups (e.g. Physicists) will soon have a
requirement to exchange their X.400 addresses and if no recommendation
exists will invent their own. Within Europe most of these user communities
come under the RARE umbrella so this offers a chance to limit the
possibility of many notations being invented. Clearly, a notation only
recognised in Europe is of limited value and probably limited lifetime
(see point 3).
Some immediate examples of where RARE already needs a recommendation:
o The RARE MHS Documentation (X.400 addresses for contacts).
o Attendence lists of meetings (at the last RARE Networkshop there was
a whole range of formats).
o X.400 address discussions where example addresses are quoted.
2. What the notation is NOT intended to be?
----------------------------------------
I think this is already clear to everyone, but just in case, the notation
is:
o NOT a recommendation for a business card
o NOT a recommendation for a user interface
The comments related to the user interface are relevant because
a). people will try to enter them directly
b). people tend to quote their addresses in the format they enter them.
3. What is the real issue?
-----------------------
----------------------------------------------------------------------
The Assumption: |
--------------- |
The assumption made in the DRAFT Recommendation is that there is NO |
standard user interface which naturally becomes the de facto notation |
for exchanging addresses. |
----------------------------------------------------------------------
Most commercial X.400 user interfaces I have seen use full-screen menus
to request the O/R Name attributes. The most popular mail networks for
high energy physicists (the user community I represent) are EARN/BITNET
and DECnet (i.e mainly VAX/VMS and IBM Mail systems). The most popular
small system is the Macintosh. Most (if not all of these) will have
full-screen menus for O/R name entry.
The counter argument to this is that UNIX systems which are popular in
many research communities will probably all accept RFC 987 syntax at
their user interface.
I believe the DRAFT Recommendation which has been proposed meets its intended
goal of being a short notation for scribling on bits of paper. It is
not intended to be a user interface because of the assumption that there
will not be a single user interface.
What we should now discuss is whether the basic assumption above is true.
-- Denise.mark@cblpf.ATT.COM (Mark Horton) (09/22/88)
> A mapping between the DRAFT Recommendation we are discussing here and any > X.400 user interface is totally outside the scope of the DRAFT > recommendation's objectives. > > o To simplify local X.400 User Guides which should define the mapping > between the recommended notation and the local user interface. Sure seems to me that the most effective way to simplify local user guides would be to recommend a standard way to write addresses. This does not mean to imply that the user interfaces of every X.400 mailer in the world would be standardized. Merely that the way in which X.400 addresses are written as single character strings (as opposed to, say, as screen forms, or some other representation) ought to be consistent where possible. > Either > 1). a critical mass agree that RFC 987 syntax will be used at a sufficient > number of user interfaces to make it a de facto X.400 notation. I think this is the case, and I hear a lot of people on this mailing list who seem to agree. The objections I'm hearing are not from people pointing out other de facto standards (as far as I'm aware, there are none) but from people concerned about perceived technical shortcomings of 987. In particular, the major objection seems to be that it's not obvious how to deal with blanks and slashes. I went back and looked at 987 to double check. It seems that blank is encoded as _ and that / is encoded as #s# and to encode _ you use #u# . Since slashes and underscores will be rare, you won't see many instances of #s# in addresses. Since blanks are more common, you will see a fair number of underscores. There are, of course, escapes to cover other characters in the syntax, such as = , and an octal escape to cover anything unforeseen. Mark
piet@cwi.nl (Piet Beertema) (09/22/88)
> All email addresses are single character strings. Not > arrays of strings; not forms; but strings, of printing, > nonblank, characters. -------- RFC822 does not say "nonblank": True. RFC822 allows a local-part to be a quoted-string which can explicitly include white space (pages 27, 11 and 10). However, your quote from pp 30/31 implicitly says you have to be VERY careful with such things: 6.2.4. DOMAIN-DEPENDENT LOCAL STRING The local-part of an addr-spec in a mailbox specification (i.e., the host's name for the mailbox) is understood to be whatever the receiving mail protocol server allows. For exam- ple, some systems do not understand mailbox references of the form "P. D. Q. Bach", but others do. The example on pp 30/31 focusses on de period, but how many mailers in use today on (e.g.) Unix systems will accept "John Doe"@domain", but will fail on "John Doe"@domain? Piet
steve@CS.UCL.AC.UK (Steve Kille) (09/26/88)
>From: mark@com.att.cblpf >To: ifip-gtwy@gov.llnl.tis, rare-wg1 <rare-wg1%uninett.unit.runit.vax@uk.ac.ucl.cs.nss> >Subject: Re: Response to comments on DRAFT/2 >Date: 21 Sep 88 21:12 +0100 >In particular, the major objection seems to be that it's not obvious how >to deal with blanks and slashes. I went back and looked at 987 to double >check. It seems that blank is encoded as _ and that / is encoded as #s# >and to encode _ you use #u# . Since slashes and underscores will be >rare, you won't see many instances of #s# in addresses. Since blanks are >more common, you will see a fair number of underscores. There are, of >course, escapes to cover other characters in the syntax, such as = , >and an octal escape to cover anything unforeseen. This is the mapping described in Appendix A. See 4.2.4 - item 4. "Use of this encoding is discouraged". This encoding was desgined for "old fashioned" (typically UUCP) RFC 822 systems, which could not handle the quoted string encoding. It should only be used by systems that really cannot avoid it. Steve