Path: utzoo!utgpu!watmath!att!rutgers!usc!apple!ames!lll-winken!ncis.tis.llnl.gov!nexus.yorku.ca!davecb From: davecb@nexus.yorku.ca (David Collier-Brown) Newsgroups: comp.protocols.iso.x400 Subject: Re: concise format Message-ID: <4577@yunexus.UUCP> Date: 24 Oct 89 13:37:20 GMT Sender: root@ncis.tis.llnl.gov Distribution: inet Organization: The Internet Lines: 78 Approved: post-x400@tis.llnl.gov 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.