Re: msg-id

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Charles Lindsey wrote:

 [mdomain instead of id-right]
> The whole thing looks such a mess that I cannot now see any
> reason for departing further than needed from RFC 2822 as
> regards the id-right.

If you want to get rid of NO-WS-CTL and quoted pairs, then...

| mdomain         = dot-atom-text / ("[" address-literal "]")
| address-literal = 1*( atext / "." / ":" )    ; see RfC 2821

...is good enough.  Address literals don't contain [, \, or ].

The stuff about "dcontent after a generalized tags registered
with IANA" in RfC 2821 is science fiction, but the pointer to
RfC 2373 (2.2 Text Representation of Addresses) IP6v is a fact.

> adopting <address-literal> from RFC 2821 does not help us,

Yes, I didn't see the "generalized" nonsense.  And I'm not sure
about the IPv6 tag in 2821, do we really want it ?  It's not
very critical in a Message-ID, but it starts to get confusing
in a path-identity.  Why not use the RfC 2373 format without a
tag ?  Anything with ":" is IPv6, anything without ":" is IPv4.

> Alexey has not really made any pronouncement yet.

Quoting <news://news.gmane.org/41C9A58A.10508@xxxxxxxxx> :

|>>Define a Message-ID compatible with NNTP, get rid of NO-WS-CTL.
|
|> Of course.

That's a clear "go", he can say "stop" if we're getting carried
away and start to reinvent the Internet... :-)

> I now see that NO-WS-CTL also appears in <id-right>.

It's everywhere in 2822, even in Subject and other unstructured
headers.  The idea was probably to avoid "over-specifications",
and the minimum "they" (incl. you ;-) could get away with was
to exclude CR, LF, and NUL in message/rfc2822.  That's the old
"be liberal in what you accept" rule, but it's too liberal for
our purposes, we want something working with existing servers
and newsreaders.

> I am coming to the conclusion that we should just omit
> NO-WS-CTL from our versions if <id-left> and <id-right>, and
> leave it at that.

Then you'd still allow <unique@[IPv9:\]\\\[]> and that's wrong,
IPv9:]\[ is no address literal.  BTW, your mdtext enumerates
%d33-61 etc., but ">" is %d34, and the comment says 'no ">"'.

My style to base enumerations on atext + additions allows to
catch such simple errors more easily.

  [unique vs. id-left]
>> anything starting or ending with a dot. That's not covered
>> by dot-atom-text.  And anything with ".." (two or more dots)
>> for the same reasons.

> If an <id-left> starts or ends with a ".", then it is not
> allowed under RFC 2822, and hence we cannot allow it either.

Yes, I was talking about the differences in id-left and unique,
i.e. your no-fold-quote and my unique-quote:

RfC 2822 and unique-quote allow <".xy."@example>, but that's
not the intention in your no-fold-quote.  Dito <"x..y"@example>.

> OK, I shall look at your latest syntax.

Our main difference or problem are now address literals.  JFTR:

| msg-id-core     =  "<" unique "@" mdomain ">"
| mdomain         = dot-atom-text / ("[" address-literal "]")
| address-literal = 1*( atext / "." / ":" )    ; see RfC 2821

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

                    Bye, Frank