eppenberger@verw.switch.ch ("Urs Eppenberger") (10/18/89)
You can't discuss a format for the representation of O/R-addresses without following, what the software developpers are selling NOW. Most user interfaces are menu or window oriented. To enter an address the naive user is prompted like the following example: Country : Administration Domain : Private Domain : Company : Subdivision : Surname : Givenname : The main criteria for a useful representation of an O/R address is now: IS THE NAIV USER ABLE TO FILL IN THE ABOVE FORM WITH THE INFORMATION GIVEN ON THE BUSINESS CARD ? Here are the two examples from Jacob Palme: C=GB;ADMD=Gold 400;O=Nottingham University;S=Smith;G=Hugh /Hugh/Smith//"Nottingham University"//"Gold 400"/GB Now ask your secretary to fill it in. This test will give you the answers. Stop theory! Kind regards, Urs Eppenberger, SWITCH
JPALME@com.qz.se (10/19/89)
>X-Originator: Jacob Palme QZ <JPALME@com.qz.se> > From: Urs Eppenberger <eppenberger@verw.switch.ch> > > You can't discuss a format for the representation of O/R-addresses > without following, what the software developpers are selling NOW. > > Most user interfaces are menu or window oriented. To enter an address > the naive user is prompted like the following example: > > Country : > Administration Domain : > Private Domain : > Company : > Subdivision : > Surname : > Givenname : > > The main criteria for a useful representation of an O/R address is now: > > IS THE NAIV USER ABLE TO FILL IN THE ABOVE FORM WITH THE INFORMATION > GIVEN ON THE BUSINESS CARD ? > > Here are the two examples from Jacob Palme: Concise RARE format: C=GB;ADMD=Gold 400;O=Nottingham University;S=Smith;G=Hugh Concise format: /Hugh/Smith//Nottingham University//Gold 400/GB It is obvious, that with a user interface which uses the form-fill-in method, the Concise RARE format is better (but not ideal). The Concise format requires in practice that all user interfaces are able to input OR-names in that format. (That format need not be the normal or only way of inputting addresses, but one possible way of inputting them.) I do not agree with you that this argument is the only argument in choosing the best concise format. There are other arguments for other alternatives. By far the most important argument, in my opinion, is the risk that X.400 will never become accepted, will become a dead horse, like Teletex, because of the complicated OR-name structure. Compare to telephone numbers, which have been successful for both telephone and fax. The reason many manufacturers today have implemented a form- fill-in interface is that this is the only reasonable solution when no standard for a concise format exists. Your arguments are a kind of catch 22 or "which was first, the hen or the egg". If there is no standard for or-name priting, we must use form-fill-in format in user interfaces. If we use form-fill-in format in user interfaces, and nothing more, then no user-friendly user interface can be defined. Conclusion: We cannot escape from this deadly loop by some kind of bootstrapping.
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (10/19/89)
Jacob, Your concerns that X.400 "will never become accepted, will become a dead horse, like Teletex, because of the complicated OR-name structure" is indeed very reasonable. I remember having once advocated a plain numerical format for ORNames -- sort of (C/A/PRMD/UA-ID) -- for it would be in any case simpler than what exist today. However, if your idea is to push an user friendly form for ORNames, then the obvious solution is to use precisely what is considered as most user friendly today, i.e. RFC-822, in a positional format of: G.S@(OU.)*O.PRMD.ADMD.C with a strict obligation of noting all hierachical tokens, i.e ADMD even if it can be guessed, or O even if it is missing. In short, without the mappings. That would lead us to write strings like: Christian.Huitema@mirsa.inria.atlas.FR grimm@darmstadt..gmd.dbp.DE eppenberger@verw.switch.switch.arcom.CH Indeed, we will need a more complex convention for: steve.kille@cs.ucl.uk\.ac.gold_400.GB in order to note blanks and to escape dots. But that is a small cost. But, if you really want a "string" format that can be understoud by all (well, a large number of) interfaces, then RFC-822 is the obvious candidate. Christian Huitema PS. However, Teletex used a very simple numerical address format
piet@cwi.nl (Piet Beertema) (10/20/89)
By far the most important argument, in my opinion, is the risk that X.400 will never become accepted, will become a dead horse, like Teletex, because of the complicated OR-name structure. Exactly! But that's nothing new. Compare to telephone numbers, which have been successful for both telephone and fax. And with RFC822 addresses for that matter.... Piet
jpo@computer-science.nottingham.ac.UK (Julian Onions) (10/20/89)
X-Phone: +44 602 484848 (x 3595 or 2862) An interesting discussion the friendly O/R-name - can't help feeling we've been here before (several times). Two things to keep in mind.. 1) What do you do with weird addresses that include things like presentation addresses - I'm sure some implementor will look at the spec and say "wow - just what I need, we'll make presentation addresses mandatory in our system!" - suddenly a whole chunk of the community are not represented as the carefully learnt rules for business card address are not capable of representing presentation addresses. Presentation address are an extreme example - but, say, teletex is not unreasonable - similarly common-name is likely to be used I imagine. 2) On a similar point, what about repeated attributes - the concise format won't deal with multiple OU's will it? Or how about multiple OU's and just the surname + initials - how do you tell the difference. O/R-names are inherently key/value based - if you remove the key there are endless ways to cause confusion. As far as I can see - this is a short term problem anyway - surely X.500 will make this whole problem go away? I just give my postal address on the business card and let the user or mta look up the X.400 address. It's probably better to look at concise formats for X.500 names than X.400 names (which were never really intended for users anyway). It might just be worth picking the worst possible format as an interim to encourage a quick transition to use of directories. (a similar argument was suggested several times with RFC-987 I seem to remember - although I don't believe it was really taken seriously - despite the output!) Julian.
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (10/23/89)
Jacob, I was proposing table free RFC-987 like addresses, which would yeld something like: Internet: christian.huitema@mirsa.inria.fr X.400: christian.huitema@mirsa.inria.atlas.FR on a business card. This should have been obvious from examples like: grimm@darmstadt..gmd.dbp.DE eppenberger@verw.switch.switch.arcom.CH steve.kille@cs.ucl.uk\.ac.gold_400.GB which I gave in the message. It should be fairly clear to anyone that the addresses should be noted in a way that does not involve tables.. However, this was merely a counter-example to yours, showing ``another short-hand format'', which would appear much more natural in our environment than your original proposal. Apart from depending a lot from different local tradition, all these ``concise formats'' suffers the same draw backs, i.e.: 1. Requiring a positional syntax implies that one selects a ``standard address form'' (given.name@ou.o.prmd.admd.c in the example), and that one resorts to special tricks like double separators or blank fields for ``deviant addresses'', e.g. when some field is ``missing''. This is not user friendly. 2. The most used form includes a Personal name and some organisational designation. As the personnal name can include several tokens, and the organisational designation a variable number of OUs, one need a special construct (@ and . in RFC-987 style) for the delimitation. This can be difficult to explain if the construct is not very clear; the "/" and "//" of your example is in my opinion difficult to explain to users. 3. The less used forms include rare fields, like X.121 addresses, A ids or DD attributes. There is no way to incorporate them into a positional syntax, and one must resort to a key-word syntax. 4. Positional syntaxes, by nature, are less user friendly than keyword syntaxes. For example, users should be free to enter the addresses in both little endians and big endians fashion, depending of their mood. 5. The claimed conciseness is not such a big winner. For example, the difference between: <grimm@darmstadt..gmd.dbp.DE> and <S=grimm;OU=darmstadt;PRMD=gmd;ADMD=dbp;C=DE> is only 15 chars. The price is not so large, if it results in less confusion. Actually, the only relevant criticsm which was expressed in this discussion is that the keywords used in the RARE syntax are too terse, and that "Surname" would be preferable to "S", etc. Chrsitian Huitema
JPALME@com.qz.se (10/23/89)
>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>
Do you mean to replace O/R-names with RFC822 names? Or to
use some kind of RFC987 algorithm for creating a short-hand
notation for O/R-names? If the latter, then the general, table-
free variant of RFC987 is about the same as the RARE format,
and the shorter table-dependent version of RFC987 only works
if all interpreters have the same, large, tables, which is
a large problem.
JPALME@com.qz.se (10/23/89)
>X-Originator: Jacob Palme QZ <JPALME@com.qz.se> > From: Julian Onions <jpo@computer-science.nottingham.ac.uk> > > 2) On a similar point, what about repeated attributes - the concise format > won't deal with multiple OU's will it? Or how about multiple OU's and just > the surname + initials - how do you tell the difference. O/R-names are > inherently key/value based - if you remove the key there are endless ways to > cause confusion. Yes, the concise format can handle multiple OU-s, since it has "/" between the OU-s, and "//" between the O/OU/OU group and the other groups. The DFN format with OU-s without O can also be handled, but will not be so neat, the format will be "-"/OU1/OU2...
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (10/23/89)
I have been silent on this topic about as long as I can stand. I find the concise format to be entirely non-intuitive and vitually useless in terms of any of my serious mail-using clients. They would never be able to cope with it in day-to-day life. It might have some kind of use in tables that are never seen by humans. Best...\Stef
grimm@darmstadt.gmd.dbp.de (Ruediger Grimm) (10/24/89)
To: Jacob Palme <C=no;PRMD=se;O=qz;OU=com;S=JPalme>
I would like to encourage Jacob to continue in his efforts to
define a concise address notation format.
The RARE format demands a basic knowledge of
the attribute structure of addresses. It enables to express any portion
of an address from a single attribute up to a full address and will
therefore always be needed regardless of any shorter or longer format
of address notation. However, from the users point of view, I don't see
a necessity of a knowledge of the address structure, in that we have
computers to do the job. With paper mail it is common to write
To: Ruediger Grimm
Jahnstr. 45
D-6100 Darmstadt
B.R.Deutschland
To: Fatuma Dakinigbe
B.P. 284
Cotonou
R.P.Benin
The second attribute in the examples above are different, one is a street,
the other one is a post box. The local postmasters (in Darmstadt and in
Cotonou, resp.) will know, what kind of attribute is following.
This kind of thoughts will not be solved inside of X.400, of course,
nor perhaps in X.500 (who was it to ask for X.600 as a general problem
solver for X.500?). However, this gives a direction of what we shall expect
from future user interfaces.
Jacob's notation is a step in this direction. If the rules become less
strict in the future, and the MTA's more intelligent, both
/Ruediger/Grimm//Darmstadt//GMD/DBP/DE, and
/Ruediger/Grimm//Darmstadt/-//GMD/DBP/DE
might make the message find its correct route.
Wouldn't it be a good idea, to ALLOW for attributes in RARE-format
inside the concise format? Such like:
/Ruediger/Grimm//OU=Darmstadt//GMD/DBP/DE
RFC987 fans might recognise something in it.
With THIS perspective in mind, it becomes a minor question, which
delimiter would be best. I find the slash one of the ugliest possiblities,
but I also see Jacob's reasons for the slash.
Don't forget, that slashes can be part of an attribute value.
Why not the semicolon?
Greetings --- Ruedigerdavecb@nexus.yorku.ca (David Collier-Brown) (10/24/89)
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) writes: | I was proposing table free RFC-987 like addresses, which would yeild something like: | Internet: christian.huitema@mirsa.inria.fr | X.400: christian.huitema@mirsa.inria.atlas.FR | on a business card. This should have been obvious from examples like: [...] Apart from depending a lot | from different local tradition, all these ``concise formats'' suffers | the same draw backs, i.e.: | 1. Requiring a positional syntax implies that one selects a ``standard | address form'' (given.name@ou.o.prmd.admd.c in the example), and that | one resorts to special tricks like double separators or blank fields | for ``deviant addresses'', e.g. when some field is ``missing''. This is | not user friendly. A slightly more common dirty trick is the distinguished or annotated entry in a positional syntax: Orville Torpid, Ork University (Steacie 103), 4700 Keele St., Toronto, Ontario, M3J 1P3. In my mailing address, the extra "(Steacie 103)" indicates that the formal address is not complete, but instead requires another more specific address field to use as one progresses from Toronto -> 4700 Keele -> the person. In this particular case its really a replacement for a department name, but stated in postal-delivery terms for the poor chap who pushes the wagon. An annotated entry is one which rather resembles a keyword entry stuffed into the middle of the above positional syntax: "Attn: Fred Friendly" in a company's address would be a good example. Note in both cases extra syntax is necessary to add the information, but nothing extra is required to indicate its absence. I claim that this is desirable, to avoid empty placeholders like // and .. | 3. The less used forms include rare fields, like X.121 addresses, A ids | or DD attributes. There is no way to incorporate them into a positional | syntax, and one must resort to a key-word syntax. Agreed! Positional syntax is simple, but inherently either limited or voluminous and hard to remember. | 4. Positional syntaxes, by nature, are less user friendly than keyword | syntaxes. For example, users should be free to enter the addresses in | both little endians and big endians fashion, depending of their mood. I almost agree. Alas, this could be applied to surface mail addresses, with considerable confusion resulting. And not just in the mind of a sorter (who is probably a machine anyway), but in the mind of the recipient, the dead letter office, etc. As you can see from the above, I incline toward a positional notation resembling surface mail, with a strong and obvious ordering and a simple grammer specifying when one can insert or delete entries, and what one does with entries which you're not sure what to do with. This rather resembles Ada, with its "foo(bar,zot,grud=>2)". Not by **any** means perfect, but usable. Using the .@ example, this might give an address form like christian.huitema@mirsa.inria.fr -- elided "atlas" or christian.huitema@mirsa.inria.atlas.fr -- full address or christian.huitema@mirsa.inria.something_or_other=atlas.fr -- annotated address I freely admit I find the last UGGGGGGGGLY. --dave (thats ok, **I'm** ugly) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
JPALME@com.qz.se (10/24/89)
>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>
The SMTP format, with the "@" character, has as an important
drawback that this character is defined as "nationally
defined" and thus is not the same in all countries.
Your arguments are all based on the idea that the user should
"understand" in X.400 terms an address. Certainly, if that
is the goal, then the RARE format is better.
The argument behind the concise format is that a user is not
interested in concepts such as "ADMD" or "Organizational Unit",
with their special meaning in X.400. A user is interested
in concepts like "GB" for Great Britain, "IBM Corp.",
"Christian", "Huitema" and prefers a minimum of other info,
and that info using a minimum of funny characters.
It is very difficult to make X.400 experts understand this
idea. To us, the X.400 concepts are so natural, that we cannot
easily understand that not everyone longs for the fantastic
opportunity of learning to understand them!!!
But let us wait and see what results the psychological tests
will show. They will be performed by the psychological research
laboratory of the Swedish Defense Research Agency, financed
by the Swedish Telecom. They will show who is right.
However, they will not include any SMTP-like format,
using "@" and ".". No one has until now proposed that
format, because of the problem with "@" not being an internationally
recognized format.
pays@emsesmc.emse.fr (Paul-Andre PAYS) (10/25/89)
Your remarks about the "attributes" users are interested with is right, however, are you aware that you are just using the justificatons (reasoning) for X.500 Directory name for which ADMD PRMD are of no relevance. If your concise notation is reorientated to be a concise simple way of giving Directory Names, then I am OK, BUT wait for X.500 to be available. If you still think of it as a short hand for ORaddresses (X.400 88), then I completely disagree with you, about the supposed user friendliness of the concise notation. 1. an address is an address within an addressing space (all attributes are of relevance, eg ADMD to indicate through which ADMD a user is to be reached) 2. positional paramters are awkward as soon they are more than a few 3. I am convinced that, even if they don't have to understand the detailed model and concept associated to each keyword, users . have to know to which keyword a value is associated with . will remind much more easily a keyworded name than a long multislashed string. We have to remind that we are only dealing with a temporary state (no Directory available) and that within 1 or 2 years we will be using directories: let addresses be adresses that can be used by skilled people push provider to provide nice personal "address book" facility enabling to use personal nicknames push for X.500 early install and operation prepare an easy notation for directory enquiries Regards, -- PAP
Harald.Alvestrand%vax.runit.unit.uninett@NAC.NO (Harald Tveit Alvestrand) (10/25/89)
Two bits' worth: - When Norsk Data's X.400 developers saw the RARE format, they JUMPED on it. They had delayed all work on "how to print" because they recognized that they could not set the standards in this field, and had many other things to do. - On this particular terminal, @ is an E with an accent. The RARE format is implementable and understandable.
list-redistribution%vax.runit.unit.uninett@NAC.NO (10/27/89)
>X-Originator: "list-redistribution%relay.CDNnet.CA" <list-redistribution%relay.CDNne >X-Originator: Jacob Palme QZ <JPALME@com.qz.se> I am not sure if either you or I are the best people to say what is "user-friendly". We may both of us be "blind" by our detailed knowledge of the O/R-name structure, and we may both find it difficult to understand how non-experts in this area feel and react.
solomon@CS.WISC.EDU (Marvin Solomon) (10/29/89)
(I just know I'm going to regret jumping into this debate, but here goes...) Perhaps part of the problem is that use of the term "address" leads people to look to the postal service for analogies. In fact, the "O/R address" is much more nearly analogous to a telephone number. In the United States, it's been about 30 years since we banished letters from phone "numbers" and settled for a uniform 10-digit numbering system, and so far as I know, so has the rest of the wold. If you want a concise format for writing O/R addresses on business cards, the only criterion for "user friendly" is how hard it is to transcribe from the card to your favorite mail user interface. To this end, it would appear that brevity is paramount. It would also appear that inclusion of punctuation and whitespace, which people are in the habit of considering to be relatively insignificant, should be avoided. If I have to transcribe the phone number "1 + (608) 262-1204", it's clear to me that I have to get every single digit exactly right, but the rest of the characters can be safely ignored. Punctuation can't be avoided entirely, but things like double and tripple slashes are likely to cause problems. Multiple consecutive periods (full stops), are worse. Significant whitespace should be avoided at all costs! I have long thought that one of the biggest mistakes in the design of 822 was that message headers are all printable ASCII. That decision has seriously impeded the development of decent mail user interfaces, since it led people to the mistaken conclusion that they didn't need any special tools to display messages (or even compose them!)--any old text editor would do. The user-chummy nature of O/R addresses leads to similar mistaken conclusions. I'm no more likely to guess the O/R name of someone in France than I am to guess his phone number. If I want to call Cristian, I I will either have to get his phone number from him over some out-of-band channel (e.g. in a letter-head -- or an email message :-), or from directory assistance. X.400 mail interfaces that provide nice menu-oriented entry of O/R addresses do more harm than good. If I get an O/R address on a business card and my mail interface allows textual entry of O/R addresses, there's at least some chance that I will correctly transcribe the string and that my mail interface program will be able to parse it. But if all I have is a "friendly" fill-in-the-form interface, *I* will have to parse it, to figure out which piece of it is the ADMD, which piece is the GenerationalQualifier, and so on. Much of the recent discussion on this list seems to be trying to figure out how make the concise format sufficiently user-friendly that this this parsing process will be easy for naive users. That's patently ridiculous. I close with a joke I heard recently. Stop me if you've heard this... X.400 novice: Someone who has no idea what an ADMD is. X.400 expert: Someone who knows what an ADMD is. X.400 guru: Someone who admits he has no idea what an ADMD is. Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu, uwvax!solomon
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (11/06/89)
Vint,
This discussion has merely an historical relevance, for I dont think
that anybody is likely to subvert RFC-822 by anything but perhaps X.400
for usage within the Internet. However, when you state that "it would
be awkward to receive a communication of the form:
To: 357-1234
CC: 895-7896,1-800-456-7892,011-44-236-4456"
you may be interested to note that one of the biggest messaging
network, perhaps the most extended in the world, is using something
very similar. SITA carries messages all over the world for the airlines
companies, and a message looks like:
destinations(to)|QAZZTYC ZTMNOOQ
source + ref |.PARPCXS 123456
STX |
text |<and here comes the text>
ETX |
The fact that it is widely used seems to indicate that users can cope
with ``abstract addresses'', 7 letters in this case...
To come back to your example, you are certainly aware that the header
could as well be a bit more user friendly, e.g.:
To: Joe Smith <357-1234>
CC: Pieter Mueller <895-7896>,
Michel Dupond <1-800-456-7892>,
Felipe Ramirez Escobas <011-44-236-4456>
This, by the way, looks very much like a formatted telex header.
Christian Huitemapiet@cwi.nl (Piet Beertema) (11/07/89)
SITA carries messages all over the world for the airlines companies, and a message looks like: destinations(to)|QAZZTYC ZTMNOOQ source + ref |.PARPCXS 123456 STX | text |<and here comes the text> ETX | The fact that it is widely used seems to indicate that users can cope with ``abstract addresses'', 7 letters in this case... Nice example, Christian, but not a good one in this context: in any particular environment (e.g. in the world of airline companies) certain abbreviations or mnemonics are meaningful and they show up in almost each and every application there. Under such circumstances users will learn quickly to cope with what you refer to as "abstract addresses", but which in their environment are composed of very meaningful elements. The "concise format" on the other hand was meant to be used universally, by people from vastly different "environments". And there Vint's example and conclusion do indeed apply. Piet
mark@cblpf.att.COM (Mark R Horton) (11/16/89)
> Why not reference a telephone-type number to the X.500 services. > Everyone knows how a number relates to a person with phones and faxen. > For this to work, we need the number defined in the same way internet > numbers are chosen and telephone numbers supplied: centrally. It's an interesting idea, but it has some serious problems. For one thing, there is no notion of a universal email number. Even the X.121 addresses people were talking about only address down to the machine level, and they don't work if your machine isn't on the worldwide X.25 internetwork. For another thing, while it is certainly true that people are used to (resigned to?) numbers for telephone, when I receive mail I would certainly prefer to read an X.400 address than a number when I'm trying to figure out who the mail came from. > "Why do I have to have an under_score between my names?" > "What does an at-symbol look like and where is it on MY keyboard?" Funny, our users (including secretaries) don't seem to have this problem. If you give them a fixed character string, they understand that if they type that exactly, it will get there. Unfortunately, X.400 addresses are not fixed character strings, and that, I think, is part of the problem. If you really feel that numbers are better than names, propose to your users that they start using 14 digit numbers for their paper mail instead of postal addresses, and see how they react. Mark
CERF@A.ISI.EDU (11/17/89)
Christian, Yes, Erik Naggum also makes the same points about the possibility of adding more identifying information. It would be nice to have a way to automatically bind the names and numbers (to minimize falsification?) - mostly to help recipients know to whom they may be replying. What about the problem of multiple recipients on the same number? (as in fax). Vint
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (11/17/89)
Binding back from numbers to names is likely to be difficult, as these numbers are not necessarily hierarchical, e.g. like the x.25 numbers with their three level hierarchy of country-site-subaddress. There is such a large fan-out on the second level of the heirarchy that one cannot apply DNS like navigation algorithms! On the other hand, if the name of the person is carried in the message, and if a directory is available, it is possible to check back from that name, e.g. read the "address" attribute for the name, and compare it with the value in the message. This will work even if the recipient has several addresses or if the addresses serve several recipients (just like fax). Christian
CERF@A.ISI.EDU (11/19/89)
It occurs to me (belatedly) that it would be helpful to have header lines include an explicit NAME field which is not the same as the ADDRESS of a recipient and that these field be linked. Yes, I know that the RFC822 format has the capability to reveal arbitrary strings of information which are distinguishable from the email address syntactically, but as these are treated as comments, not all mailers seem to retain and display the information. One could register a formal name and associate it with the address, the latter being used to deliver the message (just like postal or telephone numbers). Vint
sid@brambo.UUCP (Sid Van den Heede) (11/20/89)
> If you really feel that numbers are better than names, propose to your > users that they start using 14 digit numbers for their paper mail instead > of postal addresses, and see how they react. Don't laugh...Canada Post (I think they've changed their name to Mail Poste or something really descriptive like that) has done just that! They currently use a 6 character postal code, with alternating letters and digits. They have discussed the idea of extending it to 10 characters, with the result being that the postal code is the only thing you would need on an envelope!
bobf@lotus.UUCP (Bob Frankston, BFrankston) (11/20/89)
RFC-822 already has a facility for comments. Thus one can use the phone number/X.25 equivalent as the real address and include the name as a comment. Adding a separate name: field wouldn't work since the relationship between the comment and the mail address would not otherwise be retained. Of course, X.400 already keeps this information together in the O/R name. Full name: Bob Frankston
CERF@A.ISI.EDU (11/21/89)
Bob, I was not proposing a separate field in RFC822 which was unbound to the "address" - really, I think I was observing that having both attributes available, as in the X.400 O/R name was helpful. None of this makes me any more happy with the current X.400 O/R Name or the X.500 naming syntaxes, unfortunately. Vint
eskovgaa@uvcw.uvic.ca (Erik Skovgaard) (11/25/89)
Re. Canada Post:
No, they have not changed their name, but you cited the French name.
The postal addresses in canada are not going to be radically changed,
but as you have seen in the US there is a tendency to make the
postalcodes ("Zip" codes for you guys below the 49th) more
powerful - from the point of view of computers, that is.
Canada Post (Poste Canada in French) is currently proposing an
extension to the postal codes to enable sorting down to
individual buildings. But even their X.400 system will use
regular postal addresses - and O/R-names!
....Erik.