harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (08/10/90)
Organization: ELAB-RUNIT, SINTEF, Norway
References: <9008081714.AA10475@cbmark.cbcc.att.com>
As a member of RARE WG1, which is more or less responsible for putting the
format forward, I think I can state that the reason ; was chosen for a
delimiter
and not / was that / is a PrintableString character, while ; is not.
This means that in order to use /, we have to define a quoting syntax, while
using ; quotes would not be needed.
Of course we will have to rework that in order to write down 88 version
T.61 addresses....
Harald Tveit Alvestrand
Postmaster, UNINETTmark@cbmark.cbcc.att.COM (Mark Horton) (08/11/90)
>As a member of RARE WG1, which is more or less responsible for putting the >format forward, I think I can state that the reason ; was chosen for a >delimiter >and not / was that / is a PrintableString character, while ; is not. >This means that in order to use /, we have to define a quoting syntax, while >using ; quotes would not be needed. > >Of course we will have to rework that in order to write down 88 version >T.61 addresses.... Not to mention UNIX systems. Since ; is special to the UNIX shell, addresses with ; in them simply can't work on UNIX systems. (You can quote things to one level of shell, but the quotes will be stripped off and the next time a shell sees it, such as on a remote machine or in an internal mail switch handing off to an X.400 gateway) the semicolon will split the line into two separate shell commands. If you're willing to have a syntax that can't be used on UNIX systems, the semicolon syntax is very attractive. However, in the real world UNIX systems account for a very significant fraction of existing networks and email systems, and a standard they cannot implement will probably wind up being ignored or replaced with one that can be used. Quoting mechanisms are unavoidable in the real world. / may be a printable character, but it will be a rare one, so there won't be much inconvenience imposed by making it be quoted. Mark
Stef@nrtc.northrop.COM (Einar Stefferud) (08/11/90)
I think we should not go too far afield in this discussion of Printable Formats designed for human use on business cards and such. We certainly do not want to use the UNIX Shell Command Line restrictions as a requirement for all printed forms of ORAddresses! We also do not want to use the ASN.1 BER encoded form on our business cards either, and that is equivalent to what Mark refers to when he mentions how UNIX Mail (UUCP) actually feeds all Envelope (P1 level) addresses through a UNIX shell on each relay hop. The fact that UNIX Mail (UUCP) is braindamaged on this score should not be a factor in deciding how to print X.400 names and addresses on business cards and letter heads, or in terminal screens when entering them into message composition processes, or when displaying received messages. Cheers...\Stef
pays@mars.emse.fr (Paul-Andre Pays) (08/11/90)
don't make the confusion betweeen a business card orieneted form and a somehow "user oriented" interface. the ";" are meant for business card; no-one never said it should be used for UNIX or not UNIX based user interfaces..... please dont confuse the two very different purpose -- pap . ..
grimm@eiche.darmstadt.gmd.dbp.de (Ruediger Grimm) (08/13/90)
> > As a member of RARE WG1, which is more or less responsible for putting the > > format forward, I think I can state that the reason ; was chosen for a > > delimiter > > and not / was that / is a PrintableString character, while ; is not. > > This means that in order to use /, we have to define a quoting syntax, while > > using ; quotes would not be needed. > > I must be missing something here. > / and ; both *are printable* characters ( ASCII code 47 and 59 ). > > I believe / has more visual contrast as opposed to ; that 'blends' with the > address string. The term "printable string" in this context refers to ASN.1, not to ASCII. In ASN.1 (ISO 8824), para 29 defines several character string types, NumericString, PrintableString, TeletexString, VideotexString, VisibleString, IA5String, GraphicString, GeneralString. In that paragraph, table 5 lists the characters which can appear in the PrintableString type. For reference, see also into the RARE Recommendation for a Short Hand X.400 Address Notation, Annex A, which explains the situation with character types for use in O/R addresses. ---Ruediger
postel@venera.isi.edu (08/14/90)
Hi. What? You want to have the email address on your business card have a different syntax that is used in the user interface to send email? So every time you give your business card to someone you go through a routine like this: "And across the bottom of my card is my email address, but, of course, when you type it into the mail system you replace the semi-colons with back-slashes, except for the third semi-colon which needs two back-slashes, and, of course, if you are using unix where back-slashes are special you type two of them whereever there is a semi-colon except for the third semi-colon where you type four back-slashes. Is that clear?" This is obviously the way to go! --jon. Date: Sat, 11 Aug 90 05:21:14 +0200 From: Paul-Andre Pays <pays@mars.emse.fr> To: mark@cbmark.cbcc.att.COM, mhsnews@sintef.no Subject: Re: Printable format (was: Re: ISO/CCITT meeting report) don't make the confusion betweeen a business card orieneted form and a somehow "user oriented" interface. the ";" are meant for business card; no-one never said it should be used for UNIX or not UNIX based user interfaces..... please dont confuse the two very different purpose -- pap
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (08/14/90)
Jon, Your point is fair: going from "business card" to "user interface" should be as straight-forward as possible. However, one should not put too much emphasis on one given interface, i.e. the Unix command line. In fact, as outlined by the Swedish study on user perception, a single line expression of a set of typed tokens is always error prone, and full screen menus are preferable. In order to easely use the menu, one should be able to copy the content of each field without being bothered by the escape of special characters, etc: the choice of a delimiter outside the current X.400 set of allowed characters, ";", is thus more adequate than a character that needs escaping like "/". In fact, the best solution would probably be the use of NO separator at all, and the distinction of types (C=) from text by some typographic art, e.g. boldface of the types or italization of the contents. If you insist on single line expression of addresses, a la RFC-822, you must be aware that the form <C=DE;...; S=Kaufmann;> is currently used by some UAs. It can be directly copied from the business card, without interpolation -- reducing the risk for errors. One may expect that if a standard form of printing addresses is adopted, this standard form will be supported by more UAs. But using a text image of the X.400 addresses in a shell command is quite another business. The set of allowed characters includes in particular the blank and the parenthesis, and a quoting mechanism has to be available. As long as the parameter is quoted, you can as well include semi colons in the string! Besides, Mark Horton assertion that the MTA is build up by a set of shell commands which take the addresses to be reached as command line arguments is extremely debatable... Christian Huitema
mark@cbmark.cbcc.att.COM (Mark Horton) (08/14/90)
The original message said that a human factors study had been done, testing typing of these email addresses, how easy they are to type and how error-free the process is. It bemoaned that the ;= format is not directly usable by one-line computer user interfaces, but indicated that the committee was recommending it anyway because, even though it's not useful for typing into computers, it's at least not error-prone. Someone else then said that the whole purpose of this standard is to standardize printed business cards and that user interfaces aren't relevant. This is all silly. There are already de facto gateways being put into place, and the ones I've seen all use the /= syntax. Perhaps there is one using the ;= syntax somewhere, but I'll wager that people trying to use UUCP to reach such a gateway aren't able to get the semicolons through! A user interface standard that can't be implemented on 90% of the computers that it applies to is not going to have much influence on practice. A standard that is only useful for business cards produced by a body that standardizes computer interfaces isn't going to have much impact, either. As Jon Postel points out, if you're going to write your email address on a business card, let's write the email address the way it's going to be typed by the users. We have a golden opportunity to standardize the one-line entry format here, and if we pick a standard that can be implemented on the most popular systems, such as UNIX and MS DOS, and leverage off existing conventions and tools, such as the shell and UUCP, we can really help the users get their email sent without undue confusion. And by the way, let's standardize the spelling of the attribute names. The de facto gateways can't seem to agree on spelling, so we have to contend with A, AD, and ADMD for the same thing, for example. Mark
pmbs@stsci.edu (08/15/90)
Jon's comment on printable E-mail addresses echoes exactly the sentiments that I earlier had raised on the subject. The issue, at bottom, appears to be that what is most familiar and sensible to a user is not necessarily what is required for computer handling, and further, that user knowlege about who they want to send to does not imply (and should not involve) any knowlege about how that mail gets routed. By analogy, I can just imagine the reaction of the general public if the post office announced that a wonderful new mail system was being put into place. It would tell you if the mail was delivered, if your friend was on vacation, would let you send pictures and voice-mail all in one small envelope. The only drawback is that you would have to send along explicit information about how to get the mail routed (New York to Europe via plane, then truck to London, followed by a lorry to station xyz, the last bit on foot via a mail carrier named John Smyth ...). I suppose that a simple, readable, business-card-printable, E-mail address is too much to ask for, but the present suggestion of /x=y/ types of addresses that must include the public carrier and other organizational information appears to be rather awkward and to warp the user interface to the needs of the computer. All these years I had thought that computers were rather wonderful because we could warp them to the needs of humans. Have we lost something in this drive to provide international standards? I recognize that some sort of directory service (ala DNS or X.500) will eventually make some of these abberations disappear beneath a user interface layer (whatever that might look like). In the interim the proposed address specifications leave a lot to be desired and offer a number of difficulties in both presentation for human use and translation into system use. In my own simple way I fail to understand why some simple variant on the existing RFC822 address form (which seems to be handling an enormous amount of E-mail among many domains) cannot be used. But then, I'm probably missing something obvious. Peter
eskovgaa@uvcw.uvic.ca (Erik Skovgaard) (08/15/90)
I think it is going to very hard to change implementations of X.400.
They tend to vary in the way O/R-names are entered - some use a
directory functions or aliases and some require the full string to
be entered.
I am afraid you are too late if you want to change that - all we
can do is to make sure the users have a commonly understandable
format and then let the implementers document the mapping (or
perhaps, provide the option of using both a standard representation
and their own?).
....Erik.
---------------------------
Erik Skovgaard
PSC (Pacific) Inc.piet@cwi.nl (Piet Beertema) (08/15/90)
I suppose that a simple, readable, business-card-printable, E-mail address is too much to ask for Really? Plain RFC822 e-mail addresses are simple, readable and business-card-printable. And even today's UUCP addresses usually meet these requirements. but the present suggestion of /x=y/ types of addresses that must include the public carrier and other organizational information appears to be rather awkward and to warp the user interface to the needs of the computer. Organisational information usually is meaningful information and is in general present in RFC822 addresses too. But clearly such administrative things as management domains (ADMD and PRMD) should be none of the user's business. All these years I had thought that computers were rather wonderful because we could warp them to the needs of humans. Have we lost something in this drive to provide international standards? Yes, in the name of progress and standards we are rapidly loosing what we have: simplicity. Piet
JPALME@qz.qz.se (Jacob Palme QZ) (08/15/90)
> What? You want to have the email address on your business card have a > different syntax that is used in the user interface to send email? > > So every time you give your business card to someone you go through a > routine like this: "And across the bottom of my card is my email address, > but, of course, when you type it into the mail system you replace the > semi-colons with back-slashes, except for the third semi-colon which needs > two back-slashes, and, of course, if you are using unix where back-slashes > are special you type two of them whereever there is a semi-colon except > for the third semi-colon where you type four back-slashes. Is that clear?" > > This is obviously the way to go! > > --jon. I had the same opinion as you, until I saw the results of the human factors investigation. This investigation found the following results: User interface User interface single string form-fill-in +---------------------+---------------------+ Business card: ! Not reasonable ! Very good, but too ! Full labelled ! ! spacious on the ! format ! ! business card ! +---------------------+---------------------+ Business card: ! Bad results ! Very good ! Abbreviated ! ! ! labelled format! ! ! +---------------------+---------------------+ Business card: ! Not as bad, but not ! Not reasonable ! Concise format ! very good either ! ! +---------------------+---------------------+ So the human factors study did find that the best combination was to have a ***different*** format on the business card and in the user interface!!
pays@mars.emse.fr (Paul-Andre Pays) (08/15/90)
Thanks to Jacob for the results of this human factors study...
This is inline with my own experience managing a somehow
representative set of users.
1. An X.400 ('84) ORname is not a user friendly and easy "name" for
a remote user (or mailbox)
as a snail mail address it is an address and as such made of a set of
attributes and not a "one string" name
2. We have to distinguish different purposes
. to be able to exchange ORnames via printed media
. to be able to enter an ORname into some computer based
application (better a local -personal or shared- alias system
than directly when composing mail -- though both should be
availble)
. to be able to compose mail quite easily and quickly
. to be able to remember easily some form of a name for our most
common recipients
3. the ";=" (keyworded form) seems perfectly suited for ORname
exchange and I am pleased with its "business card" purpose..
for the user interface there could and probably should be several
different input "forms". One of them is certainly the fill-in form
already mentioned by Huitema and available with many products; another
one useful is for the software to accept as an input a blind
"retyping" of the ";=" business card form (assuming that a common
strict syntax is accepted and used); there could perfectly be one or
more other forms which are more inline with the overall user interface
either of the mail-system or the specific Operating sytem or shell
the user "task" to translate the business form into a fill in form
using the same labels (keywords) is easy for any user even novice,
and besides presents the advantage to make these users painlessly
aware of what they are doing
As stated above, it appears that the right approach is to limit
the use of whatever form of these addresses to the strict minimum.
i.e. the software should allow to normaly use names instead of
these addresses. Thus, in my opinion, any acceptable mail system
and user interface should present the ability (and encourage the
use) of aliases... either strictly personal or shared or any
combination. These aliases should be short enough though remaining
significant enough and easy to remember.
4. X.500 directory services
X.500 is not as such a solution to the previous problem: a Directory
name -- though a name is still a set of attributes and not a string.
a DName is structured and long even if the attributes are expected
to be more "natural" than those in the ORaddress. The DS will
allow queries and search using partial information, it will not
provide a universal one-string short and easy name.
Of course a specific X.500 implementation may be combined with an
alias mechanism of the type presented before, but this will be an
implementation and management matter
Well, while still waiting for the common acceptance of a printable
form of ORnames (mainly for business card and additionaly for an
optional input form for user interfaces) I maintain that
printable "ORnames" and user interfaces are really completely
different though related issues. probably RFC-822 which used only one
form was easier but is too limited and misleading.
regards,
-- PAPGRZ027%DBNGMD21.BITNET@cunyvm.cuny.edu (Peter Sylvester +49 228 8199645) (08/15/90)
> So the human factors study did find that the best combination > was to have a ***different*** format on the business card > and in the user interface!! I would interprete this result in a different way: Gargabe in, arbitary results out. If a "huge" form fill in user interface is necessary to enter addresses in an acceptable way then this means that something is wrong with the addressing structure at all. The most complicated part on a busisness card is the postal address with about 6 times 30 characters. As long as e-mail postal delivery as a model (but without all the nice human heuristics) you at least the same space for email addresses on business cards, and this is "not reasonable". What would people say if the telephone business would be changed: From now one telephones will get a keyboard and instead of a telephone number you have to type in the directory name of a user like Freiherr von M"unchhausen SchloB Birlinghoven Sankt Augustin Bundesrepublik Deutschland .... Or: Tell a user that FAX is changed now. You do not longer dial the telephone number of the recipient but you have to enter a long X.400 address. Is there someone who can reach the last wagon of the train leaving the station? Peter Sylvester GMD Bonn
zellich@STL-07SIMA.ARMY.MIL (Rich Zellich) (08/15/90)
Going back to how ORName came about, it is my recollection that the business card itself should yield the ORName without having to add ANYTHING except, in some cases, the Domain... ORName was designed to be "guessable", and certainly first name, last name, organization, and (perhaps implicitly) country are on any business card. For countries with more than one mail domain or sub-domains, or whatever, one should only need to add "EMail Domain: EDU.USA", for example, to an existing business card. Any decent user interface will probably prompt for the individual attributes, and they're all right there on the card (unique email spellings of organization might need to be added in parentheses on the business card, also, if different than the postal-mail form of the org's name).
pmbs@stsci.edu (08/15/90)
>I had the same opinion as you, until I saw the results of the human >factors investigation. >This investigation found the following results: ... table deleted >So the human factors study did find that the best combination >was to have a ***different*** format on the business card >and in the user interface!! I would caution against taking the results of any human factors evaluation of user interfaces as gospel. There are many wonderful user interfaces out in the market, ALL of which seem to have their strong advocates and even stronger detractors. As a case in point, many users seem to find the MAC interface very appealing and intuitive but there are an equally large number who do not like it at all and prefer a command line interface. The results of any study are likely to be biased by the level of experience of the users, their previous familiarity with different interfaces, and their level of familiarity with the "test" interface. In my experience new users of an interface tend to appreciate the form-fill-in style, but this loses it's appeal after a short period of familiarity when the forms and menus are found to get in the way. To come back to the real issue, it does appear that some concise format for E-mail names is well received on a business card, but longer forms, or labelled forms, are not. It also seems pretty obvious that any user interface should at least have the ability to accept and properly parse any *agreed* short form that appears on a business card. Whether such an interface can also support single command line entry, forms-fill-in, and or a menu is an interface design issue and is also bound up in operating system details of command line syntax and semantics. There are clearly many ways to handle these data input and presentation issues but I do not believe that these details are the subject of any standardization efforts. Am I wrong? Peter
piet@cwi.nl (Piet Beertema) (08/16/90)
Wonder why in this era we are talking at all about readable e-mail address formats on business cards, forms-fill-in etc. After all e-mail addresses are not meant to be read by humans, but only to be fed to computers, for which there are far better means. So, why don't we opt for a bar code presentation of them on business cards? ;-) Piet
bob@morningstar.COM (Bob Sutterfield) (08/16/90)
In article <9008141714.AA20435@GHOST.STSCI.EDU> pmbs@stsci.edu writes:
I suppose that a simple, readable, business-card-printable, E-mail
address is too much to ask for...
For years, my business card has carried something of the form
"bob@morningstar.com". Simple, discreet, tucked away into a corner.
Nobody who knows what it is has ever had trouble using it.davecb@nexus.yorku.ca (David Collier-Brown) (08/16/90)
someone declaims... > I suppose that a simple, readable, business-card-printable, E-mail > address is too much to ask for piet@cwi.nl (Piet Beertema) replies >Really? Plain RFC822 e-mail addresses are simple, readable and >business-card-printable. And even today's UUCP addresses usually >meet these requirements. That having been said, let's pull the discussion ``up'' one level and address the meta-problem: 1) We wish a useful, unambiguous machine-interpretable address, and 2) We wish a concise, possibly elliptical, human-interpretable address. We can do any of the following 0) do nothing: let them be incompatible (and reduce the viability of email somewhat) 1) use the machine address, at a cost in comprehensibility, 2) use the human address, at a cost in ambiguity, or 3) use a compromise between the two. [Please note I haven't said anything about "/,.=;" in the above: they're just parts of the machine address... and in principle are interconvertable.] Ok, let's consider what a compromise might be. I'll start by proposing a form of the human address, annotated with required disambiguating information. This might be <first name> {<optional initial> "."}* <last name> "," <street number> <street name> <optional street type> "," <city> "," <state or province> "," <postal code> "." Note that the separators are "," and "." in this positional notation. The disambiguating information is called <postal code>, and is a machine-specific annotation required to allow mechanical delivery to a semi-active MUA called a letter-carrier. Following Piet and the other commentator's lead, the public carrier and management domains are irrelevant to the addressee and/or sender, and go in the <postal code>. Note that they are still required by the mechanical transport, the MTAs. They also have to be available to the final MTA/MUA to help select the recipient unambiguously and identify misadressed mail. I can write the above with as much extra formatting (whitespace, font changes, embedded newlines) as I want: its still unambiguous without. I can put it on both letters and business cards, and as long as I don't leave something out, letters addressed with a copy of it get delivered. Sometimes they come back with ``provide proper postal code!'' if I leave the machine-specific data out, but that's my fault (;-)). Another possible positional notation would use "." and "@" as separators. A third might use "/" or ";" A possible non-positional notation might use "/", keywords and "=". This raises the obvious question: do humans need a non-positional notation? My ergonomics training makes me say ``conditionally no''. (Ie, I have to weasel a bit because very complex addressee formats **might** need one: say formats with eight data items which are not identifiable by their content). If they do not, then its is merely a matter of defining an information- preserving transform between formats using "@.", "/" and ";" and a standard for the <postal code>. That is not a simple task, mind you, but it's at least narrowly defined (:-)) --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | "And the next 8 man-months came up like CANADA. 416-223-8968 | thunder across the bay" --david kipling
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (08/16/90)
Peter, You are quite right with your analogy with telephone numbers and the like. In fact, the X.400 addressing was deliberately mapped, from the beginning, onto the postal addressing -- and this is part of the problem. The initial philosophy (1981) was that the envelope would carry the name of the recipient. Yes, the name, not the address; the name considered as a set of attribute assertions, to be used in a directory loosely modelled as a relational data base. The problem was indeed that such a world wide distributed data base was not available; an ad-hoc partitioning had to be made, hence the insertion of ADMD and PRMD codes, which play mostly the same role as zipcode and po-box in postal addresses. The hypothesis being that once the letter has been dropped by some public or private service in the po-box (or PRMD), the remaining attribute will be used by some sort of SQL query to the local directory. I one follows that philosophy, one as to take into account two remarks: * the only elements which need to be added to a business card are the identification of the zipcode and po-box, which are probably common to all the members of an organisation. There is no need to duplicate the other stuff, like first name or unit: one should be able to read them from the "text" portion of the business card. * the whole stuff is bulky and error prone. Some sort of telephone number, preferably a sequence of short tokens to allow for distributed hierarchical allocation, would be welcomed. In fact, a step in the secund direction was taken by the clear distinction between directory name and mail address in the 1988 version of X.400. The only thing which is left now is to let the address look like an address... Christian Huitema
pmbs@stsci.edu (08/16/90)
>For years, my business card has carried something of the form >"bob@morningstar.com". Simple, discreet, tucked away into a corner. >Nobody who knows what it is has ever had trouble using it. Seems I was misunderstood by some to be suggesting that there is not presently a "simple, readable, business-card-printable, E-mail address". My point was that there has not been a simple, etc, etc, X.400 E-mail address spec proffered, not that the existing RFC822 addresses do not meet those criteria. A couple of earlier responders also noted this obvious alternative; I have to note that I thought it was so obvious that I did not mention it explicitly. Peter
JPALME@qz.qz.se (Jacob Palme QZ) (08/16/90)
There are some characters best not used in any format,
because they are often changed to other characters
in various national variants of the ASCII character set.
These characters to be avoided are: }{|@`~^][\.
The characters # and $ also vary between different countries.
In the IOS 646 standard, the international version of ASCII,
all these characters are designated as for national use.GRZ027%DBNGMD21.BITNET@cunyvm.cuny.edu (Peter Sylvester +49 228 8199645) (08/16/90)
> My point was that there has not been a simple, etc, etc, X.400 E-mail > address spec proffered, not that the existing RFC822 addresses do not > meet those criteria. A couple of earlier responders also noted this > obvious alternative; I have to note that I thought it was so obvious that > I did not mention it explicitly. > Peter I can't resist: It might be that the people working at the ZPL.DFN.DBP.DE are happy with their nice short address, but all those poor people from THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE
piet@cwi.nl (Piet Beertema) (08/16/90)
I can't resist: It might be that the people working at the ZPL.DFN.DBP.DE are happy with their nice short address, but all those poor people from THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE Those poor people shouldn't even be able to send mail to or get mail from the Internet, since the secondary and all lower subdomains violate RFC920 (>12 chars).... Piet
pvm@venera.isi.edu (Paul Mockapetris) (08/17/90)
> I can't resist: It might be that the people working at the > ZPL.DFN.DBP.DE are happy with their nice short address, but all > those poor people from > THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE > Those poor people shouldn't even be able to send mail to > or get mail from the Internet, since the secondary and > all lower subdomains violate RFC920 (>12 chars).... > > > Piet While I personally find names like "cwi.nl" somewhat easier to type, I wouldn't worry too much about: "THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE" The DNS restriction is 63 characters per label or approx 255 total, restricting names to about 3 screen lines (I don't know how many lines that is on a business card.) The 12 character limit from RFC 920 was there mostly to try and help out folks with HOSTS.TXT software. RFC1123, page 13, says: Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. So, in the worst case, (i.e. to make it under the "MUST" criterion), only a single character of abbreviation would be required, and I suspect most software could hack it today. paul
david@TWG.COM (David Herron) (08/17/90)
>> THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE >Those poor people shouldn't even be able to send mail to >or get mail from the Internet, since the secondary and >all lower subdomains violate RFC920 (>12 chars).... Here is one of the major problems (as well as strengths) of the rfc-822 address scheme with domain-ing. This reliance on short mnemonic strings of characters to refer to entities doesn't scale up very well. Think about the kind of mess we'd have if that system were to be used for everybody in the world. That's the level of addressability we're capable of approaching -- if large parts of the worlds organizations get into networking & e-mail interchange. `david@twg.com' just isn't a very good identifier. I happen to like it, and that is what my business card says. But there's also about 7-8 other `david's in the company and, in fact, I'm the newest one. Furthermore there are other companies around whose initials could be "TWG". For instance a computer company in Vancouver BC (I think) has the "TWG" name over in UUCP-land all to themselves .. with some potential confusion in some peoples minds. The neat thing about mnemonics is that they mean different things to different people... The days of the RFC-822 address format are numbered.. David
kent@BBN.COM (Steve Kent) (08/17/90)
Piet, Ah, your workstation must differ in an important respect from the ones used by most of the rest of us. Just where is the bar code reader attached? Is it standard equipment or was it an optional facility offered by an aftermarket dealer? Steve
piet@cwi.nl (Piet Beertema) (08/17/90)
`david@twg.com' just isn't a very good identifier. I happen to like it, and that is what my business card says. The discussion was about formats, not identifiers. You have that address on your business card, you can communicate it to others, it can be easily typed in and it suits the purpose of getting mail to you. But there's also about 7-8 other `david's in the company and, in fact, I'm the newest one. Well, if you mailer can handle it, then why not use the David.Herron@twg.com notation? Furthermore there are other companies around whose initials could be "TWG". For instance a computer company in Vancouver BC (I think) has the "TWG" name over in UUCP-land all to themselves That has nothing to do with RFC822 addressing. It's just a matter of how it's used. Dropping the old 3-letter top level domains in favour of the ISO3166 2-letter top level domains could already considerably reduce the confusion. Without C=US, just ORG=TWG would be just as confusing. Piet
mr@ritd.co.UK (08/17/90)
OK, I can't resist chipping in. I have to say that I am firmly in the
camp of those unhappy with suggested syntaxes. The "XXX=xyz" type I
could just about stomach. The "count the delimeters" type just doesn't
tie in with my own experience of the computer literate, let alone the
rest of the world. Shades of OS/360 JCL (was that 13 commas or 14?).
Regarding the sub-discussion of the merits and problems of current
domain style addressing: I absolutely agree with Piet's comment about
country identifiers. My domain address is mr@ritd.co.uk. This uniquely
identifies me in the world. The upper domain parts seem to me to relate
to ADMD and PRMD concepts, each part having control of the allocation
of names within it's domain. This domain control is what prevents name
conflict and allows this unambiguous naming (I assume that domain
authorities have their act together).
Yet I (as an end user) don't need to know all that (or care). To most
users around here it is a short, *typographically simple* string that is
relatively easy to use and communicate to others. It's the job of our
and other mail handlers to parse such an address "sensibly". Isn't that
why we write software?
Martin Reed, Racal Imaging Systems Ltd
+----------------------------------------------------------+
|uucp: mr@ritd.co.uk, uunet!ukc!ritd!mr | `Just hold
|Global String: +44 256 469943 Fax: +44 256 471492 | these two
|Paper: Rankine Road, Basingstoke, Hants, England, RG24 0NW| wires...'
+----------------------------------------------------------+PETERSEN@ctrvx1.vanderbilt.edu (Ghost in the -Turing- Machine) (08/17/90)
> From: IN%"mr@ritd.co.UK" 17-AUG-1990 04:40:24.15 > Subject: Re: Printable format (was: Re: ISO/CCITT meeting report) > Message-Id: <1186.9008170736@coyote.ritd.co.uk> > > Yet I (as an end user) don't need to know all that (or care). To most > users around here it is a short, *typographically simple* string that is > relatively easy to use and communicate to others. It's the job of our > and other mail handlers to parse such an address "sensibly". Isn't that > why we write software? > > Martin Reed, Racal Imaging Systems Ltd I suppose I will add my $0.02 also. I think that this is the best comment I have seen so far on this subject. We write software to do things that we don't want to do or cannot do, or at least that's my justification. I don't want to HAVE to remember all of the necessary attributes for anybody's e-Mail address, and I don't want to have to type it all in correctly every time I want to send to someone. Therefore, I like the current name-server system in the Internet model. Why should my host or any host outside of the domain itself know how to reach a specific host or person in another domain, and why should a user have to know a complete routing specification? As far as I am concerned, the answer is obvious. Only the "owners" should NEED to have complete knowledge of their domain. Others should be able to specify a certain mailbox within the domain quickly and easily and have the software route everything from there... This, of course, may be a completely unrealistic approach in the global network of tomorrow... -Chris +------------------+ \ Chris Petersen / +-----------------------+--------------+----------------------+ / Vanderbilt University Computer Center - Systems Development \ / petersen@ctrvax.Vanderbilt.EDU .AND. petersen@VUctrvx1.Bitnet \ +-------------------------------------------------------------------+ { "You're quoting me? I make it up as I go!" } +---------------------------------------------+
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
In article <9008161047.aa01196@Obelix.TWG.COM> david@TWG.COM (David Herron) writes: > >> THEORETISCHE-INFORMATIK.NATURWISSENSCHAFTEN.XYZTH-SCHILDA.DBP.DE > >Those poor people shouldn't even be able to send mail to > >or get mail from the Internet, since the secondary and > >all lower subdomains violate RFC920 (>12 chars).... > Here is one of the major problems (as well as strengths) of the rfc-822 > address scheme with domain-ing. > This reliance on short mnemonic strings of characters to refer to > entities doesn't scale up very well. Sure it does. Hierarchies make the difference. You can have an obelix.twg.com or a twg.uucp (yes, I know it's not a real domain but it's the format we're talking about here) or a twg.leaf.ferranti.com or a twg.bc.ca... > Think about the kind of mess we'd > have if that system were to be used for everybody in the world. We'd sure have big fights over who gets the higher level hierarchies. But that's up to the NIC to resolve, or whoever the big guys assign to the job. > The days of the RFC-822 address format are numbered.. Only for petty political reasons, if at all. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
In article <412506*JPALME@QZ.qz.se> JPALME@qz.qz.se (Jacob Palme QZ) writes: [of {}|@`~^[]\#$] > In the IOS 646 standard, the international version of ASCII, > all these characters are designated as for national use. Ah, but isn't everyone moving towards ISO Latin 1? But if that little '@' burns you up, there's a well known solution... replace it with '%' which *is* in ISO 646: <peter.da.silva%hackercorp.com> -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
davecb@nexus.yorku.ca (David Collier-Brown) (08/20/90)
GRZ027%DBNGMD21.BITNET@cunyvm.cuny.edu (Peter Sylvester +49 228 8199645) writes: >> So the human factors study did find that the best combination >> was to have a ***different*** format on the business card >> and in the user interface!! >I would interprete this result in a different way: >Gargabe in, arbitary results out. Actually it's just too narrow (:-)). I'm afraid the ergonomic investigation will need to be re-run, with the results of the first experiment being used to help design a second experiment. After all, we're shouldn't be trying to decide on an optimal form at this early stage: we should be trying to get enough breadth of choice into the experiments so that we don't miss a previously unconsidered, arguably ``better'' form. --dave c-b [ps: If you don't think that verged on a self-serving comment, you didn't see my previous posting... I'm almost blushing.] -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | "And the next 8 man-months came up like CANADA. 416-223-8968 | thunder across the bay" --david kipling
shekhar@hpinddacup.hp.COM (Shekhar Bhide) (08/20/90)
Hey, this notestring is slowly getting into mud-slinging over X400 addressing. And you haven't even seen the X.400/88 O/R addresses yet :-) I don't think anyone is disputing that X.400 addressing is complex. But the problem of having a global message handling standard, to interconnect various e-mail systems developed by different vendors, without favoring or excluding any operating system, any mail system, any country, any PTT is indeed a complex one. In case it hasn't dawned to someone yet, X400 was not designed with BSD 4.3 Bourne shell in mind. In fact it might be a good exercise to come up with a simpler solution for addressing. Either it will open your mind to the complexity of the problem or we might have a better solution. Lets hope that the X.500 Directory Service will be widely deployed soon and shield the users from O/R addresses. shekhar /* Shekhar Bhide shekhar@hpindqc.hp.com */
mark@cbcc.att.COM (Mark Horton) (08/20/90)
Actually, it seems like most of the world is ignoring X.400 semantics in real products anyway. The primary users of X.400 appear to be the commercial email services, and they only use it to talk among themselves. They provide different user interfaces to their customers. Perhaps the best way to write an X.400/X.500 email address on your business card is to use the de facto standard, RFC 822/987. Thus the X.500 address Country UK Org UCL Org Unit CS Surname Kille Givenname Steve would simply be written Steve.Kille@CS.UCL.UK This doesn't handle all the special characters and attributes that are possible unless you resort to /= syntax on the LHS, but it seems to be in wide use (with minor variations to include AD's and PD's and fictitious countries like COM and EDU) and has proven itself to be very easy to use in the real world. Mark
piet@cwi.nl (Piet Beertema) (08/20/90)
Perhaps the best way to write an X.400/X.500 email address on your business card is to use the de facto standard, RFC 822/987. Thus the X.500 address Country UK Org UCL Org Unit CS Surname Kille Givenname Steve would simply be written Steve.Kille@CS.UCL.UK Interestingly, UK is not an ISO3166 2-letter abbreviation and thus ought not be used in X.400 or RFC822.... Piet
geo@syd.dit.csiro.au (George Bray) (08/21/90)
In article <9008151903.AA14052@piring.cwi.nl>piet@cwi.nl (Piet Beertema) writes: >After all e-mail addresses are not meant to be read >by humans, but only to be fed to computers, for which >there are far better means. >So, why don't we opt for a bar code presentation of >them on business cards? ;-) or magnetic stripe! --
JENNINGS%IRLEARN@pucc.princeton.edu (Dennis Jennings) (08/21/90)
Would it be all too unreasonable to suggest that the business card address and the e-mail address are one and the same thing, and that business cards should only have one human readable address, not two as has to be the case with RFC822 addresses. For example, my address (business and electronic) should be: Dennis M. Jennings, Director, Computing Services, University College Dublin, Belfield, Dublin, 4, Ireland This corresponds to: Personal Name Dennis M. Jennings Functional Name Director, Computing Services Organisational Unit Computing Services Organisation/PRMD University College Dublin <local postal bits> <Belfield, Dublin, 4,> Country/ADMD Ireland And, people should be able to send me mail using my personal name or my functional name - just like mail. And the mailing system should be able to work out what to do from the address given. (or tell the user that regrettably more informations is required) So, instead of adding e-mail addresses, we should surely be adopting a form of address that will cover both the postal address and the electronic address. Perhaps the way to do this is to recognise that the postal system has some intelligence in it, and the electronic mail systems have little, and adopt the convention that spurious postal address information be put in delimiters such as the angle brackets used above. Please don't flame at me for my ignorance - I am only a user. Dennis
piet@cwi.nl (Piet Beertema) (08/21/90)
>So, why don't we opt for a bar code presentation of >them on business cards? ;-) or magnetic stripe! Too expensive and too easily damaged. Piet
obh@ifi.uio.no (Ole Bj|rn Hessen) (08/21/90)
In article <9008201119.aa09713@ICS.UCI.EDU>, JENNINGS%IRLEARN@pucc.princeton.edu (Dennis Jennings) writes: > Would it be all too unreasonable to suggest that the business card > address and the e-mail address are one and the same thing, and that E-mail is a fundamental different media. It is much more interactive and spontaneous than snail-mail. In some ways it is comparable to communicating by telephone. > Personal Name Dennis M. Jennings > Functional Name Director, Computing Services > Organisational Unit Computing Services > Organisation/PRMD University College Dublin > <local postal bits> <Belfield, Dublin, 4,> > Country/ADMD Ireland Imaging yourself having to type such an address on the telephone every time you want a chat with your neighbour or your co-worker. It takes approximatively 3-5 seconds to type an 822-address. (A bit more if you have to search for it :-) (Or if the recipient belongs to certain domains in german ;-) I'm not rejecting S/A addresses, just saying that I like to do it fast (sending letters, that is). Besides, I like 822-addresses, I think they're quite mnemonic and very easy to remember. Ole Bjorn. obh@usit.uio.no
peter@ficc.ferranti.com (Peter da Silva) (08/22/90)
In article <9008201119.aa09713@ICS.UCI.EDU> JENNINGS%IRLEARN@pucc.princeton.edu (Dennis Jennings) writes: > So, instead of adding e-mail addresses, we should surely be adopting > a form of address that will cover both the postal address and the > electronic address. Perhaps the way to do this is to recognise that > the postal system has some intelligence in it, and the electronic mail > systems have little, and adopt the convention that spurious postal > address information be put in delimiters such as the angle brackets > used above. But that postal address information (post code, and so on) isn't spurious. It's important routing and disambiguating information. Wouldn't it be better to choose an Email address that doesn't contain such ambiguity in the first place? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
david@twg.COM ("David S. Herron") (08/22/90)
In article <9008141714.AA20435@GHOST.STSCI.EDU> pmbs@stsci.edu writes: >I suppose that a simple, readable, business-card-printable, E-mail address is >too much to ask for, but the present suggestion of /x=y/ types of addresses >that must include the public carrier and other organizational information >appears to be rather awkward and to warp the user interface to the needs >of the computer. All these years I had thought that computers were >rather wonderful because we could warp them to the needs of humans. Have >we lost something in this drive to provide international standards? Exactly ... In fact I had been under the impression that the /x=y/ format was a temporary thing. That some other `standard format' would come along or possibly that individual user agents were going to be free to display it as they wished. As a data-point I am in the midst of writing a program, part of which will be inputing O/R names for both MTAs and users. I am intending to have the dialog for doing this display the components in a fairly normal "form" like: Country <country value> Administrative Domain <ADMD value> Primary Domain <PRMD value> Organization <O value> Organization Unit <OU value> ... along with a box at the bottom using the current string in the /x=y/ form. Is this a reasonable thing to do? I don't see any problem with it myself with the possible exception of writing the X/Motif necessary to handle all the different possible types ... -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
pays@mars.emse.fr (Paul-Andre Pays) (08/22/90)
> > In fact I had been under the impression that the /x=y/ format was > a temporary thing. That some other `standard format' would come > along or possibly that individual user agents were going to be > free to display it as they wished. > I don't see it as temporary. What I expect is that X.500 will provide better (more natural) attributes and that we will no longer have to bother about ADMD, PRMD but X.500 DNames are in their structure very similar to ORnames and I believe thet the same format ("/=" or ";=") will be needed and used to "print" those names. > As a data-point I am in the midst of writing a program, part of which > will be inputing O/R names for both MTAs and users. I am intending > to have the dialog for doing this display the components in a > fairly normal "form" like: > > Country <country value> > Administrative Domain <ADMD value> > Primary Domain <PRMD value> > Organization <O value> > Organization Unit <OU value> > ... > > along with a box at the bottom using the current string in the /x=y/ form. > > Is this a reasonable thing to do? I don't see any problem with > it myself with the possible exception of writing the X/Motif necessary > to handle all the different possible types ... That is exactly what I have done (using curses) and what is being now delivered (curses and X) by SYNC (a software house here), and it seems that this approach suits most users. -- pap
jmm@hpctdlb.hp.COM (Janet Martino) (08/23/90)
Thank you for sending the mhsnews to me but we are also receiving this inform- tion at another source. So I don't need this information sent directly to me. Thanks, Janet Martino jmm@hpctdlb.col.hp.com