kre@ucbvax.ARPA (Robert Elz) (08/03/85)
The first thing to notice here, is that it doesn't really make sense to choose a syntax to be used to specify something, until we know what it is that we want to specify. That is, we have to get the semantics of addresses right FIRST. Once that's done, syntax is a 'religious issue' - it really doesn't matter what one we choose, just as long as we all agree to adopt the same one. So, I'm not going to say much about this, I just want to beat some much overstated preconceptions about the head a bit. First, nothing says that foo!bar!user is a route, or an attribute list, or anything else. Its just three words, and two '!' symbols separating them. Period. We can define it to be anything we like. Similarly, user@host.dom1.dom2 is not a domain specification, its four words, one '@' character, and two '.' characters. Now I can define user@host.dom1.dom2 to mean, send the mail to the site called host, which then must forward to the site called "dom1" which must then forward to the site called "dom2" which must them deliver to "user". Now that's nothing like any of the currently adopted semantics for a syntax like this, but that doesn't mean it couldn't be defined this way. Now lets look at some possibilities for the various semantic meanings possible for a mail address... 1) domains user@host.dom1.dom2 dom2!dom1!host!user user@dom2-dom1-host user[host](dom1,dom2) ... (invent your own). of those, the first is the most commonly used, the second is a possibility (sometimes thought to have been suggested in the Pike/Weinberger "Hideous Name" talk at Portland Usenix, but I'm not convinced that this is really what they were arguing for). The third is just for fun (explained below). The fourth one (and any others) are simply trash. 2) attribute lists attr1!attr2!host!user U="user", H="host", A1="attr1", A2="attr2" user@host.attr1.attr2 ... (again, invent your own) Of those, the first is the syntax that Peter Honeyman has proposed, the second is (I think) something like the syntax that MHS would use, the third is just to show that anything can be interpreted any way that you like it to be, and others would be more trash. 3) explicit routing host1!host2!host3!user user@host1.host2.host2 @host1,@host2:user@host3 user%host3%host2@host1 ... These semantics aren't worth considering really, so detailing what the possible syntaxes would mean probably isn't worth the bother. The most remarkable thing to notice about this (for all those people who are freaked out by syntax) is that a!b!c!d and a@b.c.d were listed as possibilities for each of the 3 meanings. Of themselves, the separator characters simply mean nothing - they can be interpreted in any way that you desire. Of the choices, I prefer user@host.dom1.dom2 for domain semantics. I read this as "user at host" using the conventional meaning for the '@' character. The "host.dom1.dom2" I just consider to be a host name, to me the '.' is no more a separator, than most people consider the '-' to be in the form user@dom2-dom1-host. (Eg: consider user@su-glacier and user@glacier.su - is there really a difference?). It doesn't matter to me (as a user) that one person chose the "dom2" part and registered it somewhere, and that someone else chose the "dom1" and registered it (probably at another place, possibly at "dom2" if it exists as an entity), and that yet a third person chose "host" and registered it somewhere. Nor does it matter that some hosts may choose to use some parts of the "host.dom1.dom2" string for routing purposes, and leave other parts of it to someone else (any more than it does that other hosts might take the whole string as an unbroken word). This also happens to be the syntax that's in fairly wide use. For attribute addressing I think I actually probably prefer the MHS style - but as I don't like the semantics that go with it, I'm not going to say any more. For explicit routing, I suppose I prefer the host1!host2!host3!user form, just because of its use with uucp (common practice). The rfc822 form (@host1,@host2:user@host3 is just too baroque to be true). However, as I don't think much of these semantics either, again I won't say more.