Source routing syntax
Florian Weimer
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.
Keith Moore
> 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
Florian Weimer
ka...@khms.westfalen.de (Kai Henningsen) writes:
> f...@deneb.enyo.de (Florian Weimer) wrote on 02.12.01 in <871yidh...@deneb.enyo.de>:
>
>> 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>
Pete Resnick
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:pres...@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
ned+ie...@mrochek.com
> ka...@khms.westfalen.de (Kai Henningsen) writes:
> > f...@deneb.enyo.de (Florian Weimer) wrote on 02.12.01 in <871yidh...@deneb.enyo.de>:
> >
> >> 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
Pete Resnick
On 12/6/01 at 2:47 PM -0800, ned+ie...@mrochek.com 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)
ned+ie...@mrochek.com
> On 12/6/01 at 2:47 PM -0800, ned+ie...@mrochek.com 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
Florian Weimer
ka...@khms.westfalen.de (Kai Henningsen) writes:
> Wrong. # describes a comma-separated list. See 2.7.
I stand corrected, and apologize for writing garbage.
Florian Weimer
Keith Moore <mo...@cs.utk.edu> 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 .
Keith Moore
> 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.
Florian Weimer
Keith Moore <mo...@cs.utk.edu> 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.
Keith Moore
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