Subject: #1003 Message-ID issues - status

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 21 Jul 2005 15:59:05 +0200

In usefor-05, the proposed text was inserted.
However, there are some outstanding niggles:

- Some unhappiness with the recommendation on use of domain-literal.
Current text:

   If domain literals are used, the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED.

- A question on whether or not the "don't use other people's namespace" 
belongs here or not. There is current text talking about generation:

   Some software will try to match the <id-right> of a <msg-id> in a
   case-insensitive fashion; some will match it in a case-sensitive
   fashion.  Implementations MUST NOT generate two Message-IDs where the
   only difference is the case of characters in the <id-right> part.

So we need to decide if anything goes here, and if anything, what.

- Charles suggested adding a dot to the examples:

3.1.3  Message-ID

   <[email-masked]>
   <"abcd"@example.com>
   <"ab\cd"@example.com>
s/abcd/ab.cd/
s/"abcd"/"ab.cd"/
s/"ab\cd"/"ab.\cd"/

so as to illustrate the <dot-atom-text> bug found by Frank, and to agree
with the NNTP draft.

I think that's uncontroversial.

- Frank still wants to change the RHS name from "id-right" to "id-domain". 
I have not seen anyone else support this change; I am going to declare 
consensus on not changing it unless I hear other voices.

I'm leaving this ticket open until these are settled.
Comments?

                   Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 Jul 2005 16:13:13 GMT

>   [RFC2821] is RECOMMENDED.

Yes, they expect you to say "[IPv6:aaaa:bbbb:cccc:dddd......]"
which is not how IPv6 addresses are represented elsewhere, and it was
reported that even the RFC 2821 people are having 2nd thoughts, and that
implementations do not seem to be implementing it.

So I am unhappy.

>belongs here or not. There is current text talking about generation:

I have proposed USEAGE text for this under #1083.

-- 
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: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 11:57:34 -0400

> I think that's uncontroversial.

local-part (and its non-folded equivalent id-left) does not require a dot.
I don't know what "bug" is being referenced, could you please provide a
URI or message identifier.  While adding a dot doesn't hurt, I fail to see
any need to do so.  If the issue of the examples remains to illustrate
quoting, the presence or absence of a dot which is unaffected by the
quoting mechanisms seems irrelevant.

> I'm leaving this ticket open until these are settled.

In case it's unclear, I'm in favor of sticking with our professed "cite by
reference methodology" rather than these ABNF games which "result in subtle
differences and interoperability challenges".  The fundamental problem is
the incompatible redefinition; the name is irrelevant.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 28 Jul 2005 08:47:34 +0200

Bruce Lilly wrote:

>> s/"ab\cd"/"ab.\cd"/
>> so as to illustrate the <dot-atom-text> bug found by Frank
[...]
> local-part (and its non-folded equivalent id-left) does not
> require a dot.  I don't know what "bug" is being referenced,
> could you please provide a URI or message identifier.

This example is unrelated to the "dot-bug" in older versions
of <msg-id-core>.  The "dot-bug" was about a local-part in the
forms 1: "." dot-atom-text OR 2: dot-atom-text "." OR 3:
dot-atom-text ".." dot-atom-text (e.g. <".ab..cd."@example>).

If the example wants to cover it it needs a leading, trailing,
or two adjacent dots (requiring a <quoted-string> local part).

> The fundamental problem is the incompatible redefinition;
> the name is irrelevant.

I believe in _small_ interfaces of independent modules (read
"objects" if you prefer that), because that simplifies later
replacements.  Here the minimal interface is the <msg-id>.

Anything else like <id-left> etc. are "implementation details",
they _should_ be invisible to users of the <msg-id> "module".

Unfortunately they are visible, and we modify them (back to
what they really are in all other standards, especially news).

Therefore our "implementation details" should use different
names, because they really are different from 2822 details.

Our semantics of the RHS is "domain", not "domain or whatever".

We have no "semantically invisible backslash" like RfC 2822.

For some horror scenarios what that could do to news-URIs visit
the uri@w3 list (the thread about tag: URIs and local parts of
addresses).

Therefore we need new names for our different <msg-id> details:

"<" <id-local> "@" <id-domain> ">" with <id-quote> instead of
RfC 2822 <no-fold-quote> etc.  "Minimize the interface" is no
new concept, it's at least 25 years old.

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Jul 2005 15:48:51 GMT

>URI or message identifier.

An <id-left> can be a <dot-atom-text> as in <[email-masked]>.

An <id-left> can also be a <quoted-string> as in <"ab.cd"@example.com>

Since those two would be regarded as different by news-servers, it is
necessary to forbid one of them (the 2nd one in fact).

At one time our syntax failed to do that. It has now been fixed to cover
such cases, and the example has been updated to illustrate the problem (as
well as continuing to illustrate the various other forbidden cases).