Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!nsc!chongo From: chongo@nsc.UUCP (Landon C. Noll) Newsgroups: net.mail Subject: Re: parsing host1!user@host2 - a new idea Message-ID: <1608@nsc.UUCP> Date: Tue, 16-Oct-84 05:11:14 EDT Article-I.D.: nsc.1608 Posted: Tue Oct 16 05:11:14 1984 Date-Received: Wed, 17-Oct-84 05:29:13 EDT References: <691@sunybcs.UUCP> <1606@nsc.UUCP> Distribution: net Organization: National Semiconductor, Sunnyvale Lines: 92 Chuqui has some good points in his article. To remove confusion, why not allow '('s? You could say: (host1!user)@host2 -or- host1!(user@host2) The '(' is your friend. (and so is ')') Always keep in the message, where the message has gone. If a message hits a dead/wrong end, DONT opt. the path of the return message. On another point, I think each site should not just blindly adjust the path of a message. Here are some reasons why: 1) I don't want site foo to receive my letter because the uucp manager just learned how to monitor letters and kills messages which he/she does not like. (this actually happened in a local S.F. site) The normal path might be: a!bletch!foo!bar!mojo but I want: a!bletch!curds!and!whey!bar!mojo. 2) There are too sites named foo. I send a letter to: a!bletch!c!d!e!foo!mojo but bletch changes the path to: a!bletch!foo!mojo where e!foo is not the same site as bletch!foo. I can see a site adjusting a domain directed message path if it is a gateway, or sending it on to a gateway site if it is not. The cases where you want a forced path are few. Most of the time, mailer path opt. does help. But there ARE reasons who you might want to force a given path. I have a suggestion and another use for the '(' in a path. Let the '(' guide you on which paths NOT to touch. For example: a!b!c!(x!y!z)!d!e!foo!mojo where (x!y!z) is a path expression. We will talk about this path below, so keep it in mind. Here is some ideas on how to treat this path expression: - Deal with the path c!(expression)!d as a glued in path and NOT subject to change. That is, c MUST receive the message and pass it along to the leftmost site inside the expression. The rightmost site MUST send the message to site d. In other words, c!x and z!d are 'glued' in. - Disallow a site to change the path to the right of any expression. That is, site b can not change the d!e!foo!mojo path because it is to the right of the path expression. - Allow any site within an expression to ONLY change the path inside that expression. That is, x can send it along to z and bypass site y if it wants to, but dont allow x to send it to d or e. - Pull the left '('s along until you reach a right ')'. The life of the path could go like: a!b!c!(x!y!z)!d!e!foo!mojo - as sent by the user b!c!(x!y!z)!d!e!foo!mojo - the users site talks directly to the site b, so a is bypassed. The users site also talks to e, but sending directly to e would bypass the expression. c!(x!y!z)!d!e!foo!mojo - b sent it to c. (x!y!z)!d!e!foo!mojo - c is FORCED to send it to x. (y!z)!d!e!foo!mojo - x sends it to y. (z)!d!e!foo!mojo - y sends it to z. d!e!foo!mojo - z is FORCED to send it to d. The '('s meet and they go away. foo!mojo - d can send directly to foo, and does. here mojo gets the message. Some additional notes, expressions can be nested. Such as: a!(b!c!(x!y!z))!d!e!(foo)!g!mojo a MUST send to b; c MUST send to x; z MUST send to d; e MUST send to foo; foo MUST send to g. chongo/\(--)/\ -- ~ Imagine UN*X source, being in the public domain... ~ J. Alton 84'