Subject: Re: msg-id

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jan 2005 13:05:58 GMT

In <[email-masked]> Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> writes:

>Charles Lindsey wrote:

>> The RFC 2822 wording is slightly stronger, if anything; it
>> just doesn't apply (apparently) to <id-left> and <id-right>.
>> I would not be averse to a NOTE in USEFOR to emphasize the
>> point, but I don't think we need go beyond that.

>We could copy the 822 note:

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

I think it would be better to build on the wording already present in RFC
2822 - just making it clear that it applies to <id-right>s. Anyway, I have
added that to my list of things to do.

>....  BTW, in a recent
>discussion about the definition of Usenet I had some problems
>to explain why I wouldn't consider a Web forum interface to some
>newsgroups as a part of Usenet.  One idea was to say "if the
>users can't get the complete article in the format defined by
>RfC 1036, then it's not Usenet".  That would exclude something
>like groups-beta.google.com (not necessarily the old interface
>with its output=gplain format and access on Message-IDs).

>Or did I miss something obvious ?  The argument was, that no
>RfC forbids to use HTTP to transport Usenet articles.

There is nothing wrong in using HTTP for transport, but to follow our
standard you still have to do it within the framework of the various
agents that we define.

So far as out standard is concerned, Google is just another serving agent.
The problem is that it insists on using its ghastly interface as your only
reading agent (interfaces beteeen serving and reading agents are not
covered by our draft, though NNTP has a lot to say on the subject).

Perhaps that is a reason for leaving alone (and even strengthening) the
"Duties of a reading agent" section which some people have asked me to
remove. For sure, a reading agent should be capable of displaying
everything that is conveyed by a document in the form prescribed by
USEFOR.

>That's apparently different from usepro-01.  Maye you forgot to
>send usepro-02 to the I-D list, the last IETF I-D is still 01.
>Okay, I found the 2nd draft:

><http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-02.txt>

Aaaaarrrrggghhhhhhhhh! I am sure I sent it long ago, and it has been
discussed on this list. Anyway, I have sent it off again.

-- 
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, 26 Jan 2005 04:13:22 +0100

> I think it would be better to build on the wording already
> present in RFC 2822 - just making it clear that it applies
> to <id-right>s.

STD 10 is clearer, it says "whenever possible don't".  RfC 2822
is less convincing.  Unless you'd add a pointer to this thread
with 2821, 3513, 2396bis, foo@[b\[a\]r], and UUID discussions.

> Anyway, I have added that to my list of things to do.

Okay.  BTW, some of the links on documents.html don't work at
the moment.  What else is on your to-do lists ?  Do we have a
decent Path: syntax ?  Does it allow the same domain literals
as in Message-IDs ?  And what's the idea of your experiment
with the References: in this article (I didn't touch it ;-) ?

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 26 Jan 2005 11:04:39 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>the moment.

OK. Which ones?

>  What else is on your to-do lists ?  Do we have a
>decent Path: syntax ? 

No. That is awaiting some reaction from my last list of issues. So please
say something, somebody! It is holding up progress.

Essentially, we have to decide between various notations, since there were
some (slight but possible) suspicions that the delimiter characters we had
chosen were not the best for avoiding compatibility problems.

My own current preference is to avoid the problem by using conspicuous
entries ...!POSTED!... and ...!MISMATCH!... at the proper places in the
Path header, and to use a "double bang" ...!!... to indicate that the site
had checked the accuracy of the thing to the right of the !!.

> Does it allow the same domain literals
>as in Message-IDs ?

NO_WS_CTL has gone.

>  And what's the idea of your experiment

Ah! That was a message to the ietf-822 list which went astray (you already
saw and responded to it there).

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 27 Jan 2005 09:12:31 +0100

Charles Lindsey wrote:

  [<http://www.imc.org/ietf-usefor/documents.html>]
>> some of the links on documents.html don't work at the moment.
> OK. Which ones?

http://www.imc.org/usefor/drafts/draft-ietf-usefor-message-id-01.txt
http://www.imc.org/usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

These are the only links I tested, both result in a 404.  You
can use a tool like <http://validator.w3.org/checklink> to get
a complete list (eight 404)

For the news URL the last draft is 04 instead of 02 containing
exactly zero of your or my improvements.  Whatever that means,
neither you nor the author answered my questions about it on
the URI list.  I could try to reconstruct a "working draft" from
this mess if necessary (s/2396bis/3986/g etc.)

>> Do we have a decent Path: syntax ?

> No.
[...]
> My own current preference is to avoid the problem by using
> conspicuous entries ...!POSTED!... and ...!MISMATCH!... at
> the proper places in the Path header

Okay, that's at least some kind of common practice, "problems"
with UUCP hosts POSTED or MISMATCH are fantasy, and ICANN has
no plans to introduce TLDs POSTED or MISMATCH.

> and to use a "double bang" ...!!... to indicate that the site

Something I can't judge, how can we test it ?  If all existing
news servers have no problem with ...!!... that should be okay.

>> Does it allow the same domain literals as in Message-IDs ?
> NO_WS_CTL has gone.

What's a-5.6.1 and a-5.6.2 ?  The new drafts have no chapter
5.6.  I don't find the place where you say that a path-identity
can be a domain literal minus "[" and "]" in the case of IPv4,
or how IPv6 domain literals are specified as "path-identity".

Some syntax could help:

  path-identity = dot-atom-text / path-literal
  path-literal  = ipv4 / ipv6 / ipvfuture
  ipv4          = *( DIGIT / "." )        ; see RfC ????
  ipv6          = *( iphex / ":" / "." )  ; see RfC 3513
  ipvfuture     = "[" address-literal "]" ; see 3.1.3
  iphex         = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

So far for Alexey's "no tight syntax" <beg>  We have a problem
if IPvFuture literals can contain a "!".  And my idea is again
ambiguous, for ipv6 we'd need "at least one colon" to fix it.

For ipv4 vs. dot-atom-text we need ICANN (TLDs must contain an
ALPHA) plus a new RfC published last year about this issue.  I
don't find it at the moment, it was a BCP or FYI explaining
l-d-h-string among other problems.

>> what's the idea of your experiment with the References: in
>> this article (I didn't touch it ;-) ?

> That was a message to the ietf-822 list which went astray
> (you already saw and responded to it there).

No, your ietf-822 experiments (and my replies) all went to the
ietf-822 list, I only sent one courtesy copy to you, because I
didn't know that all GMaNe users have write access on this list.

The effect here was something different, GMaNe "raw" format:
<http://article.gmane.org/gmane.ietf.usenet.format:28096:raw>
<http://article.gmane.org/gmane.ietf.usenet.format:28097:raw>

You could of course also see it with NNTP on news.gmane.org,
some really strange References: headers... ;-)  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Jan 2005 17:20:46 GMT

>a complete list (eight 404)

That is most odd. Most of the documents are actually there (and I have
just put up a couple that are missing). I shall have to check with Pete
Hoffman.

>this mess if necessary (s/2396bis/3986/g etc.)

yes, but nothing has changed between 02 and 04 :-(. Yes, I owe you some
replies on the URI list.

>news servers have no problem with ...!!... that should be okay.

There are examples in RFC 1036 of two <path-delimiter>s adjacent, so
presumably it was intended to be OK. I would like to hear more opinions
on this. Some articles sent to the *.test groups might be a good idea too.

>What's a-5.6.1 and a-5.6.2 ?

Those are references to the old draft-13. They are currently being updated
to refer to USEFOR.

>....  I don't find the place where you say that a path-identity

It was all in the old draft-13, and I am waiting for Ken to move them into
USEFOR. But I think he is waiting until we get the delimiter conventions
sorted out, and then the whole section can be written properly.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 31 Jan 2005 21:51:24 GMT

>just put up a couple that are missing). I shall have to check with Pete

OK, these should now be fixed. The links should have said (and now do)

http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-message-id-01.txt
http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

BTW, I never announced here that, at your request, Martin Junius' scheme
for gatewaying Message-IDs between Usenet and Fidonet is now available at

http://www.imc.org/ietf-usefor/drafts/FTN-Internet.txt

To: [email-masked]
Xref: clerew local.usefor:20578
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do (was: msg-id)
Date: Mon, 31 Jan 2005 21:51:24 GMT
Lines: 41
Sender: [email-masked]

>just put up a couple that are missing). I shall have to check with Pete

OK, these should now be fixed. The links should have said (and now do)

http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-message-id-01.txt
http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

BTW, I never announced here that, at your request, Martin Junius' scheme
for gatewaying Message-IDs between Usenet and Fidonet is now available at

http://www.imc.org/ietf-usefor/drafts/FTN-Internet.txt

To: [email-masked]
Xref: clerew local.usefor:20577
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do (was: msg-id)
Date: Fri, 28 Jan 2005 17:20:46 GMT
Lines: 76
Sender: [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: To do (was: msg-id)
Date: Thu, 27 Jan 2005 09:12:31 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 80
Sender: [email-masked]

Charles Lindsey wrote:

[...]

Some syntax could help:

To: [email-masked]
Xref: clerew local.usefor:20574
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Experiment #3 with multiple Reference headers
Date: Wed, 26 Jan 2005 10:36:17 GMT
Lines: 21
Sender: [email-masked]

In <[email-masked]> Charles Lindsey <[email-masked]> writes:

>This message responds to several others, and contains a References header for
>each of them. So it cannot be expected that existing MUAs will thread them
>particularly well. So the things to look out for are:

Aaaaarrrgghhhhh! Ignore that. It was a copy of a message sent to the
ietf-822 list which I was trying to feed back into my own system, and
which got fed back to the wrong place :-( .

To: [email-masked]
Xref: clerew local.usefor:20575
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Wed, 26 Jan 2005 11:04:39 GMT
Lines: 43
Sender: [email-masked]

OK. Which ones?

NO_WS_CTL has gone.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Wed, 26 Jan 2005 04:13:22 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Wed, 26 Jan 2005 03:41:19 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Charles Lindsey wrote:

 [[\]]
> We excluded them both because RFC 2822 excludes them both.

ACK, sorry, I forgot to check 2822 dtext.  This thread about
Message-IDs and some cases of [FWS] should be finished now ;-)

            Bye, Frank (strange References: fixed here)

To: [email-masked]
Xref: clerew local.usefor:20570
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Tue, 25 Jan 2005 13:05:58 GMT
Lines: 64
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:20569
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Tue, 25 Jan 2005 12:41:58 GMT
Lines: 36
Sender: [email-masked]

> [empty domain literals]
>> No, I don't "believe" in them, but nothing breaks, so if
>> RFC2822 is prepared to countenance them, even in
>> <addr-spec>s, we should leave well (or ill) alone.

>Alexej said "no tight syntax", not "copy all bugs" ;-)

>But 1* vs. * is not really important.  One minor detail is
>still strange:  you excluded ">" because that could confuse
>very simple parsers.  You kept "<" because it's no problem.

Same in RFC 1036.

>For domain literals you exclude "]" allowing only "\]", and
>of course you also exclude "\" allowing only "\\".  So far
>the same idea as for ">".  But you also exclude "[" allowing
>only "\[".  That's not strictly necessary, how about adding
>%d91 "[" to the legal characters in a domain literal ?

We excluded them both because RFC 2822 excludes them both. We would not
have been a subset of RFC 2822 syntax if we had done otherwise.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Wed, 19 Jan 2005 17:54:48 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 77
Sender: [email-masked]

In a modern form based on 2119 that could be:

  Note:  Domain-literals SHOULD NOT be used if a FQDN
  host name is available.

Assuming that FQDN is explained somewhere in the draft.
Not in usefor-02 at the moment, so maybe that's better:

  Note:  Domain-literals SHOULD NOT be used if a fully
  qualified domain name (FQDN) for the host is available.

There's no good place for this note, you could insert it
instead of the explanation of msg-id-core (unnecessary
because you plan to use msg-id instead if msg-id-core)
at the end of 3.1.3.

3.1.3 is about msg-id, so that would result in this text:

  Note:  Domain-literals in message IDs and mailbox addresses
  SHOULD NOT be used if a fully qualified domain name (FQDN)
  is available.

> Aleyei might still say it is really a USEAGE matter.

Quoting an essential idea of STD 11 and RfC 2822 is more than
only a USEAGE matter.  In the case of dynamic IPs or IPs like
127.0.0.1 etc. domain literals can be fundamentally bad.  Okay,
localhost is not much better. :-)

> There is no problem with the path and injection-info. In the
> case of injecting agents, at least, they MUST be "mailable"
> (i.e. "news@..." or "usenet@..."), though I think this is one
> of the bits of draft-13 that Ken has not incorporated into
> USEFOR yet.

Important, it avoids some potential problems.  BTW, in a recent

> "Duties of a Posting Agent" in my current file is:

>> Message-IDs like <[email-masked]> might be a bad idea.

> I think such a Message-ID would already breach a
> RECOMMENDATION in RFC 2822. But then Agent breaches that
> RECOMMENDATION every day :-( .

It doesn't use @[b[a\]r] or @[b\[a\]r] or @body.invalid etc.
Maybe it's older than RfC 2822.  Old software is always a good
excuse to ignore any new SHOULD.
                                 Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Wed, 19 Jan 2005 13:28:24 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Charles Lindsey wrote:

 [empty domain literals]
> No, I don't "believe" in them, but nothing breaks, so if
> RFC2822 is prepared to countenance them, even in
> <addr-spec>s, we should leave well (or ill) alone.

Alexej said "no tight syntax", not "copy all bugs" ;-)

But 1* vs. * is not really important.  One minor detail is
still strange:  you excluded ">" because that could confuse
very simple parsers.  You kept "<" because it's no problem.

For domain literals you exclude "]" allowing only "\]", and
of course you also exclude "\" allowing only "\\".  So far
the same idea as for ">".  But you also exclude "[" allowing
only "\[".  That's not strictly necessary, how about adding
%d91 "[" to the legal characters in a domain literal ?

| address-literal = 1*( %d33-61 /     ; for IPv6 see RfC 3513
|                       %d63-91 /     ; printable ASCII
|                       %d94-126 /    ; minus ">", "\", "]"
|                       "\\" / "\]" ) ; plus "\\, "\]"

Not exactly logical, but the same logic as for "<".  Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20566
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Mon, 17 Jan 2005 21:13:36 GMT
Lines: 94
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Maybe, but they made a really bad job out of it.  You asked
>for something in STD 11 about this problem, and I found only:

>| A domain-ref must be THE official name of a registry, network,
>| or host.  It is a symbolic reference, within a name sub-
>| domain.  At times, it is necessary to bypass standard mechan-
>| isms for resolving such references, using more primitive
>| information, such as a network host address rather than its
>| associated host name.

>| To permit such references, this standard provides the domain-
>| literal  construct.  Its contents must conform with the needs
>| of the sub-domain in which it is interpreted.

I.e. it depends on the network. On the internet, we have IPv[46] at the
moment.

>| Domain-literals which refer to domains within the ARPA Inter-
>| net specify 32-bit Internet addresses, in four 8-bit fields
>| noted in decimal, as described in Request for  Comments #820,
>| "Assigned Numbers."  For example:
>|                                   [10.0.3.19]

The RFC 2822 wording is slightly stronger, if anything; it just doesn't
apply (apparently) to <id-left> and <id-right>. I would not be averse to a
NOTE in USEFOR to emphasize the point, but I don't think we need go beyond
that. It is really their problem. And Aleyei might still say it is really
a USEAGE matter.

>In the times of STD 10 and 11 no problem, they had routes and
>return-paths and gateways.  If there was a question about b[a]r
>they probably could ask postmaster%b[a][email-masked]

>Now I'm tempted to say somewhere in the draft(s) that a system
>using local@[b\[a\]r] in net news should make sure that its
>path or injection-info somehow allow to determine the FQDN
>gateway.example   OTOH that's a bit too esoteric for my taste.

There is no problem with the path and injection-info. In the case of
injecting agents, at least, they MUST be "mailable" (i.e. "news@..." or
"usenet@..."), though I think this is one of the bits of draft-13 that Ken
has not incorporated into USEFOR yet.

> [From: header]
>> Alexei didn't want it covered in USEFOR, so it's now in
>> USEPRO (isn't it in the latest draft - it is certainly now in
>> my master copy).

>I didn't see it in usepro-01.  The TLD .invalid stuff is there,
>but 2822 obviuously expects valid From: mailbox addresses, and
>therefore it might be necessary to mention TLD .invalid in
>USEFOR explicitly.  At the moment all you have is a pointer to
>RfC 2822, is that good enough for the TLD .invalid addresses ?

The wording in "Duties of a Posting Agent" in my current file is:

   Contrary to [RFC 2822], which states that the mailbox(es) in the From
   header is that of the poster(s), a poster who does not, for whatever
   reason, wish to use his own mailbox MAY use any mailbox ending in the
   top level domain ".invalid" [RFC 2606].

AFAIR that was in Usepro-02.

>The idea is, or rather I think the idea is, that an address
>with domain literal b[a]r must be valid somewhere, and if it's
>visible in the Internet (or Usenet), then a gateway for b[a]r
>must be known.  But TLD .invalid is really invalid, there's no
>gateway or MX for an .invalid address.

>Valid vs. invalid From: addresses, or valid vs. invalid right
>hand sides of Message-IDs are also our problem.  When two or
>more systems start to create the same Message-IDs or to cancel
>articles of the other systems it's relevant for us.  The least
>we should do is to warn people that there's no such thing as a
>"correct" cancel for articles from [email-masked], and that
>Message-IDs like <[email-masked]> might be a bad idea.

I think such a Message-ID would already breach a RECOMMENDATION in RFC
2822. But then Agent breaches that RECOMMENDATION every day :-( .

To: [email-masked]
Xref: clerew local.usefor:20564
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Archive
Date: Mon, 17 Jan 2005 20:43:01 GMT
Lines: 32
Sender: [email-masked]

>>Ah! So you want the Archive header to have provision for a list of
>>MIME-style parameters (just like we originally intended for all the news
>>headers), but with no specific parameters defined just yet. Then the
>>filename parameter can be added later if/when there is a specific need for
>>it.
>>
>>Anyone else happy with that arrangement? I see no problem.
>>  
>>
>Not talking about particular syntax for extensions, this sounds fine to me.

OK, I think Alexey, Frank and myself would be happy with that, and someone
else in this thread seemed to think the possibility of filename parameters
might be useful at some later date to the news.answers moderators, but no
pressing need for them at this instant. No other comments. Does that mean
we have a rough consensus?

To: [email-masked]
Xref: clerew local.usefor:20565
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Mon, 17 Jan 2005 20:47:48 GMT
Lines: 21
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>It's essentially the same as the usefor-02 no-fold-literal, the
>only difference is 1*(...) instead of *(...) because I don't
>believe in empty domain literals.  Anything else is cosmetical.

No, I don't "believe" in them, but nothing breaks, so if RFC2822 is
prepared to countenance them, even in <addr-spec>s, we should leave well
(or ill) alone.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Sun, 16 Jan 2005 22:21:19 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 96
Sender: [email-masked]

Charles Lindsey wrote:

> I need a ruling from the chair to depart from RFC 2822 on a
> matter where no problem of interoperability arises (or where
> it was a problem that already existed in email).

Apparently Alexej likes your idea to allow anything which is
not a known problem better than my idea atext / "." / ":" or
less, so that's settled, see my reply to Alexej.

 [b\[a\]r]
> Who knows? It might mean something in IPv99, or in some
> totally different transport medium.  I suppose that is why
> both RFC 822 and RFC 2822 left it so wide open.

Maybe, but they made a really bad job out of it.  You asked
for something in STD 11 about this problem, and I found only:

| A domain-ref must be THE official name of a registry, network,
| or host.  It is a symbolic reference, within a name sub-
| domain.  At times, it is necessary to bypass standard mechan-
| isms for resolving such references, using more primitive
| information, such as a network host address rather than its
| associated host name.

| To permit such references, this standard provides the domain-
| literal  construct.  Its contents must conform with the needs
| of the sub-domain in which it is interpreted.

| Domain-literals which refer to domains within the ARPA Inter-
| net specify 32-bit Internet addresses, in four 8-bit fields
| noted in decimal, as described in Request for  Comments #820,
| "Assigned Numbers."  For example:
|                                   [10.0.3.19]

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
|        is permitted only as a means of bypassing temporary
|        system limitations, such as name tables which are not
|        complete.

In other words, don't use domain literals whenever possible.

If necessary it must have a meaning within the sub-domain where
it's used.  For IN it's an IP, but maybe a "bar" network exists
where b[a]r has a meaning, the name of an amateur radio station
or whatever.

In the times of STD 10 and 11 no problem, they had routes and
return-paths and gateways.  If there was a question about b[a]r
they probably could ask postmaster%b[a][email-masked]

Now I'm tempted to say somewhere in the draft(s) that a system
using local@[b\[a\]r] in net news should make sure that its
path or injection-info somehow allow to determine the FQDN
gateway.example   OTOH that's a bit too esoteric for my taste.

 [From: header]
> Alexei didn't want it covered in USEFOR, so it's now in
> USEPRO (isn't it in the latest draft - it is certainly now in
> my master copy).

I didn't see it in usepro-01.  The TLD .invalid stuff is there,
but 2822 obviuously expects valid From: mailbox addresses, and
therefore it might be necessary to mention TLD .invalid in
USEFOR explicitly.  At the moment all you have is a pointer to
RfC 2822, is that good enough for the TLD .invalid addresses ?

The idea is, or rather I think the idea is, that an address
with domain literal b[a]r must be valid somewhere, and if it's
visible in the Internet (or Usenet), then a gateway for b[a]r
must be known.  But TLD .invalid is really invalid, there's no
gateway or MX for an .invalid address.

Is [email-masked] a third category ?  In theory there could
be another domain system, where example.ten makes sense.  More
probably it's a typo or intentional nonsense.  And TLD .invalid
is "better" than other invalid addresses, because it's at least
obvious.  And it's one of the USEFOR ideas which are already
"common practice" to a certain degree.  Hiding this somewhere
deep in USEPRO could be seen as a step backwards.

I'm not sure about it, and maybe my interpretation that 2822
"obviously" wants valid addresses is wrong.

> essentially a problem for the mail people, not for us.

Valid vs. invalid From: addresses, or valid vs. invalid right
hand sides of Message-IDs are also our problem.  When two or
more systems start to create the same Message-IDs or to cancel
articles of the other systems it's relevant for us.  The least
we should do is to warn people that there's no such thing as a
"correct" cancel for articles from [email-masked], and that
Message-IDs like <[email-masked]> might be a bad idea.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Sun, 16 Jan 2005 20:43:02 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 102
Sender: [email-masked]

Alexey Melnikov wrote:

>>>| mdomain = dot-atom-text / ("[" address-literal "]")

>> I am still waiting for a ruling from our Chair as to whether
>> we can make further changes to the RFC 2822 <msg-id> that
>> are not required by some absolute technical necessity.

> Such changes are outside the scope for the WG and should be
> done when RFC 2822 is revised. In particular, we should avoid
> temptation to define a tight syntax for "mdomain" - doing so
> might hurt USEFOR in the future.

Okay, let's sort it out, "mdomain" is IMO just a better name
than "id-right" (and "unique" is better than "id-left") for two
reasons:

1 - our "id-left" and "id-right" _syntax_ is a proper subset of
    the 2822-syntax.  We want canonical (= unambiguous) msg-ids
    without NO-WS-CTL for NNTP and the news-URL.

2 - our "id-left" and "id-right" still have the same semantics
    as 2822, 1036, etc.  This semantics is better reflected by
    "unique" / "mdomain" instead of new "id-left" / "id-right"

Only a new name for a necessary change, so that's apparently
allowed for you and Charles.  You're not necessarily convinced
that it's a good idea, but it's not a "political" question.  Is
that correct so far ?

Whatever the future name of the RHS is, "mdomain" or "id-right",
we need some syntax for it.  Obviously we all want the RfC 2822
dot-atom-text for the normal cases wich are no domain literals:

TBD1 = dot-atom-text / ( "[" TBD2 "]" )

For TBD1 insert either id-right or mdomain as the name of this
beast.  And for TBD2 insert either no-fold-literal or address-
literal.  Again the name should be no political question, but
IMHO it's clearer to say address-literal, the syntax isn't the
same as no-fold-literal in 2822.

Finally you say that a "tight" syntax for TBD2 is out of scope.
That kills any attempt to specify address literals completely,
like copying syntax from 2821, 3513, or the old draft trying
this (hex. digits plus dot and colon).

We apparently all agree that we don't want to define address
literals completely, and that's one interpretation of "tight".

The next logical step is to enumerate all legal characters in a
domain literal without details:

1*( DIGIT / "a" / "b" / "c" / "d" / "e" / "f" / "." / ":" )

My crystal ball tells me that while that's not a complete
specification, it's still too "tight" for you, and I also
don't like it, it wouldn't allow version tags like ipv6: etc.

1*( atext / "." / ":" )

The same notoriously unreliable crystal ball tells me that you
also don't like this, although it's not really "tight".  The
only proposed alternative is Charles' "maximal" solution:

1*( atext / "." / ":" / "," / ";" / "(" / ")" /
            "<" / "@" /  DQUOTE / "\\" / "\[" / "\]" )

Putting it all together I get this updated syntax for a msg-id:

| msg-id          =  "<" unique "@" mdomain ">"

| unique          = dot-atom-text / ( DQUOTE unique-quote DQUOTE )
| unique-quote    = ( "." [unique-part] ) /
|                   ( [unique-part] "." ) /
|                   ( [unique-part] unique-literal [unique-part] )
| unique-part     = 1*( atext / "." / unique-literal )
| unique-literal  = "(" / ")" / "," / ; all specials, minus ">",
|                   "[" / "]" / "@" / ; minus DQUOTE, minus "\",
|                   ":" / ";" / "<" / ; minus single ".", plus:
|                   ".." / "\\" / ( "\" DQUOTE )

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

Can we agree on this very broad syntax for address-literal in a
msg-id, or is there still a syntactical (or even political ;-)
problem ?

If the syntax is fine then the name address-literal instead of
no-fold-literal is IMHO justified, because this syntax is much
simpler than the "[" *(dtext / quoted-pair) "]" stuff in 2822.

It's essentially the same as the usefor-02 no-fold-literal, the
only difference is 1*(...) instead of *(...) because I don't
believe in empty domain literals.  Anything else is cosmetical.

                        Bye, Frank

Date: Fri, 14 Jan 2005 23:21:26 -0500
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: msg-id
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Frank Ellermann <[email-masked]> writes:
>  
>
>>Charles Lindsey wrote:
>>    
>>
>>| msg-id-core     =  "<" unique "@" mdomain ">"
>>| mdomain         = dot-atom-text / ("[" address-literal "]")
>>    
>>
>
>I am still waiting for a ruling from our Chair as to whether we can make
>further changes to the RFC 2822 <msg-id> that are not required by some
>absolute technical necessity.
>  
>
Such changes are outside the scope for the WG and should be done when 
RFC 2822 is revised.
In particular, we should avoid temptation to define a tight syntax for 
"mdomain" - doing so might hurt USEFOR in the future.

>And it would be nice to hear also from other WG members as to whether they
>approve of these further changes that you are suggesting.
>  
>

Date: Fri, 14 Jan 2005 21:40:04 -0500
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Archive
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Frank Ellermann <[email-masked]> writes:
>  
>
>>Charles Lindsey wrote:
>>    
>>
>>>I don't really see what point you are trying to make, or what
>>>you find wrong with my words "future use, and also to allow
>>>future extensions to add further parameters".
>>>      
>>>
>>You say:  We need filename for further parameters.  I say:  No,
>>opt-parameter-list could do this trick without a filename.  The
>>point is that I'm against the filename, and maybe Bruce also
>>doesn't like it:
>>    
>>
>
>Ah! So you want the Archive header to have provision for a list of
>MIME-style parameters (just like we originally intended for all the news
>headers), but with no specific parameters defined just yet. Then the
>filename parameter can be added later if/when there is a specific need for
>it.
>
>Anyone else happy with that arrangement? I see no problem.
>  
>
Not talking about particular syntax for extensions, this sounds fine to me.

To: [email-masked]
Xref: clerew local.usefor:20559
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Fri, 14 Jan 2005 17:04:22 GMT
Lines: 99
Sender: [email-masked]

>> (ruling from the Chair still awaited)

>Something is odd if you need "higher" authorities to define the
>essence of net news, i.e. Message-ID.  I still think that's our
>job.  Of course Alexej could help us (add tin[wuo] as needed)
>if we'd confuse Message-IDs with say message digests or UUIDs.
>The proposed UUID standard was checked by the A-D.

I need a ruling from the chair to depart from RFC 2822 on a matter where
no problem of interoperability arises (or where it was a problem that
already existed in email).

>Only syntactically legal, but it's a strictly invalid domain
>literal b[a]r

>No version of IP and no notation for IPs allows b[ar]r, what's
>it supposed to mean as either IPv4 or IPv6 ? 

Who knows? It might mean something in IPv99, or in some totally different
transport medium. I suppose that is why both RFC 822 and RFC 2822 left it
so wide open.

>It's definitely illegal as the RHS of a From: mailbox in net
>news, the only allowed invalid RHS is something ending in "TLD"
>.invalid, as the name says.

>That important bit of information didn't make it from the last
>complete draft to the new split stuff, but it's clear in 2822
>(3.6.2).  IMNSHO you should add this explicitly to the split
>drafts:

Yes. Alexei didn't want it covered in USEFOR, so it's now in USEPRO (isn't
it in the latest draft - it is certainly now in my master copy). It's not
the only thing still missing from USEFOR.

>Back to your example, From: <foo@[b\[a\}r]> is illegal.  Reason:

>| The "From:" field specifies the author(s) of the message, that
>| is, the mailbox(es) of the person(s) or system(s) responsible
>| for the writing of the message.

>That's what 2822 says in section 3.6.2, and therefore it's also
>relevant for the split drafts.

So why is it allowed in 822 and 2822? Presumably to allow for future
transport arrangements where it might be meaningful. But it is essentially
a problem for the mail people, not for us.

>> I want a subset of the RFC 2822 syntax, with the same name
>> and the same semantics

>You really want a new meaning for the RHS in the case of address
>literals, your idea is not the same as in all Internet standards.

>Let's take the stuff you found in an old draft, with hex. digits 
>etc.  My proposal atext / "." / ":" was obviously much too broad
>to avoid this confusion. 

>> I see nothing in RFC 822 which says that. AFAICS, RFC 822
>> allows URNs, SSNs and all other nonsense in <domain-literals>,
>> just like RFC 2822 does.

>| An addr-spec is a specific Internet identifier that contains a
>| locally interpreted string followed by the at-sign character
>| ("@", ASCII value 64) followed by an Internet domain.  
>[...]
>| In the domain-literal form, the domain is interpreted as the
>| literal Internet address of the particular host.  In both
>| cases, how addressing is used and how  messages are
>| transported to a particular host is covered in the mail
>| transport document [RFC2821].  These mechanisms are outside
>| of the scope of this document.

But those words are not in RFC 822, as you implied. OK, I now see them in
RFC 2822, but they are still indicating that it is up to the transport
document to state the precise interpretation.

But those words do at least give you a case for saying that there is a bug
in RFC 2822, insofar as it did not apply that wording to no-fold-literals.
But then, I still don't think it is our job to fix bugs in RFC 2822, but
again you can appeal to our Chair on that.

Date: Thu, 13 Jan 2005 22:24:17 +0100
From: Frank Ellermann <[email-masked]>
Organization: <URL:http://purl.net/xyzzy>
To: [email-masked]
Subject: Re: msg-id
Sender: [email-masked]

Charles Lindsey wrote:

>> 2822 id-left, id-right, and no-fold-literal are different,
>> we want to _replace_ them completely by the original (1036
>> and 2822 addr-spec) concepts unique, mdomain, and
>> address-literal.

> No we (tinw) don't. Maybe you do

Yes, I want <unique@mdomain> based on 822, 1036, s-o-1036, and
the msg-id semantics of 2822.  BTW, we just got a new proposed
standard with a completely different concept of unique IDs:

<http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt>

Announced in <[email-masked]> today, it's
based on unique MAC addresses and UTC timestamps (100 nano-
second steps since Oct 15 1582) with provisions to use random
numbers and / or parts of MD5 / SHA1 hashes where this doesn't
work directly.  Incl. ways to use an FQDN instead of a MAC
address.

Fascinating stuff, but less convincing than our - oops, "my" -
concept of <unique@mdomain> if two parties use one of the MAC
surrogates and generate duplicates.  With "my" concept it's at
least clear who owns the name space (= RHS).

> nobody else seems to want to

Except from STD 11, 1036, and s-o-1036 maybe.  Message-IDs are
not really "my" idea.

> (ruling from the Chair still awaited)

Something is odd if you need "higher" authorities to define the
essence of net news, i.e. Message-ID.  I still think that's our
job.  Of course Alexej could help us (add tin[wuo] as needed)
if we'd confuse Message-IDs with say message digests or UUIDs.
The proposed UUID standard was checked by the A-D.

> please bear in mind that we would still have the possibility
> of those "funny" literals in <add-spec>s, as in
>     From: foo@[b\[a\]r]
> which is still legal (though maybe nonsensical) in both RFC
> 2822 and in our draft.

Only syntactically legal, but it's a strictly invalid domain
literal b[a]r

No version of IP and no notation for IPs allows b[ar]r, what's
it supposed to mean as either IPv4 or IPv6 ?  If more than one
system tries to create Message-IDs with RHS [b\[a\]r] they are
lost.

It's definitely illegal as the RHS of a From: mailbox in net
news, the only allowed invalid RHS is something ending in "TLD"
.invalid, as the name says.

That important bit of information didn't make it from the last
complete draft to the new split stuff, but it's clear in 2822
(3.6.2).  IMNSHO you should add this explicitly to the split
drafts:

| The From-header contains the electronic address(es), and
| possibly the full name, of the article's poster(s

That's 1036, you already had a better version covering more than
one mailbox and the TLD .invalid stuff,  Who deleted this when
and why from the new split drafts ?

Back to your example, From: <foo@[b\[a\}r]> is illegal.  Reason:

| The "From:" field specifies the author(s) of the message, that
| is, the mailbox(es) of the person(s) or system(s) responsible
| for the writing of the message.

That's what 2822 says in section 3.6.2, and therefore it's also
relevant for the split drafts.  IMHO you can't do it with this
inheritance trick.  RfC 2822 doesn't allow TLD .invalid for an
intentionally invalid mailbox.

> I want a subset of the RFC 2822 syntax, with the same name
> and the same semantics

Okay, that should reduce our differences to the names and the
proper subset of the syntax.  But if that's so, why do you
think that b[a]r is a "legal" domain literal ?  It's illegal.

>> I want the 2822 semantics with a new syntax and an obvious
>> name address-literal.  IPv4, IPv6, or IPvX are fine.  But
>> URNs, SSNs, or other stuff in square brackets won't do as
>> RHS of a msg-id.
 
> Why ever not? They are currently allowed (though maybe stupid)
> in the RHS of an <addr-spec> and they are currently allowed
> (in RFC 2822) in the RHS of a <msg-id>.

They are not allowed as RHS of addr-spec and msg-id, they are no
valid domain literals.  Nobody "owns" an IP b[a]r, you can't ask
the owner when there are problems with these b[a]r constructs.

You really want a new meaning for the RHS in the case of address
literals, your idea is not the same as in all Internet standards.

Let's take the stuff you found in an old draft, with hex. digits 
etc.  My proposal atext / "." / ":" was obviously much too broad
to avoid this confusion. 

> I see nothing in RFC 822 which says that. AFAICS, RFC 822
> allows URNs, SSNs and all other nonsense in <domain-literals>,
> just like RFC 2822 does.

| An addr-spec is a specific Internet identifier that contains a
| locally interpreted string followed by the at-sign character
| ("@", ASCII value 64) followed by an Internet domain.  
[...]
| In the domain-literal form, the domain is interpreted as the
| literal Internet address of the particular host.  In both
| cases, how addressing is used and how  messages are
| transported to a particular host is covered in the mail
| transport document [RFC2821].  These mechanisms are outside
| of the scope of this document.

Without looking I'm absolutely sure that RfC 2821 or STD 10 have
no idea how to transport a message from or to a UUID, SSN, URN,
or what else.
 
> AFAICS, we DO stick to the STD 11 meaning of a domain-literal.

No, the UUID, b[a]r, URN, ICBM, etc. stuff is fascinating, but
it's not in STD 11 / 10 or RfC 2822 / 2821, let alone RfC 1036.

                           Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20557
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Wed, 12 Jan 2005 11:57:36 GMT
Lines: 82
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>But 2822 id-left, id-right, and no-fold-literal are different,
>we want to _replace_ them completely by the original (1036 and
>2822 addr-spec) concepts unique, mdomain, and address-literal.

No we (tinw) don't. Maybe you do, but nobody else seems to want to, and I
am not sure that our remit allows us to (ruling from the Chair still
awaited).

And please bear in mind that we would still have the possibility of those
"funny" literals in <add-spec>s, as in
    From: foo@[b\[a\]r]
which is still legal (though maybe nonsensical) in both RFC 2822 and in
our draft.

>Now please correct me if I got this wrong,  but apparently you
>want a new semantics with a new syntax and the old 2822 name,
>essentially "anything in square brackets minus >, [, ], and \
>goes, adding \[, \], and \\".  URN, SSN, ICBM, IPv4, or IPv6,
>anything in square brackets is possible, as long as the result
>together with the LHS and "@" is a unique string.

No, I want a subset of the RFC 2822 syntax, with the same name and the
same semantics, just like we did for <msg-id> (almost) and <unstructured>.

>I want the 2822 semantics with a new syntax and an obvious name
>address-literal.  IPv4, IPv6, or IPvX are fine.  But URNs, SSNs,
>or other stuff in square brackets won't do as RHS of a msg-id.

Why ever not? They are currently allowed (though maybe stupid) in the RHS
of an <addr-spec> and they are currently allowed (in RFC 2822) in the RHS
of a <msg-id>.

>1036 mumbles something about 822:

>| In order to conform to RFC-822, the Message-ID must have the
>| format:  <unique@full_domain_name>

>822 simply says (not in this order):

>| msg-id         = "<" addr-spec ">"       ; Unique message id
>| addr-spec      = local-part "@" domain   ; global address
>| domain         = sub-domain *("." sub-domain)
>| sub-domain     = domain-ref / domain-literal
>| domain-literal = "[" *(dtext / quoted-pair) "]"

>1036 somehow managed to inherit the concept "domain-literal"
>from 822, and this 822 "domain-literal" is a close relative of
>the "no-fold-literal" in 2822.  Minus the folding and other
>problems in 822.

>STD 11 (822) is also very clear about the meaning and the usage
>of domain literals, they are _not_ arbitrary stuff in square
>brackets.  And they are exceptions, the normal case is what we
>know as FQDN.

I see nothing in RFC 822 which says that. AFAICS, RFC 822 allows URNs,
SSNs and all other nonsense in <domain-literals>, just like RFC 2822 does.

>> it is our Chair that you have to convince, not me.

>First of all I want to convince you that we better stick to the
>STD 11 meaning of a domain-literal, even if it appears in an
>obscure place like the RHS of a msg-id.

AFAICS, we DO stick to the STD 11 meaning of a domain-literal.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Tue, 11 Jan 2005 20:02:44 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 120
Sender: [email-masked]

Charles Lindsey wrote:

 [<unique@mdomain> vs. <id-left@id-right>]
> You agreed yesterday we should define our own <msg-id> rather
> than the ugly <msg-id-core>, even though it isn't an exact
> plugin replacement.

Yes, as an exception.  What we really want there is to _update_
the existing 2822 msg-id syntax (without explicitly saying so).

But 2822 id-left, id-right, and no-fold-literal are different,
we want to _replace_ them completely by the original (1036 and
2822 addr-spec) concepts unique, mdomain, and address-literal.

> On the same grounds, it is proper to use <id-left> and
> <id-right> with our more restricted syntax (because they
> _are_ plugin replacements).

That would obscure the 1036 and 2822 semantics "like addr-spec,
only unique and no CFWS":

| the msg-id has a similar syntax to angle-addr (identical
| except that comments and folding white space are not
| allowed)

That's a quote from 2822, they really wanted to get this right.
Somewhere in the mazes of CFWS, obs-id-left, and obs-id-right
they dropped the ball and invented the new names id-left and
id-right.  The "real" idea of a msg-id is <unique@mdomain> and
not some arbitrary <id-left@id-right>.

> we have agreed to chop out the NO-WS-CTL, because it
> conflicts with NNTP.

Yes, and for the same reason we agreed to remove all redundant
(unnecessary) quoted strings and quoted-pairs, and to guarantee
unambiguous (canonical) Message-IDs w.r.t. the LHS (= unique).

We're also ready for a normal FQDN as RHS, because that's the
same dot-atom-text (minus obs-id-right = domain) as in 2822.

We're not yet ready with the remaining case of a domain literal
as RHS.  You want an anonymous "no-fold-literal" (same name as
in 2822, but a different syntax), I prefer "address-literal"
(syntax and name different from 2822, but identical semantics).

Now please correct me if I got this wrong,  but apparently you
want a new semantics with a new syntax and the old 2822 name,
essentially "anything in square brackets minus >, [, ], and \
goes, adding \[, \], and \\".  URN, SSN, ICBM, IPv4, or IPv6,
anything in square brackets is possible, as long as the result
together with the LHS and "@" is a unique string.

I want the 2822 semantics with a new syntax and an obvious name
address-literal.  IPv4, IPv6, or IPvX are fine.  But URNs, SSNs,
or other stuff in square brackets won't do as RHS of a msg-id.

That would be a major difference.  No wonder that we don't find
the same syntax for this beast.

>> ask for address-literal = atext / "." / ":"
>> Let the inventors of IPvFuture decide what they want when
>> they start their future work, it's not our business.

> That's just adding a third conflicting syntax, which helps
> nobody.

There will be _four_ versions whatever you do:  2821, 2822, and
2396bis plus either your no-fold-literal (not the same as 2822)
or one of my address-literal proposals (2822 semantics).  The
address-literal = atext / "." / ":" is the minimum to get away
with, your syntax is the maximum.

>> Your versions of 1036 and s-o-1036 are very different from
>> my versions, I have full_domain_name (1036) and domain
>> (s-o-1036).

> Neither of which allows IP addresses at all, and yet they are
> commonly used.

1036 mumbles something about 822:

| In order to conform to RFC-822, the Message-ID must have the
| format:  <unique@full_domain_name>

822 simply says (not in this order):

| msg-id         = "<" addr-spec ">"       ; Unique message id
| addr-spec      = local-part "@" domain   ; global address
| domain         = sub-domain *("." sub-domain)
| sub-domain     = domain-ref / domain-literal
| domain-literal = "[" *(dtext / quoted-pair) "]"

1036 somehow managed to inherit the concept "domain-literal"
from 822, and this 822 "domain-literal" is a close relative of
the "no-fold-literal" in 2822.  Minus the folding and other
problems in 822.

STD 11 (822) is also very clear about the meaning and the usage
of domain literals, they are _not_ arbitrary stuff in square
brackets.  And they are exceptions, the normal case is what we
know as FQDN.

> it is our Chair that you have to convince, not me.

First of all I want to convince you that we better stick to the
STD 11 meaning of a domain-literal, even if it appears in an
obscure place like the RHS of a msg-id.  If we could agree on
this part, then it's only consequent to use a clear name like
address-literal for it instead of overloading no-fold-literal
with your new syntax.

And with a proper name it's obvious that we could use any new
syntax not causing immediate problems with NNTP, IPv6, 2396bis,
or the news URL.  You found the maximal solution, I found the
opposite, and if you'd call the result "address-literal", then
the syntax isn't the most important issue.  I'm much more
interested in the meaning.
                          Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20555
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Fri, 7 Jan 2005 15:19:14 GMT
Lines: 80
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:
> 
>>>| msg-id-core     =  "<" unique "@" mdomain ">"
>>>| mdomain         = dot-atom-text / ("[" address-literal "]")
> 
>> I am still waiting for a ruling from our Chair as to whether
>> we can make further changes to the RFC 2822 <msg-id>

>The quoted part is already okay, only different names instead
>of a redefined id-left / id-right / no-fold-literal.  Whatever
>the "political" difficulties might be, using RfC 2822 names for
>a different USEFOR syntax would be too confusing.

Not so. We have used it for <unstructured> (because it applies everywhere
that RFC 2822 uses <unstructured>). You agreed yesterday we should define
our own <msg-id> rather than the ugly <msg-id-core>, even though it isn't
an exact plugin replacement. On the same grounds, it is proper to use
<id-left> and <id-right> with our more restricted syntax (because they
_are_ plugin replacements).

>> What you say may be highly desirable

>Actually I don't like "(" and ")" within address-literals, but
>the 2396bis IPvFuture allows it, and IPvFuture is better than
>the 2821 General-Address-Literal with its 2822 NO-WS-CTL... :-(

But we have agreed to chop out the NO-WS-CTL, because it conflicts with
NNTP.

>> the practical politics just does not work like that.

>I'm interested what "practical IETF politics" has to say about
>hypothetical future address literals in two conflicting syntax
>versions, and their appearance in today's Message-IDs.

That's not our problem. Currently we encompass (modulo NO-WS-CTL and
quoted-pair differnences) all known versions.

>Now that you insist on Alexey's crystal ball we should actually
>ask for address-literal = atext / "." / ":".  Let the inventors
>of IPvFuture decide what they want when they start their future
>work, it's not our business.

That's just adding a third conflicting syntax, which helps nobody.

>  [RHS of Message-IDs is a domain or domain-literal]  
>>> The SHOULD in 2822 and mail is a MUST in news.

>> No, it is NOT a "MUST" in news. It is exactly the same as in
>> RFC 2822, namely it MUST be globally unique, and you can do
>> that however you like, but here is a RECOMMENDED method.

>Your versions of 1036 and s-o-1036 are very different from my
>versions, I have full_domain_name (1036) and domain (s-o-1036).

Neither of which allows IP addresses at all, and yet they are commonly
used.

>I have no objection if you insist on adding domain literals (in
>the form of address literals, no CFWS etc.) to this concept.

>But I strongly disagree with adding "whatever you like as RHS".

Our remit is to follow RFC 2822 wherever possible, which means their
version if <id-right>. If you want to do something different than that,
then it is our Chair that you have to convince, not me.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Thu, 06 Jan 2005 17:09:44 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 99
Sender: [email-masked]

Charles Lindsey wrote:
 
>>| msg-id-core     =  "<" unique "@" mdomain ">"
>>| mdomain         = dot-atom-text / ("[" address-literal "]")
 
> I am still waiting for a ruling from our Chair as to whether
> we can make further changes to the RFC 2822 <msg-id>

The quoted part is already okay, only different names instead
of a redefined id-left / id-right / no-fold-literal.  Whatever
the "political" difficulties might be, using RfC 2822 names for
a different USEFOR syntax would be too confusing.

> What you say may be highly desirable

Actually I don't like "(" and ")" within address-literals, but
the 2396bis IPvFuture allows it, and IPvFuture is better than
the 2821 General-Address-Literal with its 2822 NO-WS-CTL... :-(

> the practical politics just does not work like that.

I'm interested what "practical IETF politics" has to say about
hypothetical future address literals in two conflicting syntax
versions, and their appearance in today's Message-IDs.

Now that you insist on Alexey's crystal ball we should actually
ask for address-literal = atext / "." / ":".  Let the inventors
of IPvFuture decide what they want when they start their future
work, it's not our business.

We know that we don't want NO-WS-CTL, redundant quoted-pairs,
or ">".  atext / "." / ":" are good enough for IPv4 and IPv6.

Among the potential problems avoided by atext / "." / ":" are

- no ">" and NO-WS-CTL, excluding "<" is only consequent
- no "\" and quoted-pairs, automatically canonical for NNTP
- "[" and "]" are clear, no problem with "\[", "\[", "\\"
- no "(" and no ")", no possible confusion with comments
- no ";", broken parsers looking for MIME parameters survive
- no DQUOTE, broken parsers looking for quoted strings within
  address literals survive (it's also not allowed in 2396bis)
- no "@", good for the news URL, also not allowed in 2396bis

Char.s in this syntax but not in 2396bis [1]:
"%" / "#" / "?" / "/" / "{" / "|" / "}" / "^" / "`"

Char.s in 2396bis but not in this syntax [2]:
"," / ";" / "(" / ")"

Char.s in your no-fold-literal but not in this syntax:
"," / ";" / "(" / ")" / "<" / "@" / DQUOTE / "\\" / "\[" / "\]"

Char.s in your no-fold-literal but not in 2396bis:
"%" / "#" / "?" / "/" / "{" / "|" / "}" / "^" / "`" / 
                        "<" / "@" / DQUOTE / "\\" / "\[" / "\]"

[1]: IPvFuture has no   "{" / "|" / "}" / "^" / "`"  I have no
     idea why, these characters aren't mentioned in 2396bis (?)
[2]: No convincing reason why my syntax excludes "," (comma)

  [RHS of Message-IDs is a domain or domain-literal]  
>> The SHOULD in 2822 and mail is a MUST in news.

> No, it is NOT a "MUST" in news. It is exactly the same as in
> RFC 2822, namely it MUST be globally unique, and you can do
> that however you like, but here is a RECOMMENDED method.

Your versions of 1036 and s-o-1036 are very different from my
versions, I have full_domain_name (1036) and domain (s-o-1036).

I have no objection if you insist on adding domain literals (in
the form of address literals, no CFWS etc.) to this concept.

But I strongly disagree with adding "whatever you like as RHS".

If 2822 wanted SSNs, URLs, ISBNs, and other stuff - and I doubt
this - then it's wrong.  We have one RHS concept that's well
understood, the domain.  Anything else is untested and could
cause major trouble.

If you want say URNs as RHS of Message-IDs please do so in an
experimental RfC, but not in the "grandson" of a memo clearly
saying full_domain_name.  With a domain the authority for all
created Message-IDs is clear.  With an URN as RHS I've no idea
what to do if two systems create identical Message-IDs claiming
that the other system abuses their namespace.  Who is the owner
of an URN ?

> as is well known, Agent does not do it, either for mail or
> for news.

This software uses a dot-atom-text in the form of a domain, and
to find the relevant authority I need nothing more exotic than
DNS or maybe whois.  It certainly doesn't use address literals,
let alone URNs or avian carrier licenses in square brackets.

                        Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20553
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Wed, 5 Jan 2005 15:04:43 GMT
Lines: 54
Sender: [email-masked]

>| msg-id-core     =  "<" unique "@" mdomain ">"
>| mdomain         = dot-atom-text / ("[" address-literal "]")

I am still waiting for a ruling from our Chair as to whether we can make
further changes to the RFC 2822 <msg-id> that are not required by some
absolute technical necessity.

And it would be nice to hear also from other WG members as to whether they
approve of these further changes that you are suggesting.

>If we're unable to agree on a concept for Message-IDs in news,
>then nobody else can do in a hypothetical 2822bis.  It's the
>one thing where net news is the final authority, not RfC 2822.

What you say may be highly desirable, but the practical politics just
does not work like that.

>| 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 "@"
>[...]
>| 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.

>The SHOULD in 2822 and mail is a MUST in news. 

No, it is NOT a "MUST" in news. It is exactly the same as in RFC 2822,
namely it MUST be globally unique, and you can do that however you like,
but here is a RECOMMENDED method.

And, as is well known, Agent does not do it, either for mail or for news.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Archive
Date: Tue, 04 Jan 2005 20:14:40 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Charles Lindsey wrote:

> Archive: yes; copyright-restriction="<http://creativecommons.org/licenses/by-nc-sa/2.0/de>"

Yes, that's better, or maybe Archive: no; permission=...

I used X-NoArchive: yes when deja.news was really new for some
time, but today I'm lost.  Generally I've no problem with news
archives, quite the contrary.  I hate it if commercial sites
(ab)use newsgroups as support forum.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: msg-id
Date: Tue, 04 Jan 2005 19:54:33 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 104
Sender: [email-masked]

Charles Lindsey wrote:

> All the world and his dog are giving a conflicting syntax for
> <ipv6address>, and I do not think we want to get involved.

The quoted 2396bis text was about IPvFuture.  That's a superset
of IPv6 and IPv4 address literals.  2396bis also has the "real"
IPv6 address literals, it's the same as in 3513 and 2373.

Of course we don't want to get involved.  We only need the set
of legal characters between "<unique@[" and "]>".  And somebody
already solved this problem for us in 2396bis, the solution is
perfect for our purposes, no ambiguous quoted-pairs, no DQUOTE,
no ">", no "]", no "[".  It's much better than 2822, because we
can't use 2822.

> Just leave it as RFC 2822 has it, with only the essentual
> technical changes.

Your rules to get rid of ambiguous quoted-pairs are not simple
enough.  It starts with the wrong terms:  "id-right" is defined
in 2822, if we must have something else, then it should be as
in 1036 and its son a "domain".  But 2822 has its own "domain",
therefore let's take "mdomain".  Dito a 2822 "no-fold-literal"
is not good enough for us, let's use "address-literal", result:

| msg-id-core     =  "<" unique "@" mdomain ">"
| mdomain         = dot-atom-text / ("[" address-literal "]")

Now all we need is an enumeration of legal characters in this
address-literal:

| address-literal = 1*( atext / "." / ":" /
|                               "," / ";" / "(" / ")" )

That's already more than 2396bis allows for _future_ literals,
because they can't have "@", "#", "/", "?", and "%".

atext + 6 is 87, 128 - 34 is 94, 7 char.s are still bad in this
version and 2396bis:   DQUOTE, "\", "[", "]", "<", ">", "@".

You want 90 legal characters adding DQUOTE, "@", and "<", plus
three quoted-pairs "\[", "\]", and "\\".  Still excluding ">".

IMHO "\" (in quoted-pairs) and DQUOTE are very bad ideas, and
if ">" must be excluded then a remaining "<" is rather useless.

So for this round of the bargain I offer "@", as long as there
is at least one "@" for the news URL I don't care about any
further "@" in future address literals.  It's of course utter
dubious in the "authority" part of an URI, therefore 2396bis
doesn't allow it.  But we're talking about Message-IDs.

> much less aggro when the time for RFC 2822bis comes.

If we're unable to agree on a concept for Message-IDs in news,
then nobody else can do in a hypothetical 2822bis.  It's the
one thing where net news is the final authority, not RfC 2822.

> I didn't invent id-left and id-right. RFC 2822 did that.

The collective "you" as stated in the credits of RfC 2822 did
this, the explanation is even mentioned in the text:

| 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 "@"
[...]
| 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.

The SHOULD in 2822 and mail is a MUST in news.  In net news the
Message-ID is _essential_ for interoperability, and if somebody
has a cute idea to do something else he will go through the
pains of writing his own IESG approved amendment to 1036, its
son, and its grandson.

>> You can't say that the right part of an addr-spec supports
>> SSNs, URLs, ISBNs, or other nonsense in square brackets.
>> It's either a dot-atom-text or an address literal, nothing
>> else.

> On the contrary, RFC 2822 allows all of those things in the
> <domain-literal> part of an <addr-spec>

RfC 2822 is irrelevant for Message-IDs, proven by the cases of
ambiguous quoted-pairs and illegal NO-WS-CTL.  Now let's do it
right, that's the very minimum a future 2822bis author expects
from a net news standard, they (= we) should know Message-IDs.

> it would be entriely wrong fo forbid them in an <id-right>.

That's not the case.  The RHS of a Message-ID is a domain as
stated in 1036 and s-o-1036, anything else is wrong, address
literals are already a huge concession.

                            Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20550
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FWS problem
Date: Tue, 4 Jan 2005 12:37:07 GMT
Lines: 47
Sender: [email-masked]

>> [CFWS] should appear as normal in the Control header. That is
>> a mistake in USEFOR (cf draft-13), because the WG never asked
>> for comments to be disallowed in Control (the performance-hit
>> argument would clearly not apply).

>Control: cancel <unique@mdomain> / Supersedes; <unique@mdomain>
>are common cases, and if an implementation has a problem with
>[CFWS] in an ordinary Message-ID: <unique@mdomain> then why are
>Control: cancel / Supersedes: <unique@mdomain> less critical ?

The problem is not with [CFWS] surrounding a <msg-id> as such, but with
transit servers which need to extract the Message-ID header from _every_
message passing through them, and for which ignoring any comment that
might be present would be a significant performance hit. That just is not
true of the Control and Supersedes headers, which are only of interest to
serving agents and which, when detected, are hived off to a separate piece
of code which can deconstruct them at leisure (since they form only a
small proportion of the overall article count).

Note that there is still a generic "SHOULD NOT generate yet" for all
comments in News headers that were not known in the days of 1036, but to
be fully compliant software MUST eventually be able to accept and ignore
them, since they are a general property of _all_ headers. The only
exceptions are the few that would slow down those transit servers too
much, where we have agreed a permanent ban on them.

>BTW, s-o-1036 allows a msg-id-list in Control: cancel, but you
>stick to 1036 allowing only one msg-id, is this what you want ?

That was a quirk of s-o-1036 and of CNews which was not implemented
anywhere else. The WG discussed and rejected the idea I don't know how
many years ago.

To: LIST: [email-masked];
Xref: clerew local.usefor:20549
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Archive
Date: Tue, 4 Jan 2005 12:03:55 GMT
Lines: 56
Sender: [email-masked]

>> I don't really see what point you are trying to make, or what
>> you find wrong with my words "future use, and also to allow
>> future extensions to add further parameters".

>You say:  We need filename for further parameters.  I say:  No,
>opt-parameter-list could do this trick without a filename.  The
>point is that I'm against the filename, and maybe Bruce also
>doesn't like it:

Ah! So you want the Archive header to have provision for a list of
MIME-style parameters (just like we originally intended for all the news
headers), but with no specific parameters defined just yet. Then the
filename parameter can be added later if/when there is a specific need for
it.

Anyone else happy with that arrangement? I see no problem.

><http://article.gmane.org/gmane.ietf.usenet.format/27852> and
><http://article.gmane.org/gmane.ietf.usenet.format/28020> (6.)

>>> maybe also the token ?  I could then write
>>> Archive: creativecommons.org_licenses_by-nc-sa_2.0_de

>> Eh?

>A MIME token can't be an URL, therefore I replaced / by _ in
><URL:http://creativecommons.org/licenses/by-nc-sa/2.0/de/> and
>(ab)used the result as "copyright notice" instead of the token
>"No" in Archive: No

But why would you want a URL as a token? Tokens are keywords to introduce
parameters, as in

    some-token = "some value"

There is no reason at all why a URL should not appear in the value part of
a parameter, though is would usually have to be quoted.

I think what you were trying to achieve would be more like:

   Archive: yes; copyright-restriction="<http://creativecommons.org/licenses/by-nc-sa/2.0/de>"

Date: Tue, 04 Jan 2005 03:14:05 +0100
From: Frank Ellermann <[email-masked]>
Organization: <URL:http://purl.net/xyzzy>
To: [email-masked]
Subject: Re: FWS problem
Sender: [email-masked]

Charles Lindsey wrote:

> [CFWS] should appear as normal in the Control header. That is
> a mistake in USEFOR (cf draft-13), because the WG never asked
> for comments to be disallowed in Control (the performance-hit
> argument would clearly not apply).

Control: cancel <unique@mdomain> / Supersedes; <unique@mdomain>
are common cases, and if an implementation has a problem with
[CFWS] in an ordinary Message-ID: <unique@mdomain> then why are
Control: cancel / Supersedes: <unique@mdomain> less critical ?

BTW, s-o-1036 allows a msg-id-list in Control: cancel, but you
stick to 1036 allowing only one msg-id, is this what you want ? 

 [remove the single instance of "msg-id"]
> You may have a point there, but there is the problem that we
> use <msg-id> all over the place in the semantics, and most of
> those now need to be <msg-id-core>. So probably better to
> s/msg-id-core/msg-id/ throughout, and give the necessary
> [CFWS], CFWS or [FWS] explicitly in the syntax in the
> relevant headers.

Yes, that's a good idea.  Normally I hate it when you redefine
a 2822 term instead of introducing a new term, but in this case
it's a feature:  Your msg-id = msg-id-core is in fact the real
thing, and we want it to replace msg-id also in 2822 (of course
without explicitly saying so ;-)
                                 Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Archive
Date: Tue, 04 Jan 2005 00:56:38 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 28
Archive: creativecommons.org_licenses_by-nc-sa_2.0_de
Sender: [email-masked]

Charles Lindsey wrote:

> I don't really see what point you are trying to make, or what
> you find wrong with my words "future use, and also to allow
> future extensions to add further parameters".

You say:  We need filename for further parameters.  I say:  No,
opt-parameter-list could do this trick without a filename.  The
point is that I'm against the filename, and maybe Bruce also
doesn't like it:

<http://article.gmane.org/gmane.ietf.usenet.format/27852> and
<http://article.gmane.org/gmane.ietf.usenet.format/28020> (6.)

>> maybe also the token ?  I could then write
>> Archive: creativecommons.org_licenses_by-nc-sa_2.0_de

> Eh?

A MIME token can't be an URL, therefore I replaced / by _ in
<URL:http://creativecommons.org/licenses/by-nc-sa/2.0/de/> and
(ab)used the result as "copyright notice" instead of the token
"No" in Archive: No

That's what users normally expect if they use X-NoArchive: Yes

                           Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20543
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Archive
Date: Mon, 3 Jan 2005 15:37:22 GMT
Lines: 46
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>No, I still don't like the filename parameter.  You said that
>the purposes is (quote) "its  possible future use, and also to
>allow future extensions to add further parameters".

>RfC 3834 found a solution for the latter.

RFC 3834 found exactly the same solution that we are proposing for Archive
and Injction-Info. Yes, the present wording in USEFOR is not clear and
needs more work, and maybe RFC 3834 will provide some suitable wording. So
I don't really see what point you are trying to make, or what you find
wrong with my words "future use, and also to allow future extensions to
add further parameters".

>  You could copy its
>opt-parameter-list + explanation to Archive and Injection-Info
>if you like it.  Not the token, and maybe you could manage to
>just forget the phrase "(as amended by [N4.RFC2231])", please ?

But no, I don't think we can drop the mention of RFC 2231 altogether,
though I have no problem with some wording to point out that its use
(well, at least the multi-line bit) within Netnews is neither necessary
nor desirable.

>RfC 2231 is firmly on place three (after RfC 3865 and ISO 3166)
>of my shit list.  MIME was a piece of art, what they did to it
>in RfC 2231 is a crime.

Indeed. Dittor RFC 2047, for that matter.

>Some minutes later, maybe also the token ?  I could then write
>Archive: creativecommons.org_licenses_by-nc-sa_2.0_de

Eh?

To: LIST: [email-masked];
Xref: clerew local.usefor:20544
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FWS problem
Date: Mon, 3 Jan 2005 16:07:03 GMT
Lines: 84
Sender: [email-masked]

>> only because of loud protests by the server implementors that
>> we agreed to make exceptions for the Newsgroups and Path
>> headers, etc, but only on account of the performance hits.

>Supersedes: is relevant for news servers, like Control:, where
>you also have only three [FWS] or in the fixed variant two *WSP
>and still one [FWS] in control-message.  No [CFWS] in Control:

No, [CFWS] should appear as normal in the Control header. That is a
mistake in USEFOR (cf draft-13), because the WG never asked for comments
to be disallowed in Control (the performance-hit argument would clearly
not apply).

>IMHO you should get rid of your special USEFOR msg-id, there's
>exactly one line where you use it:

>| message-id  = "Message-ID:" SP msg-id CRLF

>For Lines: you could say that it's now deprecated and the old
>syntax was Lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF

>That's no lie, and if somebody tries new tricks with deprecated
>headers, then old software might fail for Lines: (huge)9999(!)

>> If there is something you want to forbid in a standard (such
>> as empty header lines, etc), then it is an exceedingly Bad
>> Idea to have two mechanisms for forbidding it

>Then let's use your CWSP and WSPC trick.  It's a worse idea to
>say something as a MUST in the text and then something else in
>the syntax.  The [FWS] problem is already solved for 7+2 cases,
>or 7+1 cases if you insist on Lines: (over)999(lines)

>Only 5 (or 6) similar [CFWS] cases, all solved by your idea:

>| WSPC = *WSP [ comment [CFWS] ]

>Replace all (5 or 6) "leading" (near colon) [CFWS] by WSPC.

>| CWSP = [ [CFWS] comment ] *WSP

>Dito 5 or 6 "trailing" [CFWS] => CWSP (near CRLF), ready.
>For our most critical example of the References: I get

>| references  = "References:" SP msg-id-list CRLF
>| msg-id-list = CWSP msg-id-core *( CFWS msg-id-core ) WSPC

>That's a variant enforcing at least either a comment or a WSP
>between msg-ids, it allows (x)<y@z>(a)<b@c>(u)<v@w>(e) and
><y@z> <b@c> <v@w>, but not adjacent <y@z><b@c><v@w>.   The RfC
>2822 syntax is very similar:

>| references  = "References:" 1*msg-id CRLF
>| msg-id      = [CFWS] "<" id-left "@" id-right ">" [CFWS]

>You don't use it, because msg-id one of these overloaded terms:

>| msg-id      = [FWS] msg-id-core [FWS]

>Why not simply delete the special msg-id, and use msg-id-core ?

>  message-id  = "Message-ID:" SP *WSP msg-id-core *WSP CRLF

You may have a point there, but there is the problem that we use <msg-id>
all over the place in the semantics, and most of those now need to be
<msg-id-core>. So probably better to s/msg-id-core/msg-id/ throughout, and
give the necessary [CFWS], CFWS or [FWS] explicitly in the syntax in the
relevant headers.

To: LIST: [email-masked];
Xref: clerew local.usefor:20545
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: msg-id
Date: Mon, 3 Jan 2005 16:15:24 GMT
Lines: 49
Sender: [email-masked]

>> the _real_ format, if there is such a thing, is totally
>> irrelevant, provided that it is at least permitted.

>For our discussion about the news URL I read some stuff in
><http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#host>
>2396bis uses this syntax:

>| IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
>| IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

>For IPv6 there's a pointer to RfC 3513 and the complete fun.
>There's no pointer for IPv4 (so probably the only existing
>form is 2821, and 2396bis couldn't use it for several reasons).

All the world and his dog are giving a conflicting syntax for
<ipv6address>, and I do not think we want to get involved. Just leave it
as RFC 2822 has it, with only the essentual technical changes. Will lead
to much less aggro when the time for RFC 2822bis comes.

>BTW, you already gave the reason for id-right, you couldn't use
>the right part of addr-spec (= domain) in RfC 2822 because that
>allows CFWS.  Therefore you invented id-left and id-right, only
>a hack to get addr-spec minus any CFWS.

No, I didn't invent id-left and id-right. RFC 2822 did that.

>You can't say that the right part of an addr-spec supports SSNs,
>URLs, ISBNs, or other nonsense in square brackets.  It's either
>a dot-atom-text or an address literal, nothing else.

On the contrary, RFC 2822 allows all of those things in the
<domain-literal> part of an <addr-spec> (and hence so does our draft). So
it would be entriely wrong fo forbid them in an <id-right>.