Subject: #1003 USEFOR 3.1.3 - Resolution of msg-id issues

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Jun 2005 07:32:23 -0400

Ticket #1003 says:

> From Frank Ellermann:
>
>| no-fold-quote = DQUOTE
>| ( "." mqtext /
>| *mqtext "." /
>| *mqtext mqspecial *mqtext )
>| DQUOTE
>
> s/mqtext/*mqtext/
>
> The msg-id = id-left "@" id-right style of syntax is ugly and
> doesn't indicate the intended semantics id-local "@" id-domain
>
> Overloading 2822 no-fold-quote by something else is confusing.
> a simple ( DQUOTE id-quote DQuOTE ) is clearer.
>
> Overloading 2822 no-fold-literal by something else is ugly, a
> simple id-literal is clearer
>
> The terms mqtext, mqspecial, and mdtext are cryptic (mq means
> "something in msg-id no-fold-quote", the d in md probably means
> "domain-literal").
>
> id-text, id-special, and id-literal are clearer (stuff needed
> only in a msg-id, no separate no-fold-literal vs. mdtext). See
> also <http://mid.gmane.org/[email-masked]>

I recorded 2 comments - from Charles Lindsey and Frank Ellermann - 
indicating that the replacement mqtext/*mqtext was correct, but on the 
naming issue Charles said:

> you have raised all these before, but nobody supported you
> and our Chair said to leave it be.

If nobody else wishes to reopen the issue of the names of the productions, 
I'm going to resolve the ticket as "just replace mqtext with *mqtext".

OK?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Jun 2005 15:05:29 +0200

> OK?

There's a dispute about the meaning of <id-right>.  I say it's
in fact an <id-domain>, a proper name space with an owner.

TTBOMK Charles says, whatever it is, in a msg-id it's case
sensitive.  These positions aren't incompatible, but somewhat
different.  I'm obsessed with the (2)822 semantics, Charles is
more interested in a visual similarity to RfC 2822 <id-right>.

Message-IDs are at the very core of Netnews.  More than three
opinions about it for a clearer rough consensus might help.
Henry and Russ refuse to discuss it.  Maybe somebody else has
an opinion.
                         Bye, Frank

msg-id       =  "<" id-local "@" id-domain ">"

id-local     = dot-atom-text / ( DQUOTE id-quote DQUOTE )
id-quote     = ( "." [id-text] ) /
               ( [id-text] "." ) /
               ( [id-text] id-special [id-text] )

id-text      = 1*( atext / "." / id-special )
id-special   = "(" / ")" / "," /       ; all specials, minus ">",
               "[" / "]" / "@" /       ; minus DQUOTE, minus "\",
               ":" / ";" / "<" /       ; minus single ".", plus:
               ".." / "\\" / ( "\" DQUOTE )

id-domain    = dot-atom-text / ("[" id-literal "]")
id-literal   = 1*( %d33-61 /           ; printable ASCII minus
                   %d63-90 /           ; ">", "[", "\", "]"
                   %d94-126 /          ; plus "\[", "\\, "\]"
                   "\[" / "\\" / "\]" )

---

From: Sebastian Brocks <[email-masked]>
Date: Tue, 14 Jun 2005 15:22:24 +0200

> in fact an <id-domain>, a proper name space with an owner.

(...)

> Maybe somebody else has

I agree with your position.

greetings, Sebastian

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Jun 2005 13:11:08 GMT

>> OK?

Fine with me.

>in fact an <id-domain>, a proper name space with an owner.

Frank has been flogging this for months, but appears to have gathered no
support.

RFC 2822 RECOMMENDS that a domain should be used as the <id-right>, and
this is indeed good practice. But once the <id-right> has been generated,
it is a domain no longer, but just a string of characters to be compared
for equality, or copied (as into a References header).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2005 22:03:03 +0200

Charles Lindsey wrote:
 
> Frank has been flogging this for months, but appears to have
> gathered no support.

Now you did correct the broken msg-id syntax wrt to the weird
NO-WS-CTL, you also corrected the missing leading and trailing
dot issue.  

Yes, that took some months while we discussed what the msg-id
actually _is_, analyzing different versions of domain-literal.

IIRC we also agreed to add something along the line of STD 11:
| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

One issue where I didn't gather support were the names of the
productions.  At the moment it appears to be a tie (2:2), bye.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 16 Jun 2005 11:52:43 GMT

>| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

I think we already inherit that advice from RFC 2822 (along with the
RECOMMENDATION to use domains).

But I would have no problem with repeating the advice in USEFOR (but some
people are dead set against repeating _anything_ from RFC 2822 - not that
I am against it if if it helps make thing clearer).

I think it's up to Harald now.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Jun 2005 22:42:45 +0200

Charles Lindsey wrote:
 
>> we also agreed to add something along the line of STD 11:
 
> I think we already inherit that advice from RFC 2822 (along
> with the RECOMMENDATION to use domains).

No, we would inherit the erroneous contrary, 2822 says:

| a good method is to put the domain name (or a domain literal
| IP address) of the host on which the message identifier was
| created on the right hand side of the "@"

Domain literal is _not_ a good method.  RfC 2822 also doesn't
discourage domain literals generally like STD 11.  We have to
fix it by a clear SHOULD NOT as in STD 11.

Section 3.6.4 in 2822 is not good enough for NetNews or other
serious applications of Message-IDs like mailing list archives.

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Jun 2005 13:22:27 GMT

>| created on the right hand side of the "@"

2822 says more than that. A little further down:

   ....  Though other algorithms will work, it is
   RECOMMENDED that the right hand side contain some domain identifier
   (either of the host itself or otherwise) such that the generator of
   the message identifier can guarantee the uniqueness of the left hand
   side within the scope of that domain.

>fix it by a clear SHOULD NOT as in STD 11.

Hold on! We never agreed that domain literals were a Bad Thing to use in
an <id-right>. What we DID agree was that such literals had better be an
IP address in some accepted notation (which is hinted at, but not made
absolutely clear, by some wording in RFC 2822 in connection with
<addr=spec>s, where it says "In the domain-literal form, the domain is
interpreted as the literal Internet address of the particular host").

So what we wrote (and it is now in USEFOR-04) was:

      NOTE: It is RECOMMENDED in [RFC2822] that, for ensuring global
      uniqueness, the <id-right> be some domain identifier within whose
      scope the uniqueness of the <id-left> can be guaranteed.  When
      following this recommendation, any <dot-atom-text> or <no-fold-
      literal> used for the <id-right> are to be interpreted as
      <domain>s as described in Section 3.4.1 of [RFC2822].

Now you might make that clearer by changing the last sentence:

      Hence, when following this recommendation, any <no-fold-literal>
      used for the <id-right> should be of the form of an Internet
      address, in accordance with Section 3.4.1 of [RFC2822].

That would be fine by me if Harald and Ken are agreeable.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Jun 2005 20:50:04 +0200

> 2822 says more than that. A little further down:
[...]
>| some domain identifier

Yes, that's not good enough, it SHOULD be FQDN allowing domain
literal only for special cases.

>> RfC 2822 also doesn't discourage domain literals generally
>> like STD 11.  We have to fix it by a clear SHOULD NOT as in
>> STD 11.

> Hold on! We never agreed that domain literals were a Bad
> Thing to use in an <id-right>.

That's not how I recall it, and a domain-literal is everywhere
a Bad Thing:

It's bad in the path-identifier where it breaks Bruce's B-News
monster in the case of IPv6 colons.

It's bad in reply addresses where normal users with a normal
smart host and a normal MUA (not-direct to IP, let alone IPv6)
might be unable to use it.

It's bad in an <id-domain> in the case of dynamic or reserved
IPs without a clear owner of this name space - discussing havoc
caused by msg-id collisions with say IANA is pointless.

So it's a Bad Thing everywhere, exactly as STD 11 says.

>| any <no-fold-literal> used for the <id-right> should be of
>| the form of an Internet address, in accordance with Section
>| 3.4.1 of [RFC2822].

All these tons of text are so obvious and unnecessary if you'd
only replace the bogus 2822 notation <id-right> by <id-domain>.

STD 11 is also normative for RfC 1036, so if you introduce the
unclear <id-right> concept in USEFOR this would also pop-up in
a "differences from RfC 1036" appendix:  "random garbage in the
<id-right> of a <msg-id> is now allowed, but not recommended".

No idea how you can hope to smuggle this through a "last call".

                         Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 20 Jun 2005 11:12:53 GMT

>literal only for special cases.

Why? If it's good enough for RFC 2822, it's good enough for us.

>That's not how I recall it, ...

Feel free to trawl the archives.

>monster in the case of IPv6 colons.

By the time IPv6 addresses actually come to be used in a Path header, one
can reasonably suppose that software will have been upgraded. Even where it
is not, it is only the un-upgraded site that will experience any problem
(i.e. it may erroneously relay an article to a peer that has already had
it).

>might be unable to use it.

All current UAs should (and AIUI do) send mail correctly to addresses using
domain literals.

>caused by msg-id collisions with say IANA is pointless.

It won't cause havoc unless two sites have been allocated the same dynamic
IP, in which case they already have severe problems with all sorts of
protocols.

>So it's a Bad Thing everywhere, exactly as STD 11 says.

No.

><id-right> of a <msg-id> is now allowed, but not recommended".

A domain literal (if it is syntactically a valid Internet address) is not
"random garbage".

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Jun 2005 12:48:41 +0200

> IP, in which case they already have severe problems with all sorts of

10.0.0.1.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 19:31:08 +0200

>> Yes, that's not good enough, it SHOULD be FQDN allowing
>> domain literal only for special cases.

> Why? If it's good enough for RFC 2822, it's good enough

RfC 2822 missed the idea of Message-IDs, a globally unique
identifier forever.  Where collisions and abusing foreign
name spaces may have all sorts of undesirable side effects.

It's already clear that we cannot use the old 2822 msg-id
syntax.  For NetNews our starting point is RfC 1036 anyway,
that's based on 822, and 822 said:

| THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Everywhere to the right of an "@" or in path identities.

> Feel free to trawl the archives.

<http://mid.gmane.org/[email-masked]>
<http://mid.gmane.org/[email-masked]>
<http://mid.gmane.org/[email-masked]>

> All current UAs should (and AIUI do) send mail correctly
> to addresses using domain literals.

Not here. my UA sends mails to its configured smart hosts,
and these smart hosts reject all mails to domain literals:
"administrative restriction".

>> It's bad in an <id-domain> in the case of dynamic or
>> reserved IPs without a clear owner of this name space
[...]

> It won't cause havoc unless two sites have been allocated
> the same dynamic IP

No, that's wrong.  They only need a simple algorithm for
the LHS creating the <id-local> adding the same <id-domain>
like [127.0.0.1] (the worst case) or just whatever dynamic
IP they have.

If it's the same <id-local> and the same IP it could cause
harm.  Even after weeks, it's not only about simultaneously.

The only way to get a msg-id right is a proper name space,
and that's normally an FQDN in the <id-domain>.  A static
IP is also fine.  A dynamic IP is dangerous.  A private IP
might be FUBAR.  For IPv6 it depends, still a very bad idea
in the path or addresses, but maybe okay for a msg-id.  Bye

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 16:26:47 -0400

On Tue June 14 2005 09:05, Frank Ellermann wrote:
> sensitive.

RFC 2822 is crystal clear on the semantics and the nature of the
syntax differences from 822 and 2822 angle-addr:

   Since the msg-id has
   a similar syntax to angle-addr (identical except that comments and
   folding white space are not allowed), a good method is to put the
   domain name (or a domain literal IP address) of the host on which the
   message identifier was created on the right hand side of the "@", and
   put a combination of the current absolute date and time along with
   some other currently unique (perhaps sequential) identifier available
   on the system (for example, a process id number) on the left hand
   side.

In RFC 822, the syntax was in fact identical; because of input specifically
related to Usenet the syntax was changed to exclude CFWS.   The semantics
hasn't changed, id-right is still a domain name or domain literal, and
there is nothing in 2822 that even *suggests* case-sensitivity.

>                    %d94-126 /          ; plus "\[", "\\, "\]"

Usefor draft -04 section 1.6 states:

   This document uses a cite by reference methodology, rather than
   repeating the contents of other standards, which could otherwise
   result in subtle differences and interoperability challenges.
   Although this document is as a result rather short, it requires
   complete understanding and implementation of the normative references
   to be compliant.

Given the stated methodology and the rationale for it (especially
"otherwise result in subtle differences and interoperability challenges"),
as well as the basis of our document supposed to be 2822, and the
suggestion made years ago by Mark Crispin, viz:

  NNTP Transport Requirements

     The BLURDYBLOOP command in NNTP uses the message-id as an argument.
     The syntax for this command does not provide any way for spaces to
     appear in the message-id.  Therefore, message-ids in the Message-ID,
     In-Reply-To, and References headers of a message MUST NOT contain
     the space character.

I can see no reason for an incompatible redefinition in our document.

The sole purpose of the incompatible redefinition of msg-id, already
defined in RFC 2822 making concessions to specific Usenet issues,
seems to be to:
1. eliminate some legal, unchanged-since-822 local-part constructs that
   somebody doesn't like (but I've seen no description of real issues
   similar to those of Mark's suggestion) (N.B. the WS part of CFWS is
   already excluded by 2822).
2. force-fit the existing IP address literal restrictions into the
   syntax instead of simply saying "an IP address literal must conform
   to the syntax of STD 3 (IPv4) or RFC 3513 (IPv6) or any future IP
   address literal syntax that may be approved by the IESG".  Of
   course, that's already implicit in the semantic definition of RFC
   2822 domain-literal/no-fold-literal, so nothing need be said at all
   (avoiding the somewhat tricky issue of 3513 successors and future
   directions.
3. introduce incompatible use of 822/2822 "special"s in the LHS. That
   is not backwards compatible (it may break IMAP and other Standards
   Track protocols).  In particular (but by no mens the sole problem),
   introduction of unquoted parentheses in the LHS of a msg-id in
   structured fields (especially since comments were permitted by RFC
   822) is begging for interoperability problems.  Especially as the
   proposed syntax would permit *unbalanced* parentheses.  That's
   going to break all sorts of quick-and-dirty hacks, and we all
   know that there are plenty of those around.

My recommendation is to leave msg-id as defined in our primary normative
reference RFC 2822 and to add such notes along the lines suggested by
Mark as may be required, keeping those (in the format document) to the
bare minimum necessary to deal with specific external protocol issues
such as NNTP.  A personal dislike for some RFC 822/2822 feature wouldn't
qualify, nor would some specific broken UA that can't handle legal 822
syntax not explicitly forbidden by RFC 1036.  Length limits in some
ancient implementations might barely qualify for such a note (NNTP's
limit of ca. 500 octets would warrant a brief note, but doesn't encroach
on legal domain names), but said note should also observe that legal
domain names may be as long as 255 octets, and should strongly recommend
that software with such incompatible limits be upgraded ASAP.  Such
notes about ancient implementations might even be relegated to a
separate informational document.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 21:33:08 -0400

> > Thing to use in an <id-right>.

Frank has a valid point; 127.0.0.1, 192.168.0.1, 10.0.0.1,
172.16.0.1, 192.0.0.1, 224.0.0.1, 169.254.0.1, and many similar
IP address literals lack the uniqueness characteristic necessary
for some uses (including msg-id domain lierals).

A dynamic IP address might be usable if the LHS has a timestamp
as suggested in RFC 2822.

A static, Internet-routable IP address literal is OK for a msg-id
RHS.

A note pointing out the limitations of dynamic IP addresses and
the unsuitability of unroutable, example, loopback, DHCP negotiation,
and multicast IP addresses should suffice.  This isn't a syntax or
semantics issue, nor a protocol issue per se; it could go in USEAGE.

------ new topic -------
 
> monster in the case of IPv6 colons.

It breaks C news and INN as well.  Moreover, as recently reaffirmed
by Russ, INN has no special treatment of numeric-plus-dots names in
the Path field due to severe performance issues associated with
such special treatment.  Note that the Path field as currently
defined has no provision for comments; the justification given for
that in earlier drafts was that the processing to treat comments
as whitespace (i.e. essentially to ignore them) would be an onerous
performance problem.  Russ has noted that DNS lookups can take quite
a long time.  The implications for path field components is clear:
they have to be treated purely as public names, not as IP address
literals.  That obviates any argument about backwards compatibility
breaking reassignment of colon (ostensibly for IPv6 literals), and
it means that I don;t have to remind Charles that his claim that
handling of e.g. dead:beef would affect only one site and not sites
named "dead" or "beef" or their neighbors and downstream sites has
been twice debunked before he recently repeated it.

Specific change to USEFOR -04 text: remove colon from path-identity
ABNF production.

As the text currently doe not mention IP address literals and does
use "name" (albeit only in a note), no other change is necessary
(semantic clarification that components are public names would
however be welcome).

The second note claims that component names "are traditionally in
lower case", but I've seen mixed case and upper-case names.  I'd
like to see that text elided. possibly replaced with a statement
that a choice of name of "POSTED", "MISMATCH", or even "PoStEd"
would be a really bad idea.  That of course assumes that we want
to continue pursuing introduction of those keywords.
 
---- returning to msg-id -----

> only replace the bogus 2822 notation <id-right> by <id-domain>.

Here we disagree, as I have noted separately.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Jun 2005 18:54:47 GMT

><http://mid.gmane.org/[email-masked]>

I see nothing in those messages to indicate that anybody but yourself had
accepted the idea that domain-literals (assuming they actually looked like
an Internet address) were to be discouraged.

>"administrative restriction".

Then those smart hosts are broken.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Jun 2005 21:26:52 GMT

>for some uses (including msg-id domain lierals).

Indeed, there are lots of stupid domain literals that should not be used
as an <id-right>, but RFC 2822 already has that problem (and it is not our
job to fix RFC 2822). I would have thought the point obvious enough that
we do not need to mention it explicitly.

>as suggested in RFC 2822.

Exactly. In fact, and IP address over which you have sole control at that
exact moment in time is OK (or you have some agreement with the person who
_does_ have such sole control).

>....  This isn't a syntax or

Possibly.

>such special treatment.

I do not recall that there was any performance issue. They are just a
string of characters like any other <path-identity>.

>....  Russ has noted that DNS lookups can take quite
>literals.

Absolutely. But I don't expect DNS lookups for <path-identity>s on a
routine basis (indeed, our text used to say that, but it was one of Brad
Templeton's excesses that I got rid ot).

Though when it comes to implementing our new arrangements for catching
MISMATCHes, there will be a little extra work to do - probably involving
a cache of known path-identities for each peering site.

>  That obviates any argument about backwards compatibility

I think it has always been well understood that the benefit of being able
to handle IPv6 addresses outweighed some possible inconvenience to sites
that used some rather unusual <path-identity>s. If the sites "dead" and
"beef" find that some idiot has invented a site "dead:beef", and if they
find that they are receiving too many articles twice over in consequence,
then they will have to deal with it as best they can. It is already
well-known that there are idiot sites out there, and Usenet has always
managed to work its way around them.

>Specific change to USEFOR -04 text: remove colon from path-identity

So you would rather throw out a much needed facility than put up with a
rather improbable minor inconvenience? Please come and join us in the Real
World for a change.

>to continue pursuing introduction of those keywords.

Again, there is a limit as to how far one should go to deal with idiotic
sysadmins.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Jun 2005 19:18:24 GMT

>   on the system (for example, a process id number) on the left hand

In RFC 2822 an <id-right> is a string of characters satisfying some ABNF.
It has no semantics attached to it (except that a `\` in a <quoted-pair>
is "invisible"). If you generate such an <id-right> by "putting" a <domain>
in there, it is still an <id-right> (even if it happens to look like a
<domain>) and it still has no further semantics, and hence no requirement
to be considered case insensitively at any stage.

In our draft, the same is true (except that we have fixed the
<quoted-pair> problem). But, for the removal of all doubt, we have also
excluded your bizarre interpretation by stating the intent that an
octet-by-octet comparison will always suffice.

>hasn't changed,

Yes, it has changed (whether intended so or not).

>I can see no reason for an incompatible redefinition in our document.

The differences in the <msg-id> in our document are essential for
technical reasons that have been explained so many times that I will not
repeat them here.

>defined in RFC 2822 making concessions to specific Usenet issues,

Those concessions turned out to be insufficient for the essential
requirement of Netnews that an octet-by-octet comparison of <msg-id>s
would always suffice.

>Mark as may be required,

No, Mark made his suggestion (in the NNTP list, I believe) in the belief
that he was describing a temporary problem that would be fixed in future
implementations. He was rapidly disabused of that notion.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Jun 2005 00:43:43 +0200

Bruce Lilly wrote:

> A dynamic IP address might be usable if the LHS has a
> timestamp as suggested in RFC 2822.

Please note the *if* here, timestamps are not the only
way to create some form of <id-local> - especially not
for devices so desperate that they use a domain literal
as <id-domain> instead of a proper FQDN.

While it's a bad idea some algorithms might try hashes
and / or counters.  Even if they use timestamps the way
how they encode them in a <id-local> varies.

Different local times on different machines are also a
source for insufficient <id-local> concepts.  All these
unclear conditions covered by a very simple STD 11 rule:

> A static, Internet-routable IP address literal is OK
> for a msg-id RHS.

Yes.

> A note pointing out the limitations of dynamic IP
> addresses and the unsuitability of unroutable, example,
> loopback, DHCP negotiation, and multicast IP addresses
> should suffice.

E.g. the STD 11 rule translated to 2119 SHOULD NOT style.

> nor a protocol issue per se; it could go in USEAGE.

USEAGE is not on the same level as STD 11, and IMHO it's a
protocol issue in many cases.

As far as USEFOR and msg-id are concerned there's already
a note in chapter 5 (security considerations).

When it comes to domain literals my mental picture is an
independent Web cam without FQDN and clock connected to
the public Internet.  Maybe it tries to post pictures.

Yes, ridiculous, but the HTTP/1.1 spec. manages to allow
for such "Web server without clock" cases - IIRC it says
SHOULD instead of MUST at a critical place about "Date:".

 [path]
> the text currently does not mention IP address literals

Somewhere you'd find an "approved" IPv6 path-example for
the next USEPRO.

>> replace the bogus 2822 notation <id-right> by <id-domain>

> Here we disagree, as I have noted separately.

You probably want "my" semantics with the old 2822-syntax.
AFAIK this "my" is also "your" or the "true" semantics of
a msg-id.  I'd be very surprised if you say that the RHS
can be "anything" as long as it's syntactically correct.

                          Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 09:34:17 -0400

> In RFC 2822 an <id-right> is a string of characters satisfying some ABNF.

The grammar production named id-right is an ABNF rule name, yes.

> is "invisible").

No, the semantics are "the domain name (or a domain literal IP address)".

> If you generate such an <id-right> by "putting" a <domain> 

References to specific RFC 2822 text supporting your claims, please.
 
> octet-by-octet comparison will always suffice.

Kindly refrain from ad-hominem attacks.  There is no "bizarre
interpretation", a msg-id has had a domain name or domain literal
on the RHS since RFC 822 (prior to which the RHS was a host name,
as that was before DNS).  RFC 2822 has not changed the semantics,
contrary to your unsupported assertion (RFC 2822 Appendix B contains
a list of changes, and semantics of msg-id is not among them).  2822
dis change a very specific part of the syntax, which as noted is
"identical except" for those specific syntax changes.

> Yes, it has changed (whether intended so or not).

Repeating an unsupported assertion does not add to the discussion.  If
you cannot support your assertion, please retract it so we can move on.

> technical reasons that have been explained so many times that I will not

IOW, more unsupported assertions, not even repeated in this case.
 
> requirement of Netnews that an octet-by-octet comparison of <msg-id>s

Kindly support your assertions.
 
> No, Mark made his suggestion (in the NNTP list, I believe)

Mark's suggestion was made here, and is archived in this WG's mailing list
archive at
http://www.imc.org/ietf-usefor/2003/Feb/0493.html

> in the belief 
> implementations.

That is a false assertion; Mark specifically referred to a transport
protocol constraint, as his text clearly shows.

> He was rapidly disabused of that notion. 

References, please.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Jun 2005 15:59:19 +0200

Assigned ticket #1047 to this issue.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 10:17:03 -0400

> Indeed, there are lots of stupid domain literals that should not be used

Precisely what is the purpose of the word "stupid" in your remarks?

[colon in path components (currently (1036) a delimiter)]
> string of characters like any other <path-identity>.

If, and only if, there is an explicit statement that the components are
names, not IP address literals.  As noted elsewhere, the -04 USEFOR
draft text seems to be acceptable, but might benefit from clarification.
If treated as address literals, there are several severe performance
penalties...

> routine basis

An IP address literal (any version) in path would have to be treated
specially for the widely-implemented purpose of determining if an
article should be propagated to neighbors. 123.45.67.89 and 123.045.67.89
are different bits of text, but equivalent IP address literals.  IPv6
is much more complex as there are literally dozens of ways to represent
a given IPv6 literal.  A neighbor might not be known by IP address but
by name, so treatment if IP address literals would involve a DNS lookup
in in-addr.arpa.

> that used some rather unusual <path-identity>s.

No. Frank is on recent record as being opposed to IP addresses in path.
You seem to have agreed "Absolutely" to treatment of path components "purely
as public names, not as IP address literals".  Russ is also on record as
being opposed to IP addresses.   Now where is this supposed "benefit"?

> If the sites "dead" and 
> "beef" find that some idiot has invented a site "dead:beef",

What purpose is served by use of the derogatory term "idiot"?

> and if they 
> then they will have to deal with it as best they can.

Sigh.  No Charles, as has been explained to you twice before, the issue is
neither "only affects that site" nor "receiving too many articles twice
over", it is that if some combination of characters (hexadecimal digits)
appears next to a colon in Path, the sequence of characters (excluding the
colon delimiter) is interpreted as a host name, and an upstream neighbor
of a site with such a host name will not receive such articles *at all*,
nor will sites downstream of the named host who are dependent of that host
for a feed of the affected newsgroups and/or distributions.  I.e. it breaks
the flooding algorithm by changing the meaning of a long-standing delimiter.
It breaks backwards compatibility.
 
> It is already 

Does your continued use of offensive language serve any purpose?
 
> rather improbable minor inconvenience? Please come and join us in the Real

Please support your "much-needed" assertion.

Your "minor inconvenience" claim is a false assertion, as has been explained
to you in detail at least twice before, and now again.

Your "join us in the real world for a change" snide remark is highly
offensive and totally uncalled for.
 
> Again, there is a limit as to how far one should go to deal with idiotic

Is that supposed to be a substantive comment of some sort?  If so I
fail to see the substance.   It sounds like yet another uncalled for
insult.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 23 Jun 2005 07:30:08 -0700

Bruce Lilly <[email-masked]> writes:

> article should be propagated to neighbors. 123.45.67.89 and
> 123.045.67.89 are different bits of text, but equivalent IP address
> literals.

That depends on your implementation of address conversion.  Most Unix
systems will treat 123.045.67.89 as equivalent to 123.37.67.89.  :)
(Which just goes to illustrate your point.)

> IPv6 is much more complex as there are literally dozens of ways to
> represent a given IPv6 literal.  A neighbor might not be known by IP
> address but by name, so treatment if IP address literals would involve a
> DNS lookup in in-addr.arpa.

You have to treat Path identities as opaque labels; anything else gets
into way too much work to specify and implement, IMO.

> You seem to have agreed "Absolutely" to treatment of path components
> "purely as public names, not as IP address literals".  Russ is also on
> record as being opposed to IP addresses.  Now where is this supposed
> "benefit"?

I'm not sure that I've really gone on the record being *opposed* to them;
I just think they're a bad idea (which isn't quite the same thing as
saying that they shouldn't be allowed).  IP addresses are used somewhat
currently.

There's something to be said for supporting IPv4 for legacy reasons but
telling people using IPv6 that, sorry, they have to come up with a regular
name.

>> rather improbable minor inconvenience? Please come and join us in the
>> Real World for a change.

> Please support your "much-needed" assertion.

Yeah, I'd like to see some support for that too.  I'm not seeing a clamor
from IPv6 sites wanting to put address literals into the Path header.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jun 2005 10:46:42 -0400 (EDT)

On Thu, 23 Jun 2005, Russ Allbery wrote:
> > ...123.45.67.89 and

No, they are unquestionably equivalent -- this notation for IP addresses
is known as "dotted decimal" (see, e.g., RFC 1123), not "dotted decimal,
octal, or hex".  RFC 1166, in particular, explicitly states that
128.009.000.032 and 128.9.0.32 are equivalent.  (I had cause to do some
research on this some years ago on another project.)

The Unix implementation's interpretation of leading zeros is simply wrong.

> into way too much work to specify and implement, IMO.

Now this, I concur on.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 11:26:24 -0400

> (Which just goes to illustrate your point.)

Actually, my point was that *IF* one allows treatment of path components
as IP address literals, *THEN* a simple textual comparison is insufficient
*AND THEREFORE* there will be a performance penalty.  I don't know of any
Unix (or other) systems that would treat "123.45.67.89" and "123.045.67.89"
as equivalent as text.

> into way too much work to specify and implement, IMO.

It appears that we're agreed that treatment as IP address literals is
"way too much work".  We might differ regarding "opaque labels" vs.
"public names".
 
> saying that they shouldn't be allowed).  IP addresses are used somewhat

*As* IP address literals (with eliding leading zeroes, reverse lookup to
check against known names, etc.)?  Or as textual labels?

Reference:
 "What are you talking about?  I've been opposed to using IP addresses in
 the Path except for entries that fail validation since the beginning, and
 I've never been worried about long Path headers."
from message <[email-masked]> posted to this WG's
mailing list and dated 27 Jun 1999 04:05:54 -0700.

Unfortunately the online WG mailing list archive is incomplete.

Apologies if I have unintentionally misinterpreted your position, Russ.

> telling people using IPv6 that, sorry, they have to come up with a regular

I suspect that would run afoul of IETF provisions requiring equal support
for IP versions.  If supporting IPv6 address literals is a problem,
supporting IPv4 address literals (as address literals) is a problem.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 11:59:54 -0400

On Thu June 23 2005 10:17, Bruce Lilly wrote:

> for a feed of the affected newsgroups and/or distributions.

Correction:  the upstream neighbor won't send, and the named site (and its
downstream dependents) won't receive the articles.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 23 Jun 2005 09:09:04 -0700

> as IP address literals, *THEN* a simple textual comparison is
> insufficient *AND THEREFORE* there will be a performance penalty.  I
> don't know of any Unix (or other) systems that would treat
> "123.45.67.89" and "123.045.67.89" as equivalent as text.

I agree with this.

>> I'm not sure that I've really gone on the record being *opposed* to
>> them; I just think they're a bad idea (which isn't quite the same thing
>> as saying that they shouldn't be allowed).  IP addresses are used
>> somewhat currently.

> check against known names, etc.)?  Or as textual labels?

As textual labels.

> Apologies if I have unintentionally misinterpreted your position, Russ.

You haven't, really; there are just various definitions of "opposed"
happening.  I don't think IP addresses belong in the Path header; IP
addresses are, among other things, too transitory and too difficult to
trace compared to good textual names.  *However*, there are some
situations where using the IP address as a Path identity might be a
reasonable choice, or there might be some reason why one really wants an
IP address not as a Path identity for optimization but rather for trace
information (such as, as mentioned, including additional trace information
for Path mismatches -- IPv6 *is* a problem for that, actually).

Although, that being said, it's worth noting that nearly all of my
opinions on how best to write these documents have changed since 1999; I
was naive and far too optimistic about some things six years ago, and in
many cases have changed my opinion completely.

> I suspect that would run afoul of IETF provisions requiring equal
> support for IP versions.  If supporting IPv6 address literals is a
> problem, supporting IPv4 address literals (as address literals) is a
> problem.

Provisions for legacy support may well be exempt from those sorts of
rules, if that's the only reason why IP addresses are supported.  (But
that might require some other solution to the tracing problem.)

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Jun 2005 18:44:53 +0200

Bruce Lilly wrote:

> <[email-masked]> posted to this WG's

> Unfortunately the online WG mailing list archive is

Try <http://mid.gmane.org/[email-masked]>
for old articles.  In the resulting URL ..../number add /raw if
you need the original header.  Or for ...:number add :raw.  Or
use your news reader:

<news://news.gmane.org/[email-masked]>

>> There's something to be said for supporting IPv4 for legacy
>> reasons but telling people using IPv6 that, sorry, they have
>> to come up with a regular name.
 
> I suspect that would run afoul of IETF provisions requiring
> equal support for IP versions.

It's also an odd idea, some problems for IPv4 like dynamic IPs
or private IPs behind NAT should not exist for most IPv6 IPs.

> If supporting IPv6 address literals is a problem, supporting
> IPv4 address literals (as address literals) is a problem.

Sorry, I don't get this, yes, there are problems, that's why I
want the STD 11 "STRONGLY DISCOURAGED".  For the fun effect of
screaming in a stadard maybe literally.

But the problems for IPv4 and IPv6 are completely different.

BTW, the old "is a leading zero octal" question made it into an
I-D (or even RfC), and STD 66 offers a nice unambiguous syntax.

For a laugh see the "octal"-part in:
<http://mid.gmane.org/[email-masked]>

                    Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 13:32:21 -0400

> or private IPs behind NAT should not exist for most IPv6 IPs.

Off-topic: some people aren't convinced that IPv6 means the end of
NAT.
 
> screaming in a stadard maybe literally.

The problem is that if we try to say something resembling "IPv4
is supported, IPv6 is not"  it is virtually guaranteed that during
IETF Last Call and/or IESG review somebody will point out the
requirement for treating IPv6 the same as IPv4 and will go to the
trouble of looking up the exact reference.  It is likely to be a
contentious issue.

I've suggested avoiding the problem(s) (performance as well as the
IPv6 issue) by explicitly treating the path identities as not IP
addresses.  And I've seen some support for that (we can debate
"public name" vs. "opaque string" etc. if and when we reach consensus
on "not IP address literals").

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Jun 2005 20:43:55 +0200

Bruce Lilly wrote:

[I've reset the subject because we're back to the old topic]

> The problem is that if we try to say something resembling
> "IPv4 is supported, IPv6 is not"

Oh, yes, that won't fly.  It's much worse than omitting an
empty IANA considerations, claiming that CRAM-MD5 is secure,
and getting the IPR boilerplate wrong put together.

> I've suggested avoiding the problem(s) (performance as well
> as the IPv6 issue) by explicitly treating the path identities
> as not IP addresses.

There are _many_ <path-identity> in usefor-04, usepro-03, and
already "approved" modifications of these texts.  Changing its
semantics now is a dubious idea.

But that's also not necessary for your idea, we can get this
effect by saying that a <path-identity> is compared octet by
octet (BTW, same idea as for a msg-id), and so it should be
always created in the same way.

It's IMO unnecessary to invent any "canonical representation"
for this simple purpose.  Add a general rule discouraging
domain literals, because that's the only case where it gets
really tricky, and it should be good enough.

The added colon for IPv6 has to be mentioned in a "differences
from 1036" section.  That's no showstopper, we have these IPv6
domain literals everywhere in the syntax.

And at the moment "dead", "beef", "cafe", "affe", etc. are no
FQDNs.  If some poor old UUCP host in the last world map 1999
had one of these names it's tough but we can't change it.  We
could document it if you think that it's a real problem today,
not only with some scripts trying to analyze historical paths.

Inventing our own IPv6 path-id convention based on s/:/_/ is
too horrible to consider it.  A "MUST NOT domain literal" in
the path might be worse, I still like "STRONGLY DISCOURAGED".

                         Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 17:08:02 -0400

> semantics now is a dubious idea.

Let's stick to USEFOR for the moment.

> always created in the same way.

That's neither necessary nor sufficient for the purposes the Path
field has.  The purposes listed in -04 3.1.6 impose first and
foremost a uniqueness requirement.  That in turn requires either
a hierarchical system (like DNS) or a central authority (like the
UUCP mapping project was supposed to be, though it never worked
well).  As mentioned about a year ago, I'd be happy to have the
draft say "MUST be a fully-qualified domain name" [*], thereby avoiding
the problems with IP address literals and UUCP node names, and
satisfying the uniqueness requirement.  As a nice side-effect,
it precludes conflict with the newfangled "POSTED" and "MISMATCH"
keywords (as those aren't FQDNs).

> really tricky, and it should be good enough.

Merely "discouraging" or even "STRONGLY DISCOURAGED" 127.0.0.1
won't satisfy the uniqueness requirement.

> from 1036" section.

Not if the difference (and associated backward compatibility
issues) are removed.

> FQDNs.

Neither is "sn-us", but that doesn't prevent its use.

> If some poor old UUCP host in the last world map 1999 

All things considered, I think requiring FQDN (for conforming
implementations) is the best approach.
 
> too horrible to consider it.

It might not be so bad it the use were restricted to literals used
to document validation failures.  Indeed, since underscore is not
valid in DNS labels, it would avoid confusion between such literals
and FQDNs.  As IPv4 addresses can be mapped to IPv6 (RFC 3513 sect.
2.5.5), that can also be used for IPv4 literals for documenting
validation failures, e.g. 129.144.52.38 -> ::FFFF:129.144.52.38 ->
__FFFF_129.144.52.38 which is no FQDN.

---------
* probably with an implementation note indicating that unqualified
names may exist, that there is no established mechanism to avoid
clashes, etc.

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Fri, 24 Jun 2005 12:51:20 +0200

Henry Spencer:
> Russ Allbery:

>> Most Unix
> No

Yes. Try 'ping' for just one example of such treatment.

-- 
Grtz, Ruud

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Fri, 24 Jun 2005 13:24:58 +0200

Frank Ellermann:
> Bruce Lilly:

> <news://news.gmane.org/[email-masked]>

And for the whole enchilada: 
  news://news.gmane.org/gmane.ietf.usenet.format
(23000+ messages)

-- 
Grtz, Ruud

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 15:11:15 GMT

>Unfortunately the online WG mailing list archive is incomplete.

It's all there in mbox format, if you are desperate.

I eventually got around to updating my Perl script to grab them from the
Landfield site, and even managed to download a couple of months' worth.

But next day I found the site down, and I have not been able to catch it
up since. But I shall keep trying.

And I was going to put the USEFOR-04 draft up at the same time, which is
why that has never happened as of yet.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 15:31:03 GMT

>foremost a uniqueness requirement.

It doesn't explicitly say so, but it is evident that it is necessary.

>  That in turn requires either
>well).

But that does not follow at all. Usenet has been working quite happily for
many years now just by admins using their common sense when choosing
<path-identity>s. I am not aware of serious clashes that have occurred,
and if they have then they have been sorted out amicably (because it is in
everybody's interest to do so). It ain't broke, so it doesn't need fixing.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 15:04:51 GMT

>into way too much work to specify and implement, IMO.

Absolutely so.

But for human readers, it is useful to be able to regard them as
domain-names and/or IP addresses (as the case may be) and to look them up
in the DNS or in whois databases in order to determine the (alleged) route
an article took.

Also, in order to detect MISMATCHes, you will likely need to know whether
the IP address the NNTP packet came from agrees with what the
<path-identity> in the header says. But that does not mean you start doing
DNS lookups and the like for every article. You construct a database of the
IP addresses your peers normally use and the <path-identity>s they
normally use with them. For sure, you may have submitted domain-names and
IP addresses as seen in Path headers to various bits of DNS-related
software for the purpose of constructing your database, but that is an
offline operation so far as your main server software is concerned.

And if your peer insists on using different forms of the same IP address
in different articles, then you should seriously consider depeering him
:-) .

>saying that they shouldn't be allowed).  IP addresses are used somewhat

The text which en/dis-courages various forms of <path-identity> is
currently in USEPRO rather than USEFOR (because that's where Alexey asked
me to put it); I posted it here a while back.

Currently, it puts IP addresses (whether IPv4 or IPv6) as the least
desirable alternative, which seems to agree with opinions expressed here.
But they _do_ happen, and I see no reason to ban them altogether.

>....  I'm not seeing a clamor

I think that is because usage of IPv6 is still much less than of IPv4. But
clearly it is going to take off one of these days, probably in the Pacific
region first, because that is where the supply of IPv4 addresses seems to
be running out. And then you will start to see them in <path-identity>s;
but probably not for a couple of years or so.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 15:55:48 GMT

>No, the semantics are "the domain name (or a domain literal IP address)".

I do not see where RFC 2822 says that.

It is essentially the same as we have just been agreeing for the Path
header. All of <path-identity>, <id-left> and <id-right> are "opaque
labels", whether you initially construct them out of domain-names or
domain literals, or whatever else.

>protocol constraint, as his text clearly shows.

Mark may well have said that on this list when he was a member of it. But
he most certainly raised essentially the same point on the NNTP list
within the last few months (as you may check from their website), and he
signally failed to convince that WG.

---

From: Henry Spencer <[email-masked]>
Date: Fri, 24 Jun 2005 12:23:55 -0400 (EDT)

> Yes. Try 'ping' for just one example of such treatment.

If you read what I actually wrote -- which was more than "No" -- you'll
see that you've misunderstood.  I didn't say "Unix doesn't do that"; I
said "Unix does that but shouldn't".

                                                          Henry Spencer
                                                       [email-masked]

---

From: Richard Clayton <[email-masked]>
Date: Fri, 24 Jun 2005 18:21:10 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>Usenet has been working quite happily for

It would also be unwise to put any existing servers in a position that
they found themselves feeling that to conform to modern standards they
should change their identity...

Demon Internet (the first UK dialup ISP in the early 1990s) has used
!demon! since before it was called Demon Internet or even before it sent
news over NNTP. When an error was made with a new peering machine and
this tag was omitted a number of customers (with simple single-user
"leaf" systems who only swapped articles with Demon) started fetching
articles and (trying to) re-inject them all. Because servers elsewhere
in the cluster, generally, already had a copy of the article this went
on unnoticed for weeks until occasionally the customer presented the
article earlier than the peering machine.... and when the article was
spam it tripped detectors and we found the problem.

What I'm trying to illustrate is that path identities are not only
important to the few thousand machines that peer news on a high volume
basis, but these identities are nailed into hundred of thousands of end
user systems. We outlaw (or deprecate) existing path identities, whether
dating from UUCP or more recent conventions, at our peril.

and to echo Charles, what was it that was broken ?

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 16:44:09 GMT

>> Specific change to USEFOR -04 text: remove colon from path-identity

I oppose this. It has been raised on the WG several times over the years,
and it has always been concluded that IPv6 addresses were going to arise
sooner or later and therefore should be accomodated (though possibly
discouraged as the proposed USEPRO text already does).

Yes, there is a theoretical possibility of a backward incompatibility
(i.e. you can construct possible but extremely unlikely scenarios). Even
if a case did occur, it would only affect certain sites, and could easily
be resolved between the sites affected. The worst that could happen is
that a site might find that one of its peers was failing to supply certain
articles[1].

I have already proposed a wording (in reply to John) for inclusion in
USEFOR to advise care when choosing <path-identity>s.

[1] Suppose site A still regards ":" as a <path-delimiter>. It feeds site
B which has always chosen to call itself "beef". In the meantime,
post-new-standard, some new site C has chosen to call itself "dead:beef"
(not a wise choice, but I am not allowed to the the 'i' word :-) ).  Now,
A will fail to forward to B articles which have previously passed through
"dead:beef". Note that this is much less likely if use of ":" is confined
to IPv6 addresses. There is also a less disruptive scenario [2].

[2] Suppose A also feeds site C. It receives an article which has already
passed through C once, with the <path-identity> "dead:beef".  It will not
recognize that <path-identity>, and so it will pass it to C again (which is
wasteful but not harmful). (but you still may well ask how A came to
register C as a peer with the name "dead:beef", given that is not a
valid <path-identity> from the POV of A).

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 25 Jun 2005 05:34:47 +0200

Bruce Lilly wrote:

>> It has no semantics attached to it (except that a `\` in a
>> <quoted-pair> is "invisible").

[...]
> a msg-id has had a domain name or domain literal on the RHS
> since RFC 822 (prior to which the RHS was a host name, as
> that was before DNS).  RFC 2822 has not changed the semantics, 
> contrary to your unsupported assertion

Obviously there are strong disagreements about what a msg-id is
both semantically and syntactially:

Bruce + Frank + Sebastian + STD 11 + 1036 + s-o-1036:
  RHS is domain or domain-literal

Charles:
  RHS is what the fixed 2822 syntax allows for <id-right>

Charles + Frank + Alexey + 1036 + s-o-1036 + nntp-27:
  2822 msg-id syntax has to be fixed for News, NNTP, and URLs

Bruce:
  2822 msg-id syntax is good enough

So for these two details the rough consensus is IMHO clear.
Putting it together the consequence _should_ be also clear:

That won't fly with Bruce and Charles for different reasons,
Bruce wants the 2822 syntax, Charles wants his own semantics.

Both positions are showstoppers from my POV, i.e. I prefer to
dissolve this WG without any result instead of these positions.

                         Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 11:35:42 -0400

> in the DNS or in whois databases in order to determine the (alleged) route

We need to specify the semantics of a "path-identity" as one of:
o an opaque label
o a public name
o domain names, IP-addresses, etc.

It is unsatisfactory, because it is self-inconsistent, to give contradictory
semantics.

> the IP address the NNTP packet

NNTP is not the only transport mechanism.

> came from agrees with what the 
> <path-identity> in the header says.

Irrelevant to the discussion at hand, which is interpretation of the
"path-identity" *as* an IP address, not interpretation of an IP address
obtained from another source.

> but probably not for a couple of years or so.

Russ' complete statement was:

 > Please support your "much-needed" assertion.

You still have not provided any substantive support for your assertion;
"I think", "probably", "seems to be", etc. are hardly convincing, and
contain no objective data to support the "much needed" assertion.  Nor
does it provide any evidence to support "a clamor from IPv6 sites to put
address literals into the Path".  Would you care to retract your "much
needed" assertion and/or admit that there is no "clamor"?

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 11:44:06 -0400

> >  The purposes listed in -04 3.1.6 impose first and

OK; we're agreed that there is a uniqueness requirement. N.B. requirement
as in "necessary", not "wouldn't it be nice if...".
 
> everybody's interest to do so).

While you might not be aware of problems, they certainly exist. Although
the UUCP mapping project has good intentions and was intended to avoid
clashes, it failed to do so.  I happen to know for a fact (and have
previously mentioned here) that there have been unresolved duplicates;
one that I can recall off the top of my head even after a decade is
multiple sites claiming the name "wolf".  I am not aware that the duplicates
were ever resolved.  Do you have evidence to support your claim that "they
have been sorted out amicably"?

In the general case, would you care to explain in specification language
(as opposed to hand-waving) precisely how a uniqueness requirement can
be met in a distributed system without a hierarchical DNS-like system
or a central authority?

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 12:22:46 -0400

> I do not see where RFC 2822 says that.

It says so (in those words) in the part which I quoted from 2822 and which
you have snipped.  John Stanley seems to have identified some problem
related to editing (unless of course you were exaggerating about "an hour
or so" (N.B. there was a "smiley" notation indicating sadness, but none
indicating intended humor or exaggeration)); may I suggest the vi editor,
which John also recommended, and with which you can quickly and efficiently
locate the text by typing (each line ends with a carriage return):

  vi rfc2822.txt
  /domain name (o

You can exit vi by typing the two characters (no carriage return required)
  ZZ

Alternatively, you can find a web interface to RFCs via the RFC-Editor web
site (http://www.rfc-editor.org), and you can use your browser's text
search mechanism to find the text within the RFC 2822 document.

> header.

We seem not to be agreed.  There is some agreement on "not an IP address",
but you seem to want it both (incompatible) ways, "not an IP address" and
"an IP address".  We are not agreed on "opaque label" or "public name",
which has not been discussed much.  In any event, Path is not specified
in RFC 2822, and is irrelevant to discussion of msg-id and 2822.

> All of <path-identity>, <id-left> and <id-right> are "opaque 

Please cite RFC 2822 text supporting your "opaque labels" assertion.
Please also cite specific RFC 2822 text, as specifically requested
earlier, that supports your contention that the semantics of msg-id
has been changed.
 
> Mark may well have said that on this list when he was a member of it.

Charles, there is no "may" about it.  I have provided a reference to the
archived mailing list message as well as a quotation from that message
which clearly indicate:
1. the suggestion was made here
2. It was not "describing a temporary problem..."

> But 

If it was the same point, then it still was not "describing a temporary
problem".  And whether or not the issue was raised on the NNTP list, that
is irrelevant to the statement about what he said on *this* list, which
was quoted (several times, including multiple references) prior to your
assertions about what was said and where it was said.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 12:41:59 -0400

> discouraged as the proposed USEPRO text already does).

References to all of the discussions (you claimed "always") and
Chair-specified consensus, please.  [Frankly, your continued habit of
making unsupported assertions is very wasteful of limited WG
resources.  Please stop it.]

> Yes, there is a theoretical possibility of a backward incompatibility

There is nothing "theoretical" about it; you know this because it has
been discussed at length, with supporting documentation -- we know for
a fact that B news, C news, and INN treat colon as a delimiter, and
that reassignment will therefore unquestionably break backward
compatibility.  It is disingenuous of you, and frankly insulting to
others, for you to categorize this as "theoretical".

> USEFOR to advise care when choosing <path-identity>s.

That wording is inadequate.
 
> to IPv6 addresses. There is also a less disruptive scenario [2].

Sigh (again).  Charles, do you honestly fail to recognize, after it has
been pointed out and after Frank has also mentioned "cafe" etc., that
"dead" and "beef" are composed entirely of characters representing
hexadecimal digits (and moreover DEADBEEF is a well-known set of such
heaxadecimal digits) and therefore might well appear in an IPv6 address
literal?  Clearly "dead", "beef", and any of (16^^4 = 65536) - 2 other
4-character combinations of hexadecimal digits (not to mention 256
combinations of two hexadecimal digits) which may appear in IPv6 address
literals can conflict with unqualified (in the DNS sense) names.  Do you
really fail to realize that obvious fact, or are you intentionally wasting
WG time?  Really, I want to know if it's the former case so that I know
to explain things in minute detail.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 13:12:36 -0400

>   2822 msg-id syntax has to be fixed for News, NNTP, and URLs

The WG charter gives no authorization to modify RFC 2822.

Facts:
o CID and MID URIs (RFC 2392) seem to work fine.
o there are mechanisms other than syntax changes (e.g.
  implementation notes) to address specific issues.
o NNTP and URIs are handled by other groups.  Not our problem.

Wording: "fixed" implies that something is "broken", but no
convincing case has been made that 2822's definition is what
is broken.

[...]
> Bruce wants the 2822 syntax

I repeat: we have no authority to modify RFC 2822. This has nothing
to do with "wants"; it's a simple matter of proper IETF procedure.

---

From: Henry Spencer <[email-masked]>
Date: Sat, 25 Jun 2005 15:58:06 -0400 (EDT)

> The WG charter gives no authorization to modify RFC 2822.

Nobody is talking about modifying RFC 2822.  The extent to which 2822
syntax applies to news, and specifically what restrictions might have to
be imposed to make it work for news, is legitimately our decision.  An
arbitrary 2822-conforming message is *not* a valid news article, so there
*are* added restrictions; the only questions are what they are and how
they are best explained. 

Quite plausibly some of them are best explained by using text and/or ABNF
which is a rewritten version of parts of 2822 (although this needs to be
done with care to ensure that our version doesn't legalize something that
2822 outlaws). 

Please stop playing this broken record, Bruce. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 26 Jun 2005 18:47:19 +0200

> The WG charter gives no authorization to modify RFC 2822.

If you look at http://tools.ietf.org/wg/usefor/ you'd find
among others two expired drafts especially about the msg-id.

You'd also find a link to the WG Charter stating:

| A draft update to RFC 1036 ("Son of RFC 1036" ) was released
| by Henry Spencer in June 1994 but this was not further
| pursued and is now itself out of date. Currently a
| combination of this and RFC 1036 are regarded as the de-facto
| standard.
[...]
| The Group shall also aid and/or oversee the production of
| other Usenet related Internet Drafts and Standards.

That covers NNTP and the two news-nntp-uri drafts.  If the WG
failed to fix the msg-id error in [MESSFOR] it's sad, but at
least it's not forced to repeat this error.

> o CID and MID URIs (RFC 2392) seem to work fine.

That's essentially a percent-encoded RfC 822 <addr-spec>, and
we already know that we don't want WSP, NO-WS-CTL, or comments
in a <msg-id>.  Not one of the RfC 2392 examples discusses or
uses such constructs, it's about %25 for % etc. in URLs based
on RfC 1738.

>   implementation notes) to address specific issues.

If we don't get the <msg-id> or <newsgroup-name> syntax right
this WG should be dissolved.  Intentionally hiding this syntax
problem in prose is cowardly and no option.  

The IESG is already at its lowest point of unprofessional and
unethical behaviour after approving technically incompatible
"mail experiments".  That's no excuse for you and me to follow
their "worst common practice".

For an example how this problem should be _not_ solved see e.g.
<http://article.gmane.org/gmane.org.w3c.uri/569/match=dtext> :

| A word about non-whitespace controls, since there seems to
| be some confusion: aside from appearance in qtext and ctext,
| they also appear in the 2822 grammar for dtext.  The reason
| for that as I understand it (private correspondence with
| Pete Resnick) is that at the time, IDN had not been fleshed
| out, and the provision is to accommodate possible schemes.
| Of course at the present time, a domain name, including IDN,
| consists solely of letters, digits, and hyphens plus
| separating dots.  So while the syntax has provision for
| NO-WS-CTLS in dtext, those won't actually occur because of
| restrictions in other specifications (notably RFCs 1034, 1035).

Your communication with the [MESSFOR] author is not good enough
for a future <id-domain>.  And this dtext problem hits also the
<General-address-literal> in RfC 2821.  It is _our_ job, if we
don't get the <msg-id> right this WG has absolutely no business
to mess with NetNews at all.

> o NNTP and URIs are handled by other groups.

See the WG Charter quoted above.  State of the art in nntp -27:

| A message-id MUST begin with "<" and end with ">", and MUST
| NOT contain the latter except at the end.
| A message-id MUST be between 3 and 250 octets in length.
| A message-id MUST NOT contain octets other than printable
| US-ASCII characters.
[...]
|      message-id = "<" 1*248A-NOTGT ">"
[...]
|      A-NOTGT    = %x21-3D / %x3F-7E  ; exclude ">"

For the purposes of NNTP the <id-local> "@" <id-domain> details
are irrelevant, as long as the combination is unique, worldwide
and forever.  For other purposes like news-URLs, or designing a
msg-id generator based on proper name spaces, the structure is
important.

> Not our problem.

Read the Charter.  Of course it's our problem, it affects also
<unique>@<full_domain_name> in RfC 1738, or rather its syntax:

article = 1*[ uchar | ";"| "/" | "?" | ":" | "&" | "=" ] "@" host

The two proposed news-nntp-uri-00 successors use either:

    message-id      = printable-ascii "@" printable-ascii
    printable-ascii = 1*( %d33-61 / %d63-126 ) ; excludes ">"
or:
    message-id = unique "@" host               ; see RFC 1036
    unique     = 1*( %d33-61 / %d63-126 )      ; excludes ">"

Some details still TBD, at the moment <unique> is plain wrong,
because it has to be percent-encoded in an URL.

> Wording: "fixed" implies that something is "broken"

Yes, and the least common denominators are printable (syntax)
and a domain allowing for a domain-literal as RHS (semantics).

                          Bye, Frank

---

From: [email-masked] (Kai Henningsen)
Date: 26 Jun 2005 14:15:00 +0200

> more interested in a visual similarity to RfC 2822 <id-right>.

If we insist on at least as much different semantics from a domain in an  
address as 2822 (it's not clear to me what 2822 implies about this), then  
we certainly shouldn't be any closer to the notation of a domain in an  
address.

I'm for id-right.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 26 Jun 2005 14:47:00 +0200

[email-masked] (Frank Ellermann)  wrote on 21.06.05 in <[email-masked]>:

> identifier forever.

I'm seriously fed up by this completely unfounded assertion that seems to  
be impossible to kill no matter how false.

In fact, the idea goes back at least to RFC 624 (obsoleted by 733, which  
was obsoleted by 822, which is obsoleted by 2822), 1977-05-12.

All we're debating are implementation techniques and problems, not the  
fundamental concept.

MfG Kai

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 27 Jun 2005 09:13:08 -0400

> That covers NNTP and the two news-nntp-uri drafts.

That's covered by a separate WG.

Note also that the charter hasn't been substantively updated in
years, even after a specific call to recharter (which resulted
in the addition of a note at the top claiming that "a charter
rewrite/update is underway" and some milestones (including
Apr 05 recharter or conclude) at the bottom.

The (now past) WG co-chairs clearly indicated our direction:
http://www.imc.org/ietf-usefor/2003/Mar/0305.html
with our work products to deal only with articles that conform
to 2822 and MIME syntax.  N.B. not to *redefine* 2822 or MIME
syntax. 

> uses such constructs, it's about %25 for % etc. in URLs based

1. 2822 obsoletes 822 and forbids CFWS.  So far nobody has made a
   convincing case about no-WS-CTLs; we know that you don't like
   them, but you haven't given a technical argument against their
   use.
2. There is a separate effort to update URIs.  Not our job, and
   we don't have the time or temperament to rewrite 2822, MIME,
   and RFC 2392; we way behind schedule on getting the first of
   two Standards Track documents done.

> If we don't get the <msg-id> [...] syntax right

1. You have yet (see above) to indicate a specific technical problem.
2. msg-id (and date-time and zone) are defined in RFC 2822 and are
   used in a number of standardized fields (Message-ID, References,
   In-Reply-To, and Superseded for msg-id, Date, Received, Resent-Date
   for date-time and zone).  Conflicting syntax definitions are
   unsatisfactory:
   a. They are a problem for implementers of combined mail/news UAs
   b. They are a problem for implementers of Standards Track protocols
      that handle messages of all sorts (e.g. IMAP)
   c. Conflicting syntax of field components (msg-id, date-time, zone)
      affect fields which this WG has no authority over (i.e. those
      mentioned above
   d. It affects other applications based on the Internet Message
      Format (voice mail, fax, EDI, etc.)
   e. It affects other Standards Track protocols based on the field
      components defined in [2]822 (e.g. MIME Content-ID, HTTP, SIP). 

We can, without causing conflict and remaining within the bounds
established in "the plan of action" provide suitable implementation
notes adding specific restrictions based on technical issues as suggested
in detail by Mark Crispin.  We are also free to define whatever separate
syntax we desire for news-specific fields such as Injection-Date.

> for a future <id-domain>.

Can you accurately predict what future versions of IP address
literals will look like?  Heck, there isn't agreement for
IPv6 (RFC 2821 "IPv6:" tag, for example).

> And this dtext problem hits also the 

You are free to suggest addition of a (redundant) note pointing
out that at this time IPv4 address literals are limited to dotted
decimal quads as specified in STD 3.  You can add, if you wish,
that there is no single agreed-upon way to represent IPv6 address
literals.
  
> See the WG Charter quoted above.  State of the art in nntp -27:

This WG doesn't have a "nntp -27".
 
[...]
> and a domain allowing for a domain-literal as RHS (semantics).

RFC 2822 msg-id permits all of that.  If you have a specific case
of a standards-compliant external protocol issue that adds some
restriction, please specify it along the lines suggested by Mark
Crispin.  We can't rewrite 2822.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Jun 2005 20:32:36 +0200

Bruce Lilly wrote:

>> | The Group shall also aid and/or oversee the production
>> | of other Usenet related Internet Drafts and Standards.

> That's covered by a separate WG.

In fact NNTP -27 was approved, 1*248 VCHAR excl. ">" within
angle brackets is settled.

> http://www.imc.org/ietf-usefor/2003/Mar/0305.html

That article says that USEFOR produces its fourth and final
I18N RFC in November 2003.

> with our work products to deal only with articles that
> conform to 2822 and MIME syntax.

Sure, "<" <id-local> "@" <id-domain> ">" or Charles' version
are a proper subset of what 2822 / MIME / NNTP say.

> N.B. not to *redefine* 2822 or MIME syntax.

Now what's that, avoiding <id-left> "@" <id-right> is not
good enough, do you maybe want a new term for a <msg-id> ?
How about the good old term <message-id> as in s-o-1036 ?

> So far nobody has made a convincing case about no-WS-CTLs;
> we know that you don't like them, but you haven't given a
> technical argument against their use.

You probably missed one or two of the several hundreds (?)
of articles in the various "msg-id" threads.  That point
is moot, the proposed standard NNTP -27 has VCHAR excl. ">",
and it's not exactly a new concept (1036, 1738, etc.).

> There is a separate effort to update URIs.  Not our job

Obviously Charles and I volunteered after Paul said that he's
not more interested.  And so it's "our" job to educate these
volunteers about our ideas for a <message-id>, it there are
any differences from 1036 / 1738 (hint: yes).

> we don't have the time or temperament to rewrite 2822

True, but updating only its <msg-id> syntax is an option after
this WG is closed.

> MIME,

Except from a clear "don't mess with the boundary parameter"
plus some more elaborated security considerations I don't
see what you'd want to update there - okay, fix the errata,
use ABNF while you're at it, and avoid any prose in syntax.

> You have yet (see above) to indicate a specific technical
> problem.

"Does not work with NNTP" is good enough.  But just for fun
here's another obvious reason found in RfC 2046, please read
also the surrounding text:

| Aside from these conventions, any use of the control
| characters or DEL in a body must either occur
|
| (1)   because a subtype of text other than "plain"
|       specifically assigns some additional meaning, or
[... (private convention) ...]

Many NetNews articles are text/plain US ASCII and routinely
mention some <message-id>s in the body.  That won't work for
NO-WS-CTL (excl. the conventional HT and FF), it's illegal.

Deja-vu, IIRC we already discussed this.

> Can you accurately predict what future versions of IP
> address literals will look like?

Yes, it will be a subset of the STD 66 <IPvFuture> syntax.

> there isn't agreement for IPv6 (RFC 2821 "IPv6:" tag, for
> example).

Sorry, I fail to see any NO-WS-CTL in the string "IPv6:", and
otherwise it's the same as in STD 66 <IPv6address>.  Another
deja-vu, at least Charles and I looked into all these details.

Until Alexey said that we better don't try to define all the
details of <id-literal> or <no-fold-literal> resp., just the
set of allowed characters adding \\, \[, and \] just in case.

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Jun 2005 21:42:21 +0200

Kai Henningsen wrote:

> the idea goes back at least to RFC 624 (obsoleted by 733,

Okay, 733 says 724, let's see:

| The uniqueness of the message identifier is guaranteed by
| each host.

And that <host-name> is the part of an <host-indicator>,
which is either "at" or "@" followed by the name, an <atom>
or a <decimal-host-address>.

> we're debating are implementation techniques and problems,
> not the fundamental concept.

I'm not convinced that that's the case, Charles repeatedly
said that it's no domain (i.e. <host-name> in this old RFC).

> I'm for id-right.

And that doesn't reflect the fundamental concept <host-name>.

<id-right> could be "maybe take some random number + hash +
timestamp, don't forget to add an '@' somewhere in the middle".

                           Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 27 Jun 2005 15:52:16 -0400

> angle brackets is settled.

Somebody recently said "The IESG is already at its lowest point
of unprofessional and unethical behaviour after approving
technically incompatible [...]"...

> I18N RFC in November 2003.

That was the suggested ("here's what we suggest as a schedule")
for the timeline.
 
> are a proper subset of what 2822 / MIME / NNTP say.

Fine, Use msg-id as defined in 2822 and add a note saying what
other protocol imposes limitations, what those limitations are,
etc. as suggested by Mark.

> good enough,

Not "not good enough", a redefinition is harmful (as detailed
earlier).

> do you maybe want a new term for a <msg-id> ? 

Where would you use it?  Message-ID and References fields are defined
in RFC 2822, Likewise for Received and In-Reply-To.  Supersedes is
defined in RFC 2156.  Content-ID is defined in RFC 2045.  Don't mess
with those definitions -- add restrictions if there's good reason.
 
> True, but updating only its <msg-id> syntax is an option after

Meanwhile we should use the definition as it is, not as one or
two people would like to see it.
 
> use ABNF while you're at it, and avoid any prose in syntax.

*I* don;t want to change it -- you apparently want to screw up
the definition of the Content-ID field.
 
> "Does not work with NNTP" is good enough.

What is the specific issue with RFC 977 (NNTP)?

> But just for fun 

That's for the charset parameter of a text media type and pertains
to the text media body content.  We're discussing header field
components.
 
> mention some <message-id>s in the body.

If it hurts, don't do it.  I have no objection to a note (presumably
in USEAGE) pointing out the problem (note that body text can be
encoded using e.g. quoted-printable).  But that would amount to
fretting about nothing (see below).

> That won't work for 

See quoted-printable.  All of which is academic because while "dtext"
syntax allows such things to accommodate future formats, STD 3 and
the various IPv6 schemes don't, so it won't happen until and unless
some future scheme provides explicitly for it.
 
> Yes, it will be a subset of the STD 66 <IPvFuture> syntax.

That's one opinion; RFC 3986 pertains to URIs, which is irrelevant
to message format header field content except where that content
specifically specifies a URI (which is not the case under discussion).
It's also hard to take seriously a document that has changed the
definition of "reserved" characters as drastically and frequently
as the URI specification has.

> otherwise it's the same as in STD 66 <IPv6address>.

The "IPv6:" tag is a crucial difference.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 27 Jun 2005 13:02:33 -0700

> technically incompatible [...]"...

The NNTP draft defines the minimum syntactic restrictions on message ID
required to work with NNTP software and explicitly states that additional
syntactic restrictions will be imposed by the relevant article standard.
It is compatible with our proposed message ID definition in that it
doesn't add additional restrictions.  It is not fully compatible with the
RFC 2822 message ID syntax for the reasons previously stated here
(primarily whitespace and multiple representations for the same message
ID), since making it so (even apart from whether that would be a good
idea) would have been significantly incompatible with existing NNTP
practice and hence outside our WG charter.

Please note that NNTP is not used exclusively with Usenet messages, and
was not written limiting itself to Usenet messages.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Jun 2005 23:50:26 +0200

Bruce Lilly wrote:

 [IESG process failure, quoting me:]
> after approving technically incompatible [...]

Maybe in the very same telechat (minutes not yet available).

But I wasn't talking about NNTP -27.  It was about abusing
v=spf1 sender policies for the incompatible "PRA" causing
bogus FAIL as well as bogus PASS results for received mail,
"unprofessional and unethical".  NOT RECOMMENDED and SHOULD
simultaneously.  Broken by design instead of engineering.

> Use msg-id as defined in 2822

No, it's broken, it's too broad for all protocols where it's
used, we need an interoperable subset.  And the maximal set
of syntactically well-formed <message-id>s is already clear.

                      Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 19:39:22 GMT

>others, for you to categorize this as "theoretical".

On the contrary, I stand by every word that I said. It is highly
improbable that any currenly existing <path-identity> will run into any
problem when ":" ceases to be a path-delimiter. And even if it does it
will be of limited impact, and will easily be fixed. Hence "theoretical
possibility" was an appropriate way to describe it.

>That wording is inadequate.

Then you are welcome to propose alternative wordings.

>literal?

And how many sites do you suppose there exist on Usenet which consist of
exactly four Hex Digits?

Perhaps somebody with access to a large server and some spare machine
cycles to burn would care to do a grep for us.

OK, you want a NOTE warning would-be generators of identities to avoid all
hex-digit-only names?

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 19:01:47 GMT

>  msg-id = "<" id-local "@" id-domain ">"

Simply changing the name of some syntax rule cannot possibly change the
meaning of the document.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 16:33:05 GMT

>o domain names, IP-addresses, etc.

No we don't.

1. I am not clear what is the distinction between "opaque label" and
"public name", or whether it matters for our purpose.

2. <path-identity>s are used for various purposes. They are used by
relayers to prevent articles being sent where they have already been sent.
Performance issues require that, for such use, regarding them as "opaque
labels" (enabling them to be compared octet by octet) is essential. Our
drafts must impose no requirements that would prevent that opaque
interpretation. They do not currently impose any such.

3. <path-identity>s are also useful for humans, who may well use the fact
that they are domain-names or IP-addresses for a variety of purposes
(including generating email to "[email-masked]"). They may even be
interpreted as such by software outside of the critical code within
relayers, if implementors find that useful (for example, when constructing
lists of identities used by their various peers).

>It is unsatisfactory, because it is self-inconsistent, to give contradictory

I see nothing contradictory in treating a <path-identity> as opaque for
some purposes, but not for others. I also see nothing unsatisfactory about
it either, particularly as that is the way is has been for the last 20
years or more.

>NNTP is not the only transport mechanism.

So? It is widely used, and current implementations regularly take note of
the source IP of incoming packets for a variety of purposes. It is
expected that those purposes will, in future, include detection of
MISMATCHes (indeed, some servers even do so currently).

>obtained from another source.

The expectation is that those two will be the same, and newsadmins should
not be accepting differences without knowing why (there are, of course,
lots of valid reasons why it might be so, and also lots of reason why it
might indicate malpractice).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 18:59:24 GMT

>up since. But I shall keep trying.

And I have at last caught that site "up", and my script to download the
missing archive is chugging away, even as we speak.

>why that has never happened as of yet.

And I have now done that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 19:26:02 GMT

>you have snipped.

> >   on the system (for example, a process id number) on the left hand
They clearly say nothing about the semantics of <id-right>. Note that the
word "semantics" implies something that tells you the "meaning".

The text in question gives sound (even RECOMMENDED) advice on how to
*generate* an <id-right>, in order to fulfil the REQUIREMENT that what
you generate is to be globally unique. It tells you nothing about the
meaning of the object you have generated, or what it is to be used for, or
how (though there are instructions elsewhere in RFC 2822 as to how to use
it in constructing a References field). In particular, there is nothing to
say that its semantics (meaning) is in any way related to the semantics
(meaning) of a <domain>.

If you read elsewhere in RFC 2822, you will find that, semantically, the
<msg-id> is intended to identify a particular version of a particular
message, and also that certain rules regarding quoted-pairs are relevant
(though that bit does not apply in USEFOR). And that is all the semantics
that is given.

>  John Stanley seems to have identified some problem
>indicating intended humor or exaggeration));

John thinks the edit could be done in 10 minutes. He might well be right,
but the remaining 50 minutes, "or so", would be needed to remove all the
false positives that such a naive approach would undoubtedly throw up :-).

>Please cite RFC 2822 text supporting your "opaque labels" assertion.

Please cite the RFC text supporting your assertion that they are anything
else than "opaque" (once generated).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 16:59:01 GMT

>have been sorted out amicably"?

Do you have evidence that they have not? Do you have evidence that the
various sites called "wolf" have actually used that name in their
path-identities? Have you ever seen dicussion in the various news.admin.*
newsgroups discussing problems arising from such causes (I have not, that
I recall). Has Usenet been brought to its kneed due to this cause (I often
hear of the "death of the net predicted" for a variety of causes, but
never from that one).

In short, have you any evidence that the present setup (with no Cabal and
not even any UUCP maps anymore) is in any sense "broken"?

Clearly, use of domain-names or IP addresses is an excellent way of
ensuring that you have acquired a unique path-identity, but not all sites
necessarily even have an internet connection (for example, those using
UUCP or carrier pigeons).

It is clearly the reponsibility of anyone adopting an identity not based
on DNS of IP addresses to choose something that is unique. Our drafts do
not, cannot and should not specify how that is ensured. It is a problem
for that site to sort out as it sees fit. All out drafts have ever said
(and this is now in USEPRO) is:

|  3. An arbitrary name believed to be unique and registered at least
|     with all other news-servers receiving articles directly from the
|     given one.

If you do not like that, then you are free to propose alternatives.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 27 Jun 2005 19:28:35 -0700

Charles Lindsey <[email-masked]> writes:

> problem when ":" ceases to be a path-delimiter.

Ceasing to use it as a path delimiter is not the problem; in practice, no
one uses anything other than "!".  Starting to use it for something *else*
is the problem, since sites will continue treating it as a path delimiter.

I do agree that the possibility of colliding with a <=4 character path
identity isn't exactly the sort of risk that would keep me up at night.

> And how many sites do you suppose there exist on Usenet which consist of

Pedant point:  one to four hex digits, as you can omit the zero padding in
IPv6 address specifications.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 28 Jun 2005 09:29:55 -0400

> "public name", or whether it matters for our purpose.

See RFC 1958.
 
> it either, particularly as that is the way is has been for the last 20

So you see no problem in some random site in some random place with
some random affiliation using the opaque label "clerew.man.ac.uk".
 
> So?

So a mismatch in source of UUCP data requires no IP address information,
and your argument equating a specific case with the general case fails.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 28 Jun 2005 09:38:15 -0400

> Do you have evidence that they have not?

1. I do; the issue was reported ages ago, and not resolved after years.

2. Reasoned debate is predicated on a claimant supporting his or her
   assertions (ideally, *when* they are made), not in saying "here's
   my assertion; you prove me wrong".  You have made the claim that
   such issues "have been sorted out amicably" -- with to date no
   supporting evidence, and you have been asked to support *your*
   claim.  The burden of proof for *your* claim is on *you*, not me.
 
> not, cannot and should not specify how that is ensured.

Au contraire, requiring uniqueness but failing to indicate a suitable
method by which uniqueness can be assured is a "known technical omission"
(see BCP 9).

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 28 Jun 2005 09:49:00 -0400

> Simply changing the name of some syntax rule cannot possibly change the

Ergo, by your own logic, "id-right" does not change the meaning of
the RHS of a msg-id from that of a domain name or literal.  Nor
does it change the fact that domain names are case-insensitive.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 28 Jun 2005 09:53:43 -0400

On Mon June 27 2005 15:26, Charles Lindsey wrote:

> They clearly say nothing about the semantics of <id-right>.

2822 clearly says "the domain name (or a domain literal IP address"; it
does not say "some random string" or anything like it.  Nor does it say
that the semantics have changed from RFC 822.

[...]
> else than "opaque" (once generated).

Sorry, Charles; your claim, your burden of proof.  Prove or retract.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 28 Jun 2005 09:59:47 -0400

> problem when ":" ceases to be a path-delimiter.

That will happen when every instance of currently conforming news software
handling the Path field is replaced.  We know from past experience that
that will take a very long time.  Indeed, if anything can be said to be
"theoretical", it is that hypothetical wholesale replacement of such
software.

> Then you are welcome to propose alternative wordings.

No change would be better than that change.

> OK, you want a NOTE warning would-be generators of identities to avoid all

No, I want clear semantics and a corresponding mechanism that address
the issue, leaving no known technical omission.

---

From: Ned Freed <[email-masked]>
Date: Mon, 27 Jun 2005 18:01:24 -0700 (PDT)

> simultaneously.  Broken by design instead of engineering.

Yes, well, I have to say that out of all the stuff that's going on right now,
this is the one that has me the most worried.

				Ned

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Jun 2005 17:10:06 GMT

>And that doesn't reflect the fundamental concept <host-name>.

I think that is exactly why Kai said he was "for id-right" :-).

>timestamp, don't forget to add an '@' somewhere in the middle".

Yes, that is a perfectly reasonable implementation if you use a good
random number generator and make it long enough that the clashes are
unlikely to occur before the heat death of the universe.

It does conflict with a RECOMMENDATION in RFC 2822, but that is no
absolute bar.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 05:59:15 +0200

> I think that is exactly why Kai said he was "for id-right" :-)

Possible, then I missed this "option" / "idea" (?) in RfC 724.
Where is it ?

>> timestamp, don't forget to add an '@' somewhere in the middle"

> Yes, that is a perfectly reasonable implementation if you use
> a good random number generator and make it long enough that
> the clashes are unlikely to occur before the heat death of
> the universe.

Clashes should be restricted to your own <id-domain>.  We have
already seen one case of <number@number> where nobody knew how
it was generated.  Elsewhere I saw <number@oemcomputer>.  That
is certified madness.  Doing this in mail might work, but the
poor user is an IETF WG Chair, he sends mails to mailing lists,
and for lists it's essentially the same problem as in news.

> It does conflict with a RECOMMENDATION in RFC 2822, but that
> is no absolute bar.

<id-domain> instead of <id-right> is also no absolute bar, but
at least the semantics is then obvious.  Even for implementors.

                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 12:56:55 GMT

>that the semantics have changed from RFC 822.

RFC 2822 invites you to "put" a "domain name (or a domain literal IP
address)" when generating an <id-right>. That does not cause it not to be
an <id-right> any more, nor does it confer any semantics upon that
<id-right> that it did not already possess by virtue of its being an
<id-right>.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 12:51:23 GMT

>does it change the fact that domain names are case-insensitive.

If you replace <id-right> by <domain> (which is already defined in RFC
2822), then obviously it makes a considerable difference. But replacing
it, systematically, by <mumble-foo>, or anything else, will have no effect
whatsoever.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 13:12:19 GMT

>See RFC 1958.

Yes. Having read that, I think a <path-identity> is a "public name",
identifying a particular server.

>some random affiliation using the opaque label "clerew.man.ac.uk".

Random sites in random places are already using "clerew.man.ac.uk",
judging by the bogus bounce messages I receive from time to time :-( .

However, the text that is to go in Usefor states quite clearly that any
FQDN used as a <path-identity> SHOULD be an A record for the agent
concerned, or an MX record that is mailable. I would have thought it
pretty obvious that any FQDN or IP address used was intended to be one
relevant to that agent, but if you want me to spell that out in
excruciating detail, then I could do so.

>and your argument equating a specific case with the general case fails.

You missed the word "likely". There are ways other than the IP address
used in packets for identifying the site that is relaying to you - for
example an authorization identity obtained from a SASL exchange.
Naturally, as you observe, UUCP data will not be accompanied by an IP
address, but UUCP incorporates its own methods of identitying the sender.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 13:35:16 GMT

>handling the Path field is replaced.

No, it will officially "cease" to be a path-delimiter as soon as our
standard is published. At that point of time, the probability of their
existing any then current <path-identity> that will cause problems when
":" starts to appear (in IPv6 addresses, for example) is exceedingly
small.

So small, in fact, that Russ has said that it will not affect the
soundness of his sleep.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 13:19:22 GMT

>method by which uniqueness can be assured is a "known technical omission"

The presently proposed text leaves it to the site owner to choose a unique
name as best he can. If he screws up, then he screws up.

I will take advice from Harald as to whether that needs to be documented
as a "technical omission".

All I can say is that the problem does not seem to be a serious one on the
present Usenet. Moreover, I am still awaiting an answer to my question as
to whether there is more than one site called "wolf" on Usenet, or whether
that was just a duplicate in the old UUCP maps that merely caused problems
with misdirection of email.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 19:29:38 +0200

Charles Lindsey wrote:

> At that point of time, the probability of their existing any
> then current <path-identity> that will cause problems when
> ":" starts to appear (in IPv6 addresses, for example) is
> exceedingly small.

BTW, that's an advantage of Harald's idea, he restricts this
to _only_ IPv6, after s/no-fold-literal/IPv6address/  Bye.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 19:39:21 +0200

Charles Lindsey wrote:

> a <path-identity> is a "public name", identifying a
> particular server.

Fine, extend this good idea to s/id-right/is-domain/ ;-)

> Random sites in random places are already using
> "clerew.man.ac.uk", judging by the bogus bounce messages
> I receive from time to time :-( .

Publish a v=spf1 sender policy, it works after some weeks.
State "approved", substate "point raised - writeup needed".

> SHOULD be an A record for the agent concerned, or an MX
> record that is mailable

Don't forget the AAAA case, bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 11:12:53 -0400

On Wed June 29 2005 08:51, Charles Lindsey wrote:
> 2822),

You have that backwards; RFC 2822 changed domain (as used in 822) to
id-right for the reason explicitly noted in 2822 ("identical except
that comments and folding white space are not allowed").
 
Still no substantiation of the claim that the semantics were explicitly
changed, I note.

2003-06-30:4