Subject: Re: msg-id

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 3 Jan 2005 16:15:24 GMT

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

>Charles Lindsey wrote:

>> 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>.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Mon, 3 Jan 2005 15:37:22 GMT

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?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 04 Jan 2005 00:56:38 +0100

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

> 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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 4 Jan 2005 12:03:55 GMT

>point is that I'm against the filename, and maybe Bruce also

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.

>(ab)used the result as "copyright notice" instead of the token

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>"

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 04 Jan 2005 19:54:33 +0100

Charles Lindsey wrote:

> <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.

> <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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 04 Jan 2005 20:14:40 +0100

> 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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 5 Jan 2005 15:04:43 GMT

>| 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.

>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.

>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.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 06 Jan 2005 17:09:44 +0100

> 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]  

> 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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 7 Jan 2005 15:19:14 GMT

>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).

>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.

>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.

>work, it's not our business.

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

>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.

>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.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 11 Jan 2005 20:02:44 +0100

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

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

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Jan 2005 11:57:36 GMT

>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.

>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>.

>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>.

>brackets.  And they are exceptions, the normal case is what we

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.

>obscure place like the RHS of a msg-id.

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 13 Jan 2005 22:24:17 +0100

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 14 Jan 2005 17:04:22 GMT

>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).

>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.

>(3.6.2).  IMNSHO you should add this explicitly to the split

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.

>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.

>| 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Jan 2005 21:40:04 -0500

>Anyone else happy with that arrangement? I see no problem.
Not talking about particular syntax for extensions, this sounds fine to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Jan 2005 23:21:26 -0500

>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.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 16 Jan 2005 20:43:02 +0100

>> 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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 16 Jan 2005 22:21:19 +0100

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 17 Jan 2005 20:43:01 GMT

>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?

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 17 Jan 2005 21:13:36 GMT

>| 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.

>| "Assigned Numbers."  For example:

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.

>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.

>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.

>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 :-( .

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 17 Jan 2005 20:47:48 GMT

>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.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 19 Jan 2005 13:28:24 +0100

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 19 Jan 2005 17:54:48 +0100

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.

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
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.

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

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>

> 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

---

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

>very simple parsers.  You kept "<" because it's no problem.

Same in RFC 1036.

>%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.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Jan 2005 03:41:19 +0100

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)