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'