[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: msg-id



Charles Lindsey wrote:

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

> Yes, that is the only bit of RFC 2821 I had in mind to adopt.
> Indeed, Dan Kohn's original draft (and the usefor-draft-01)
> had that, but it was taken out because the WG had never agreed

Sorry, anything before 07 is far outside my radar, do you
recall the specific arguments against it ?  Was it the simple
form shown above, an enumeration of legal characters with a
pointer to one relevant RfC, or was it a complete copy of the
syntax ?

> if our Chair is willing to allow it ...

Alexej said that a Message-ID compatible with NNTP is okay,
this covers no NO-WS-CTL and some auto-canonical "unique"
instead of the 2822 id-left.  It also kills the 2822 id-right
for the same reasons.  Renaming your "id-right" to "mdomain",
and your "id-left" to "unique" is only an editorial trick to
highlight the purpose of these beasts as in 1036 and s-o-1036,
and because it's different from 2822 "id-left" / "id-right".

 [unique]
> But that looks exactly the same as my current <id-left>. Was
> there supposed to be some difference?

For the later and improved xmas-edition see
<news://news.gmane.org/41CAB9A3.77D6@xxxxxxxxxxxxxxxxx>
<http://article.gmane.org/gmane.ietf.usenet.format/28304/raw>

One small difference is 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.

Your mqspecial contains "." (single dot), and that's not good
enough for a "must-quote", the "." is also in dot-atom-text.

My unique-literal has ".." instead of your mqspecial ".", the
rest is identical.  I don't use no-fold-literal, that's a 2822
term, redefinitions are too confusing.  Instead of your mqtext
I've unique-part = 1*( atext / "." / unique-literal ), that's
IMHO clearer for readers familiar with 2822 atext and specials.

Parsing some ".." constructs will be ambiguous, OTOH there's no
reason to parse "unique-quote" as long as it either starts or
ends with a dot, or contains one unique-literal, in addition to
any number of atext, dots, and further unique-literals.

                           Bye, Frank