Subject: Re: Source routing syntax
From: Keith Moore <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Date: Sun, 23 Dec 2001 10:15:30 -0500
List-Id: <ietf-822.imc.org>

> >> I'm pretty confident that DNS fragmentation is going to happen.
> >
> > others do not share your confidence.  yes, there are self-proclaimed
> > alternate roots.  no, they do not have significant buy-in.
> 
> Please have a look at:
> 
> http://siliconvalley.internet.com/news/article/0,2198,3531_944171,00.html
> http://news.cnet.com/news/0-1005-200-8236459.html?tag=ch_mh
> http://www.intern.de/news/2403.html
> 
> Even if the numbers are exaggerated by an order of magnitude, they
> start to become significant.
> 
> The way New.net changes network hosts to use their namespace is quite
> remarkable, too.

ISP buy-in is one thing; user buy-in is quite another.  It will be 
interesting to see whether purchasers of these names are disappointed 
that they cannot be used throughout the Internet in email addresses
and URLs.

Keith

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Source routing syntax
From: Florian Weimer <[email-masked]>
Date: Sun, 23 Dec 2001 16:11:10 +0100
Lines: 18
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> I'm pretty confident that DNS fragmentation is going to happen.  
>
> others do not share your confidence.  yes, there are self-proclaimed
> alternate roots.  no, they do not have significant buy-in.

Please have a look at:

http://siliconvalley.internet.com/news/article/0,2198,3531_944171,00.html
http://news.cnet.com/news/0-1005-200-8236459.html?tag=ch_mh
http://www.intern.de/news/2403.html

Even if the numbers are exaggerated by an order of magnitude, they
start to become significant.

The way New.net changes network hosts to use their namespace is quite
remarkable, too.

Date: Sun, 09 Dec 2001 15:31:19 -0700
From: Chris Newman <[email-masked]>
To: Marc Mutz <[email-masked]>, [email-masked]
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Sender: [email-masked]

--On Wednesday, December 5, 2001 16:08 +0100 Marc Mutz <[email-masked]> wrote:
> KMail now has UTF-7 support (ie. it does understand that charset, but
> doesn't use it actively).
> Are there any interoperability concerns with UTF-7?

Yes, there are.

First, many people don't realize that UTF-7 is actually a double-encoding. 
It's a second layer of encoding on top of UTF-16 which is an encoding of 
UCS-4.  As of the most recent Unicode spec, this is a problem for 
non-English languages.  UTF-8 is a single encoding (yes, quoted-printable 
UTF-8 is double encoded, but it's handled cleanly by separate layers and 
isn't needed often).

Also suppose I don't have a Unicode-aware email client, but I do have a 
Unicode aware editor.  Most Unicode aware editors support UTF-16 and UTF-8, 
but don't support UTF-7.  Thus UTF-8 is more likely to be readable by a 
recipient than UTF-7.  And in the rare case 7-bit encoding is needed, 
virtually every client can remove quoted-printable, while only UTF-7 aware 
clients can do anything useful.

Also note that US-ASCII is _not_ a subset of UTF-7, since UTF-7 steals a 
character as an escape.  This can cause all sorts of interoperability 
problems.

I could go on with more interop problems.

UTF-7 is a really bad idea in email.  _Please_ don't generate it.

		- Chris

Date: 08 Dec 2001 13:41:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
cc: [email-masked]
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Katsuhiko Momoi)  wrote on 05.12.01 in <[email-masked]>:

> 4. There is a bit of problem in Mozilla/Netscape 6 for replying to
> messages encoded in UTF-7. The mail compose window lists only standard
> (or near-consensus standard) encodings. In replying to a UTF-7 message,
> the charset of the reply mail will reflect the original encoding. But
> that item (UTF-7) will not be visible on the Compose window encoding
> menu because it is not on the default list of the recommended mail-send
> encoding. One might say that this is a bug in Mozilla but my feeling is
> that we should promote only standard or near standard mail encodings. I
> don't believe we should unnecessarily increase send-mail encodings in use.

One possible solution is to list the "standard" encodings and the single  
replied-to encoding.

MfG Kai

From: Keith Moore <[email-masked]>
To: Florian Weimer <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Source routing syntax 
Date: Fri, 07 Dec 2001 07:38:55 -0500
Sender: [email-masked]

> I'm pretty confident that DNS fragmentation is going to happen.  

others do not share your confidence.  yes, there are self-proclaimed
alternate roots.  no, they do not have significant buy-in.

and I can't support the idea that we should adapt every application, 
and every user, to do source-routing.

what with NATs fragmenting the IP space and alternate roots trying
to fragment the DNS space, it's a wonder we can still network at all.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Source routing syntax
From: Florian Weimer <[email-masked]>
Date: Fri, 07 Dec 2001 12:00:21 +0100
Lines: 16
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> frankly, it would be really insane to re-establish source routing 
> for email in order to make it easier to fragment DNS.   if we're
> going to take two giant steps backward in networking, why not go 
> all the way back to semaphores and smoke signals?

I'm pretty confident that DNS fragmentation is going to happen.  In
fact, it has already taken place.  If you are a company which is
among the first to gain control over a moderately sized DNS fragment,
you can make a lot of money, probably comparable to the existing
registrars.  So there's a big short-term economic incentive to
fragment DNS, although it certainly is a major step backwards.

However, email should continue to work in such horror scenarios Maybe.
the percent hack is enough for that, though                          .

To: [email-masked] (Kai Henningsen)
Cc: [email-masked]
Subject: Re: Source routing syntax
From: Florian Weimer <[email-masked]>
Date: Fri, 07 Dec 2001 11:55:54 +0100
Lines: 5
Sender: [email-masked]

[email-masked] (Kai Henningsen) writes:

> Wrong. # describes a comma-separated list. See 2.7.

I stand corrected, and apologize for writing garbage.

Date: Thu, 06 Dec 2001 21:35:40 -0800 (PST)
From: [email-masked]
Subject: Re: Source routing syntax
To: Pete Resnick <[email-masked]>
Cc: [email-masked], Florian Weimer <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> On 12/6/01 at 2:47 PM -0800, [email-masked] wrote:

> >This unfortunately, does look to be a correct reading of the production:
> >
> >obs-domain-list =       "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
> >
> >I believe this rule should be something like:
> >
> >obs-domain-list =       "@" domain *([CFWS] "," *(CFWS / ",") "@" domain)

> Yup, I forgot about that error; it was pointed out to me not to long
> ago and needs to be fixed. Actually, because domain is surrounded by
> optional whitespace, simpler than your's is:

> obs-domain-list =       "@" domain *(1*("," [CFWS]) "@" domain)

You might want to submit this to the RFC Editor so they can put it on their
RFC errata page.

				Ned

Date: Thu, 6 Dec 2001 22:16:51 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Source routing syntax
Cc: Florian Weimer <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 12/6/01 at 2:47 PM -0800, [email-masked] wrote:

>This unfortunately, does look to be a correct reading of the production:
>
>obs-domain-list =       "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
>
>I believe this rule should be something like:
>
>obs-domain-list =       "@" domain *([CFWS] "," *(CFWS / ",") "@" domain)

Yup, I forgot about that error; it was pointed out to me not to long 
ago and needs to be fixed. Actually, because domain is surrounded by 
optional whitespace, simpler than your's is:

obs-domain-list =       "@" domain *(1*("," [CFWS]) "@" domain)

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: 06 Dec 2001 23:51:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Source routing syntax
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Florian Weimer)  wrote on 06.12.01 in <[email-masked]>:

> [email-masked] (Kai Henningsen) writes:
>
> > [email-masked] (Florian Weimer)  wrote on 02.12.01 in
> > <[email-masked]>:
> >
> >> The source routing syntax in RFC 2822 differs considerably from
> >> RFC 822.  Is this intentional?
> >
> > It does? How?
>
> RFC 822 route-addr:      <@host1@host2:user@target>

Wrong. # describes a comma-separated list. See 2.7.

> RFC 2822 obs-angle-addr: <@host1@host2:user@target>
>                          <@host1,@host2:user@target>
>                          <@host1 @host2:user@target>
>                          <@host1,,@host2:user@target>

True; I don't remember seeing that part discussed, but I expect it was to  
match some frequent misspellings. You just demonstrated why that might be  
necessary, by your misreading of 822.

MfG Kai

Date: Thu, 06 Dec 2001 14:47:40 -0800 (PST)
From: [email-masked]
Subject: Re: Source routing syntax
To: Florian Weimer <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] (Kai Henningsen) writes:

> > [email-masked] (Florian Weimer)  wrote on 02.12.01 in <[email-masked]>:
> >
> >> The source routing syntax in RFC 2822 differs considerably from
> >> RFC 822.  Is this intentional?
> >
> > It does? How?

> RFC 822 route-addr:      <@host1@host2:user@target>

This is incorrect. The rule specified in RFC 822 gives:

RFC 822 route-addr:      <@host1,@host2:user@target>
                         <@host1,,@host2:user@target>

Specifically, a route is defined as 

    route       =  1#("@" domain) ":"           ; path-relative

I suspect you're misinterpreting the #. # specifies a list of elements,
each separated by one or more commas. And whitespace may also appear.

> RFC 2822 obs-angle-addr: <@host1@host2:user@target>
>                          <@host1,@host2:user@target>
>                          <@host1 @host2:user@target>
>                          <@host1,,@host2:user@target>

This unfortunately, does look to be a correct reading of the production:

obs-domain-list =       "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)

I believe this rule should be something like:

obs-domain-list =       "@" domain *([CFWS] "," *(CFWS / ",") "@" domain)

				Ned

Date: Thu, 6 Dec 2001 16:30:53 -0600
To: Florian Weimer <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Source routing syntax
Cc: [email-masked] (Kai Henningsen), [email-masked]
Sender: [email-masked]

On 12/6/01 at 11:39 PM +0100, Florian Weimer wrote:

>RFC 822 route-addr:      <@host1@host2:user@target>
>RFC 2822 obs-angle-addr: <@host1@host2:user@target>
>                          <@host1,@host2:user@target>
>                          <@host1 @host2:user@target>
>                          <@host1,,@host2:user@target>

Nope, the above is just wrong. You've misread the ABNF. In 822:

      route-addr  =  "<" [route] addr-spec ">"

      route       =  1#("@" domain) ":"           ; path-relative

In 822 ABNF, # is defined as follows:

      2.7.  #RULE:  LISTS

           A construct "#" is defined, similar to "*", as follows:

                               <l>#<m>element

      indicating at least <l> and at most <m> elements, each  separated
      by  one  or more commas (","). This makes the usual form of lists
      very easy; a rule such as '(element *("," element))' can be shown
      as  "1#element".   Wherever this construct is used, null elements
      are allowed, but do not  contribute  to  the  count  of  elements
      present.   That  is,  "(element),,(element)"  is  permitted,  but
      counts as only two elements.  Therefore, where at least one  ele-
      ment  is required, at least one non-null element must be present.
      Default values are 0 and infinity so that "#(element)" allows any
      number,  including  zero;  "1#element" requires at least one; and
      "1#2element" allows one or two.

And, in 822 you are allowed free whitespace. So, in both 822 and 
2822, the following are legal as addresses with routes:

<@host1,@host2:user@target>
<@host1   ,     @host2:user@target>
<@host1,,@host2:user@target>

The comma between elements is required in both, any number of commas 
may appear between elements in both, and spaces are allowed around 
the commas in both.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked] (Kai Henningsen)
Cc: [email-masked]
Subject: Re: Source routing syntax
From: Florian Weimer <[email-masked]>
Date: Thu, 06 Dec 2001 23:39:58 +0100
Lines: 14
Sender: [email-masked]

[email-masked] (Kai Henningsen) writes:

> [email-masked] (Florian Weimer)  wrote on 02.12.01 in <[email-masked]>:
>
>> The source routing syntax in RFC 2822 differs considerably from
>> RFC 822.  Is this intentional?
>
> It does? How?

RFC 822 route-addr:      <@host1@host2:user@target>
RFC 2822 obs-angle-addr: <@host1@host2:user@target>
                         <@host1,@host2:user@target>
                         <@host1 @host2:user@target>
                         <@host1,,@host2:user@target>

Date: Wed, 05 Dec 2001 11:47:05 -0800
From: [email-masked] (Katsuhiko Momoi)
To: Marc Mutz <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Sender: [email-masked]

Hi,

The following might be of some use to you in making a decision.
Let me provide background info on what we did at Netscape for 
Communicator 4.x and Netscape 6/Mozilla mail.

1. Prior to Comm 4.5, we recommended UTF-7 as the default Unicode 
charset for mail.

2. After consulting several mail experts inside and outside Netscape, we 
decided to go with UTF-8 as the default charset for Comm 4.5 primarily 
for 2 reasons. First, UTF-7 has never gained the status of the default 
Unicode charset and instead UTF-8 was becoming the default Unicode 
charset.  Second, 8-bit encodings are not that problematical these days 
as evidenced by the fact that they are used as standard mail encodings 
in  Korean, Chinese and European languages.

3. While UTF-7 can be displayed by most major mail programs today, there 
is a question of promoting a single Unicode mail encoding. At least we 
thought it would be better if we stick to one encoding for Unicode 
sending messages. For dusplaying messages, we do support UTF-7.

4. There is a bit of problem in Mozilla/Netscape 6 for replying to 
messages encoded in UTF-7. The mail compose window lists only standard 
(or near-consensus standard) encodings. In replying to a UTF-7 message, 
the charset of the reply mail will reflect the original encoding. But 
that item (UTF-7) will not be visible on the Compose window encoding 
menu because it is not on the default list of the recommended mail-send 
encoding. One might say that this is a bug in Mozilla but my feeling is 
that we should promote only standard or near standard mail encodings. I 
don't believe we should unnecessarily increase send-mail encodings in use.

- Kat

Marc Mutz wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Wednesday 05 December 2001 16:37, Keith Moore wrote: 
>
>>>Is it safe to make UTF-7 the charset to use as "last 
>>>resort" instead of UTF-8? 
>>>
>>No.  The only charset supported by all major MUAs is ASCII. 
>>
> 
>Though I think you know very well what I meant, let me restate the 
>questions more precisely ;-) 
> 
>When sending a textual mail, we have to choose a charset that is capable 
>of representing all contained characters (internally, we use unicode) 
>to use for the text/plain body part. We currently try us-ascii,<locale 
>charset>,utf-8 (in that order). So you could see UTF-8 as a fallback 
>for _text/plain bodypart charsets_. 
> 
>Now, we are discussing making UTF-7 that default instead of UTF-8, 
>because it doesnt need further Content-Transfer-Encoding processing on 
>top of it. 
> 
>Would we seriously decrease interoperability with other mail clients by 
>doing this? And don't tell me: "Yes, with all those who don't speak 
>anything but us-ascii" because they are not a likely target of a mail 
>that someone sends, but which can't be represented in his own locale's 
>charset. Also, the question is not "shall we use charsets other than 
>us-ascii", but "is it OK to use UTF-7 where we'd else use UTF-8"? 
> 
>Hope I made my question clear enough this time. :-) 
> 
>Marc 
> 
>- --  
>An der Prioritätenskala wehrhafter Demokratien gibt es nichts zu 
>deuteln: Erst kommt die Stärke, dann Freiheit Hand in Hand mit der 
>Gerechtigkeit und in der Nachhut trottet der Frieden hinterher. 
>    -- Goedart Palm "Der Friedensnobelpreis und ein bisschen Krieg" 
>       Telepolis 2001/10/13 (#9807) 
> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE8Dmmc3oWD+L2/6DgRAj3uAKCbzdKqh099aal6TbAjg/zh7zZKNACfRJ3W
>vIvm0mtF8Tu5eZ8BwHsqVtE=
>=2mo6
>-----END PGP SIGNATURE-----
>

-- 
Katsuhiko Momoi <[email-masked]>
Senior International Manager, Web Standards/Embedding
Netscape Technology Evangelism/Developer Support

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Pete Resnick <[email-masked]>
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Date: Wed, 5 Dec 2001 20:39:12 +0100
Cc: [email-masked]
Sender: [email-masked]

On Wednesday 05 December 2001 18:09, Pete Resnick wrote: 
<snip> 
> Though many MUA's support UTF-7 if they also support UTF-8, I know of 
> none that supports it by default. UTF-7 is really all but dead. I 
> don't think it's worth it. 
<snip> 
 
Thanks. Meanwhile I also found the IMC's report that deprecates utf-7. 
 
Marc 
 
- --  
"Similia similibus currentur" 
           -- Bush's new motto in fighting terrorism. 

Date: Wed, 5 Dec 2001 11:09:17 -0600
To: Marc Mutz <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

On 12/5/01 at 7:38 PM +0100, Marc Mutz wrote:

>Now, we are discussing making UTF-7 that default instead of UTF-8, 
>because it doesn't need further Content-Transfer-Encoding processing 
>on top of it.

Given that you can use the ESMTP 8BITMIME extension to avoid the 
transfer encoding and that UTF-7 is a pretty gross encoding for a 
charset itself, I would recommend not making it the default fallback. 
Though many MUA's support UTF-7 if they also support UTF-8, I know of 
none that supports it by default. UTF-7 is really all but dead. I 
don't think it's worth it.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 05 Dec 2001 08:51:41 -0800 (PST)
From: [email-masked]
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
To: Marc Mutz <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

> Now, we are discussing making UTF-7 that default instead of UTF-8,
> because it doesnt need further Content-Transfer-Encoding processing on
> top of it.
 
> Would we seriously decrease interoperability with other mail clients by
> doing this?

Yes you would. UTF-7 never really caught on so support is very limited. UTF-8
is the preferred charset.

				Ned

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Keith Moore <[email-masked]>
Subject: Re: UTF-7 vs. UTF-8 for fallback charset?
Date: Wed, 5 Dec 2001 19:38:20 +0100
Cc: [email-masked]
Sender: [email-masked]

On Wednesday 05 December 2001 16:37, Keith Moore wrote: 
> > Is it safe to make UTF-7 the charset to use as "last 
> > resort" instead of UTF-8? 
> 
> No.  The only charset supported by all major MUAs is ASCII. 
 
Though I think you know very well what I meant, let me restate the 
questions more precisely ;-) 
 
When sending a textual mail, we have to choose a charset that is capable 
of representing all contained characters (internally, we use unicode) 
to use for the text/plain body part. We currently try us-ascii,<locale 
charset>,utf-8 (in that order). So you could see UTF-8 as a fallback 
for _text/plain bodypart charsets_. 
 
Now, we are discussing making UTF-7 that default instead of UTF-8, 
because it doesnt need further Content-Transfer-Encoding processing on 
top of it. 
 
Would we seriously decrease interoperability with other mail clients by 
doing this? And don't tell me: "Yes, with all those who don't speak 
anything but us-ascii" because they are not a likely target of a mail 
that someone sends, but which can't be represented in his own locale's 
charset. Also, the question is not "shall we use charsets other than 
us-ascii", but "is it OK to use UTF-7 where we'd else use UTF-8"? 
 
Hope I made my question clear enough this time. :-) 
 
Marc 
 
- --  
An der Prioritätenskala wehrhafter Demokratien gibt es nichts zu 
deuteln: Erst kommt die Stärke, dann Freiheit Hand in Hand mit der 
Gerechtigkeit und in der Nachhut trottet der Frieden hinterher. 
    -- Goedart Palm "Der Friedensnobelpreis und ein bisschen Krieg" 
       Telepolis 2001/10/13 (#9807) 

From: Keith Moore <[email-masked]>
To: Marc Mutz <[email-masked]>
cc: [email-masked]
Subject: Re: UTF-7 vs. UTF-8 for fallback charset? 
Date: Wed, 05 Dec 2001 10:37:08 -0500
Sender: [email-masked]

> Is it safe to make UTF-7 the charset to use as "last
> resort" instead of UTF-8?

No.  The only charset supported by all major MUAs is ASCII.

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: UTF-7 vs. UTF-8 for fallback charset?
Date: Wed, 5 Dec 2001 16:08:18 +0100
Sender: [email-masked]

Hi! 
 
KMail now has UTF-7 support (ie. it does understand that charset, but 
doesn't use it actively). 
Are there any interoperability concerns with UTF-7? Is it supported by 
all major MUAs? Is it safe to make UTF-7 the charset to use as "last 
resort" instead of UTF-8? 
 
Marc 
 
- --  
It is truly ironic that the United States, once the beacon for 
promoting the principles of freedom of expression, is now 
systematically infecting other countries with this dangerous public 
policy choice [the DMCA] that will restrict more speech than any law 
before it.    -- EFF FTAA Alert: 
                 Stop Hollywood Forcing Technology Ban on 34 Countries 

Date: 05 Dec 2001 08:32:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Source routing syntax
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Florian Weimer)  wrote on 02.12.01 in <[email-masked]>:

> The source routing syntax in RFC 2822 differs considerably from
> RFC 822.  Is this intentional?

It does? How?

> I think it's a bit premature to abolish source routing.  Source
> routing might become a valuable tool in a future fragmented DNS.

I don't see a fragmented DNS becoming a serious problem - if it could, it  
already would have.

And I *do* see *lots* of MTAs that have already blocked source routing,  
because it's attractive to spammers.

MfG Kai

From: Keith Moore <[email-masked]>
To: Florian Weimer <[email-masked]>
cc: [email-masked]
Subject: Re: Source routing syntax 
Date: Sun, 02 Dec 2001 18:27:41 -0500
Sender: [email-masked]

> I think it's a bit premature to abolish source routing.  Source
> routing might become a valuable tool in a future fragmented DNS.

you're a little late.  source routing was effectively abolished
when RFC 1123 was published...at least, hosts were not required
to honor it then.

frankly, it would be really insane to re-establish source routing 
for email in order to make it easier to fragment DNS.   if we're
going to take two giant steps backward in networking, why not go 
all the way back to semaphores and smoke signals?

Keith

To: [email-masked]
Subject: Source routing syntax
From: Florian Weimer <[email-masked]>
Date: Sun, 02 Dec 2001 19:13:39 +0100
Lines: 5
Sender: [email-masked]

The source routing syntax in RFC 2822 differs considerably from
RFC 822.  Is this intentional?

I think it's a bit premature to abolish source routing.  Source
routing might become a valuable tool in a future fragmented DNS.