Subject: Re: To do

From: Frank Ellermann <[email-masked]>
Date: Wed, 02 Feb 2005 09:40:43 +0100

Charles Lindsey wrote:

> should now be fixed

Thanks.

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

Another vote for <unique@mdomain> instead of <id-left@id-right>
if I got this right... ;->  It even says that using IPs is now
(= 1998) obsolete, and it mentions the problem with dynamic IPs.

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 02 Feb 2005 10:26:21 +0100

Charles Lindsey wrote:

> There are examples in RFC 1036 of two <path-delimiter>s
> adjacent, so presumably it was intended to be OK.

I haven't found it looking for "!" or "path:".  If that's
the case it should be good enough for your ...!!... idea.

You snipped my question about IPv6 path identities, how's
that supposed to work ?  RfC 1036 says:

| Letters, digits, periods and hyphens are considered part
| of host names; other punctuation, including blanks, are
| considered separators.

One of the RfC 3513 formats is x:x:x:x:x:x:d.d.d.d, and
that IPv6 is generally not the same as an IPv4 d.d.d.d

> It was all in the old draft-13

That explains why you added ":", but not that it may not work
with the RfC 1036 idea of "punctuation".  We really need that
"THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED" note in
STD 10.

> I am waiting for Ken to move them into USEFOR

Okay, let's wait for usefor-03 and an "official" usepro-02,
I'd like to see the new msg-id and *WSP syntax.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 3 Feb 2005 12:05:41 GMT

>the case it should be good enough for your ...!!... idea.

The example in RFC 1036 is:

	cbosgd!mhuxj!mhuxt
	cbosgd, mhuxj, mhuxt
	@cbosgd.ATT.COM,@mjuxj.ATT.COM,@mhuxt.ATT.COM
	teklabs, zehntel, sri-unix@cca!decvax

There are several examples of ', ' there (SP is a delimiter, and those
examples plus RFC 822, are sufficient to establish that long Path lines
can be folded).

The 3rd line contains two examples of ',@' i.e. two delimiters immediately
together. There is also an example of '@' on its own to confirm that it is a
delimiter. There is also the interesting case of an '@' on its own at the
start of a line. By RFC 1036 standards, that is pretty convincing stuff.

>> It was all in the old draft-13

Our draft makes it clear that ':' is henceforth to be part of the
path-identity and not a delimiter. Hence ap IPv6 address would appear as
...!x:x:x:x:x:x:d.d.d.d!...

If some ancient system misparses that as 7 successive path-identities,
then no harm will arise unless it is itself the system which owns that
IPv6 address, in which case it will fail to recognize itself in the Path,
but then has only itself to blame :-( .

>I'd like to see the new msg-id and *WSP syntax.  Bye, Frank

I doubt Ken will want to adopt the *WSP syntax.

-- 
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: Thu, 3 Feb 2005 12:09:48 GMT

>Another vote for <unique@mdomain> instead of <id-left@id-right>

No, that draft was written over two years vefore RFC 2822 came out, and
before the id-left and id-right stuff had appeared in the DRUMS drafts.

>(= 1998) obsolete, and it mentions the problem with dynamic IPs.

That was its opinion. But there could exist some machine somewhere with an
IP address and no domain-name to go with it. Agreed, the practice should
be deprecated, and RFC 2822 does so (though USEFOR should probably apply a
little reinforcement).

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Feb 2005 11:01:11 +0100

> @cbosgd.ATT.COM,@mjuxj.ATT.COM,@mhuxt.ATT.COM

Thanks, clearly two adjacent delimiters, your ...!!... syntax
should work with 1036-servers.  It's a good compromise between
options 2C and 2D in the "outstanding issues".

> Our draft makes it clear that ':' is henceforth to be part of
> the path-identity and not a delimiter. Hence ap IPv6 address
> would appear as ...!x:x:x:x:x:x:d.d.d.d!...

Okay, maybe add two IPv6 examples and a pointer to RfC 3513.

For BBBB:CCCC:DDDD:EEEE:FFFF:0000:1234:5678 the path identities
...!BBBB:CCCC:DDDD:EEEE:FFFF::1234:5678!... and
...!BBBB:CCCC:DDDD:EEEE:FFFF:0000:18.52.86.120!... are actually
the same, aren't they ?

For implementors these examples make it clear, that something
starting with a letter is not necessarily a FQDN, and that
(apparently) different path identities can be the same IP.

> If some ancient system misparses that

Modern systems also have an excellent chance to get this wrong.

> I doubt Ken will want to adopt the *WSP syntax.

Then he could state his reasons to stick to [FWS] instead of
*WSP here.  Bruce found an interpretation of the [FWS]-syntax,
which is not allowed by an explicit MUST in the text.

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 14 Feb 2005 16:20:54 GMT

>...!BBBB:CCCC:DDDD:EEEE:FFFF:0000:18.52.86.120!... are actually

I don't know. If some site uses sometimes the one and somtimes the other
in the Paths of articles that pass through it, then it has only itself to
blame if it fails to recognise its own articles when they come around
again.

>Modern systems also have an excellent chance to get this wrong.

The only systems where this matters are the ones responsible for ensuring
that articles that have passed through the site with that IPv6 address
don't get sent those articles again. Those sites had better get it right.

>*WSP here.

Indeed he could.

>  Bruce found an interpretation of the [FWS]-syntax,

Can you remind me of what that was?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Feb 2005 22:16:58 +0100

> Can you remind me of what that was?

It was the case "name:" SP CRLF WSP "body" CRLF
with a trailing space in the first line.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 16 Feb 2005 12:20:27 GMT

>with a trailing space in the first line.  Bye, Frank

Sorry, you have still got me lost. I presume "body" in the above was
intended to represent the content of the header.

In draft-ietf-usefor-usefor-02.txt we find:

   o  All agents MUST generate headers so that at least one space
      immediately follows the ':' separating the header name and the
      header contents (for compatibility with deployed software).  News
      agents MAY accept headers which do not contain the required space.
   o  The header contents of every header line (including the first and
      any that are subsequently folded) MUST contain at least one
      non-whitespace character.

That seems to forbid your example.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Feb 2005 19:04:02 +0100

Charles Lindsey wrote:

>| o  The header contents of every header line (including the
>|    first and any that are subsequently folded) MUST contain
>|    at least one non-whitespace character.
 
> That seems to forbid your example.

Yes, that's the point.  The general ABNF for all header fields
has either the form "name:" SP [FWS] "body" [FWS] CRLF or it's
the same pattern with CFWS instead of FWS.

The general 2822-pattern is "name:" [CFWS] "body" [CFWS] CRLF.

Of course Bruce and other readers are misled to believe that
"name:" SP CRLF WSP "body" CRLF is okay, unless they find this
MUST in the text and understand "header content" "first line".

With "name:" SP *WSP "body" *WSP CRLF they would probably see
that it's not the same as in 2822 minus comments,  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 17 Feb 2005 10:20:30 GMT

>MUST in the text and understand "header content" "first line".

Yes, but there are two problems with trying to attack this syntactically.

1. There are some cases for which no feasible syntactic soluition exists,
and so you still need the MUST wording to cover them, in which case Bruce
and other readers will still be misled. In paticular, all the headers from
RFC 2822 or from other mail extensions that we do not use, but can still
turn up in News (and even some that we do use, like Content-*), could not
be covered syntactically in our draft.

2. It is generally undesirable to depart from the RFC 2822 syntax and
conventions except in case of absolute technical necessity.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Feb 2005 08:05:41 +0100

> 1. There are some cases for which no feasible syntactic

Yes, but they are restricted to [CFWS] cases (see below).

> you still need the MUST wording to cover them

Yes, keeping the MUST in the text is okay.  I'm not trying to
replace it by some convoluted syntax.  I only want the draft
to be as clear as possible for readers.  Some of them could be
UA implementors or gateway operators.

> 2. It is generally undesirable to depart from the RFC 2822
> syntax and conventions except in case of absolute technical
> necessity.

A natural compromise is to keep the pattern...

"name:" SP [CFWS} "body" [CFWS] CRLF

...because it corresponds to the very similar 2822 pattern...

"name:" [CFWS] "body" [CFWS] CRLF

...and because 2822 hat its own peculiar "MUST NOT" about empty
lines as a side-effect of folded comments, which is almost the
same idea as in your MUST.

But in the cases where you have [FWS] instead of [CFWS] there's
no excuse to stick to the 2822 syntax pattern.  2822 has no...

"name:" [FWS] "body" [FWS] CRLF

...at all.  Your reasons for the [CFWS]-cases don't work for...

"name:" SP [FWS] "body" [FWS] CRLF

...headers without 2822-counterparts.  The correct pattern...

"name:" SP *WSP "body" *WSP CRLF

...is just better.  And it's no big editorial problem, see my
earlier proposal for the seven (? IIRC) affected [FWS]-headers.

Something completely different, I've just found the new
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-03.txt>

Minus some synchronizations with [ARTICLE] it's almost ready,
isn't it ?  I'd like the two "Alternative-2".

                         Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 04 Feb 2005 09:54:37 +0100

Charles Lindsey wrote:
 
  [<http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt>]

> No, that draft was written over two years vefore RFC 2822
> came out

BTW, the author is also mentioned in chapter 8 of RfC 2822.
 
> there could exist some machine somewhere with an IP address
> and no domain-name to go with it.

Sure, sometimes domain literals are necessary.  And generally
FQDNs are better.  Maybe you hate "domain", because you needed
an argument in your flame-war with Bruce about "case sensitive
Message-IDs", but IMHO that's incorrect / unnecessary:

<unique@example> and <unique@Example> are two Message-IDs of
the same domain.  Bruce mentioned some of your articles in a 
"last call" yesterday (I saw it in ietf.general list):

 <URL:http://www.imc.org/ietf-822/mail-archive/msg04969.html>
| Nobody gives a damn whether an <id-right> is a domain or not

That's not true.  In fact I'd insist on a domain, because it's
an essential part of the concept.  If Bruce really thinks that
<unique@example> and <unique@Example> are the same Message-ID,
then he's wrong.  But the problem is not that the <id-right> is
no domain (incl. domain literals).

Obviously <id-left> and <id-right> were bad choices in RfC 2822
creating a lot of unnecessary confusion (between you and Bruce,
nobody else has this problem), let's use <unique> and <mdomain>
in Usefor.  After all the syntax will be different, that's a
good reason to replace these misleading 2822 terms.

There won't be a problem with the proposed "Domain Name System
(DNS) Case Insensitivity Clarification".  Nobody plans to use
DNS to compare Message-IDs.

                         Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 21 Feb 2005 10:44:05 GMT

>"name:" [FWS] "body" [FWS] CRLF

But it will still be clearer to people familiar with RFC 2822 that this
header is still essentially similar to all the pother usual headers,
except only that FWS is used in place ot CFWS.

>earlier proposal for the seven (? IIRC) affected [FWS]-headers.

If you can convince Ken, then he can put it in. But you have no way
convinced me.

>isn't it ? 

No, there is still a lot to be done.

 I'd like the two "Alternative-2".

Last week IIRC you preferred Alternative-1.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 21 Feb 2005 13:01:49 +0100

Charles Lindsey wrote:

>> 2822 has no...

> But it will still be clearer to people familiar with RFC 2822
> that this header is still essentially similar to all the
> other usual headers

Exactly that's the point, "2822 minus comments plus SP" allows
"name:" SP CRLF WSP "body" CRLF 
as identified by Bruce, but it's illegal in news (usefor-02).

> If you can convince Ken, then he can put it in.

So far that's apparently a fictitious alter-ego of Alexey ;-)

> you have no way convinced me.

You're IMHO a bit paranoid about 2822.  A clear difference is
better than an artificial similarity.  We (tinw) shouldn't try
to smuggle some obscured "features" through a future last call.

Either "name:" SP *WSP "body" *WSP CRLF is what we want, or
it's not.  Maybe that's the real question, and a mandatory FWS
instead of the mandatory SP would be better for news + 2822bis.

> Last week IIRC you preferred Alternative-1.

Last week the alternatives were different:

| 1. A followup is a response, and MUST have a References
|    header. A part of a multi-part FAQ (or anything similar)
|    is not a followup, but it MAY nevertheless have a
|    References header.
| 2. A followup is a response, or a part of a multi-part FAQ
|    (or anything similar). A followup MUST have a References
|    header, and anything else MUST NOT have one.

In the now published protocol-03 you have:

 [Alternative-1.]
| A "followup" is an article containing a response to the
| contents of an earlier article.  
| An article is a "precursor" of some later article which is a
| followup to it, or which is otherwise intended to be grouped
| with it for purposes of display (e.g. as a part of a
| multipart posting such as a FAQ).

 [Alternative-2.]
| A "followup" to an earlier article (its "precursor") is one
| intended to be grouped with that article for purposes of
| display (e.g. because it is a response to its contents or is
| a part of a multipart posting such as a FAQ).

Last week I actually wanted a short statement "a follow-up is
a response and has a References header".  But if you insist on
mentioning a multipart posting, then the new [Alternative-2] is
IMHO fine and minimally better than the new [Alternative-1].

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 21 Feb 2005 11:08:06 GMT

>That's not true.

Yes it is. Once the message-id has been written, how it was contructed is
no longer of any interest. All that matters is that it accompanies the
message without munging and can be matched against other occurrences of
itself that may turn up (e.g. in References headers).

The purpose of putting a domain in there is that it is a very effective
way of helping to ensure that the message-id is globally unique. So
effective, in fact, that RFC 2822 RECOMMENDS that it be done that way (and
we inherit that RECOMMEND).

>  In fact I'd insist on a domain

We do insist on a domain (at least to the extent of that RECOMMENDATION,
which is equivalent to a SHOULD).

>, because it's

Assuming that Bruce meant example.com and Example.Com, then they are
different message-ids evidently derived from the same domain, in
accordance with that RECOMMENDATION.

>Obviously <id-left> and <id-right> were bad choices in RfC 2822

They were perfeclty good choices so far as they went. They could usefully
have made the relationship to domains clearer, and their exact syntax is a
mess as we have now discovered (hence the changes made to it in USEFOR).

>DNS to compare Message-IDs.

Not quite. Nobody has any business extracting any supposed domain from a
message-id and looking it up in the DNS. That is not part of any protocol
(hence the reason why nobody should give any damn). Though it might
occasionally be useful to do so for diagnostic	 purposes (spam chasing,
and so on).

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 21 Feb 2005 19:04:36 +0100

Charles Lindsey wrote:

> Yes it is. Once the message-id has been written, how it was
> contructed is no longer of any interest.

In fact I do not care how somebody else but me constructed a
Message-ID with RHS @xyzzy.claranet.de:  I cancel it, or report
is as abuse, or worse.  With a strong tendency towards "worse"
including all kinds of retaliation I can think of before I cool
down or hell freezes, whatever happens first.

It's "my" RHS as long as claranet.de allows me to use it, and
as long as DENIC allows clara.net to manage claranet.de.

The RfC 2822 "id-right" was a very bad idea.  You need higher
text interpretation skills to find out that they really meant
<unique@mdomain> as it was since Message-IDs were invented in
news or STD 11, but certainly not in 2822.

> The purpose of putting a domain in there is that it is a very
> effective way of helping to ensure that the message-id is
> globally unique.

It's not there as one of many ways to create a name space, it's
THE way to create a name space.  It only offers domain literals
for the rare cases where a domain is unavailable.

 [STD 11]
| msg-id      =  "<" addr-spec ">"      ; Unique message id
[...]
| addr-spec   =  local-part "@" domain  ; global address

 [RfC 1036]
|          <unique@full_domain_name>
| where full_domain_name is the full name of the host at which
| the message entered the network, including a domain that host
| is in

 [s-o-1036]
| message-id  = "<" local-part "@" domain ">"
[...]
| The domain in the message ID SHOULD be the full Internet
| domain name of the posting agent's host.

They all want "domain" whereever possible.  If that's the case
the best way to say so is <unique@mdomain> with the new syntax.

The "<" id-left "@" id-right "> syntax details in 2822 will be
obsoleted by the better Usefor syntax.  The id-right semantics
is what it always was, a domain covering the exceptional case
of a domain literal (aka "domain-ref" in STD 11).

>> Nobody plans to use DNS to compare Message-IDs.

> Not quite. Nobody has any business extracting any supposed
> domain from a message-id and looking it up in the DNS.

That's not what many Usenet users incl. me think how it works.
It's also not what STD 11, 1036, and s-o-1036 clearly say.

If some dork abuses "my" name space @xyzzy.claranet.de then I
do not care whether the LHS algorithm is different from my UA,
which could be good enough for your interpretation.  It's not
for "my" interpretation.
                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 22 Feb 2005 11:55:57 GMT

>as identified by Bruce, but it's illegal in news (usefor-02).

And "2822 with comments plus SP" also allows "name:" SP CRLF WSP "body" CRLF.

Whether it is [CFWS] or [FWS] at the beginning of some rule makes not a
blind bit of difference to that problem. Either way needs the extra
wording to forbid the illegal cases (both in email and news). So you gain
nothing by trying to fix one syntactically without fixing the other. What
you do do is to tempt the reader to thoink that there is some extra magic
going on, beyond the fact that all you have done id to forbid comments in
one of the cases.

>You're IMHO a bit paranoid about 2822.

No, I am just following the directions I have been given from the Chair to
follow RFC 2822, both in content and style, unless there is a technical
reason not to do so.

>In the now published protocol-03 you have:

But that is only half the text. When you see the other half of the text
that will go in the next Usefor under the semantics of the References
header, you will see that it is the same. The wording I gave last week was
but a short summary of the situation, not a wording that would stand up in
an official document.

But the other half of the text is waiting for somebody's alter ego, or
whatever :-( .

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 22 Feb 2005 12:10:12 GMT

>for the rare cases where a domain is unavailable.

Not quite. It is the RECOMMENDED (RFC 2119) way to create a name space. It
is not absolutely forbidden to put other unique texts in there, but you
better have a good reason.

>the best way to say so is <unique@mdomain> with the new syntax.

And [RFC 2822] also, but it chose different names for the syntax items. We
are supposed to be following RFC 2822.

>of a domain literal (aka "domain-ref" in STD 11).

I hope (but have no way of guaranteeing) that RFC 2822 bis will fix up
<msg-id>s to eliminate the problems we have found. But I don't expect it to
cease using the terms <id-left> and <id-right>.

>It's also not what STD 11, 1036, and s-o-1036 clearly say.

Eh? What protocol instructs you to take a domain out of a message-id and
to look it up in the DNS? Certainly not STD 11, 1036, or s-o-1036.

>which could be good enough for your interpretation.  It's not

You have every right to be annoyed if some dork uses
<[email-masked]> in his Message-ID. But I doubt you would
succeed in getting him thrown off by his ISP in the same way as if he had
used that domain in his From, Sender or Approved header, or in the
envelope FROM of some email.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Feb 2005 18:11:13 +0100

Charles Lindsey wrote:

> It is not absolutely forbidden to put other unique texts in
> there, but you better have a good reason.

The essential point is that you MUST NOT use @xyzzy.claranet.de
in your message IDs without the permission of claranet,de

If you use a domain literal, some AlterNIC domain, a s-o-1036
.uucp or .bitnet "domain", then that's your problem, but it's
still meant to be a "domain" in some way.

>> [s-o-1036]

Exactly.  Even RfC 2822 explains that the RHS of a Message-ID
is essentially the same as the RHS of an address, a "domain"
minus CFWS and other syntax oddities allowed in addresses.

> but it chose different names for the syntax items. We are
> supposed to be following RFC 2822.

We're not supposed to use the same name "id-right" where the
syntax is different, and the semantics is "domain".  There's
not one string "2822" on the Web page with the UseFor charter.

The UseFor charter mentions RfC 822, RfC 1036, and s-o-1036.
These texts all manage to say "domain" if they mean "domain".

> I hope (but have no way of guaranteeing) that RFC 2822 bis
> will fix up <msg-id>s to eliminate the problems we have
> found. But I don't expect it to cease using the terms
> <id-left> and <id-right>.

If the future authors read old threads here, and survive the
following psychological research because they didn't commit net
suicide like all other readers, they'll copy the UseFor syntax
as is.  It's important to get at least the Message-ID right.

> What protocol instructs you to take a domain out of a
> message-id

Protocols, where articles with <[email-masked]> are
not propagated, because somebody else abused it before me.  Or
where articles written by me are replaced in a public archive,
because somebody else abused the same Message-IDs much later.
Or cancel messages for my Message-IDs by 3rd parties.

That's net abuse, like forged From addresses.  I can judge this
if it's "my" domain, and others can verify it by contacting the
owner of this domain.

> I doubt you would succeed in getting him thrown off by his
> ISP in the same way as if he had used that domain in his
> From, Sender or Approved header, or in the envelope FROM of
> some email.

So far the worst with "my" domain was a broken cancel-bot, and
while he wasn't shot, his provider, the relevant Tech-C, the
Admin-C, and some other interested parties all "helped" him to
fix his cancel-bot a.s.a.p.  Then they fixed their systems as
far as I found reasons to have them listed as "RfC-ignorants",
and while nobody said it explicitly I'm sure that we're now all
trying to avoid any similar situation.

                            Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Feb 2005 18:57:41 +0100

Charles Lindsey wrote:

> Whether it is [CFWS] or [FWS] at the beginning of some rule
> makes not a blind bit of difference to that problem.

Whether it is [CFWS] or *WSP at the beginning of some rule
makes a difference to that problem.  The latter is correct,
and RfC 2822 has neither [FWS] nor *WSP in that place.

You also won't say "poster" because it includes the correct
poster-text, you say [FWS] %d112.111.115.116.101.114 [FWS].

This excludes some incorrect forms like "PoStEr", but still
allows an incorrect CRLF WSP "poster" CRLF WSP.  To get this
always right you need *WSP %d112.111.115.116.101.114 *WSP

Anything else is an erroneous syntax for poster-text.

> What you do do is to tempt the reader to thoink that there
> is some extra magic going on

I don't see extra magic in *WSP %d112.111.115.116.101.114 *WSP

It covers exactly all correct forms of a poster-text.  Unlike
[FWS] %d112.111.115.116.101.114 [FWS], or [FWS] "poster" [FWS],
or *WSP "poster" *WSP, which include some incorrect forms.

> I am just following the directions I have been given from the
> Chair to follow RFC 2822, both in content and style, unless
> there is a technical reason not to do so.

JFTR, where and when did Alexey say that an erroneous syntax
in the "style" of RfC 2822 is better than the correct syntax ?

IIRC he had "FWS" as one of the issues outstanding.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 23 Feb 2005 13:45:39 GMT

>in your message IDs without the permission of claranet,de

There is no such MUST NOT in RFC 2822, nor in Usefor, nor is there any
proposal to make it so. I agree is is bad practice, and maybe even a
SHOULD NOT.

>still meant to be a "domain" in some way.

"Meant" is not a term with any well defined meaning. "RECOMMENDED", which
is the actual term used in RFC 2822, is defined in RFC 2119.

>not one string "2822" on the Web page with the UseFor charter.

We are not using "domain" for the same reason that RFC 2822 did not use
"domain". We are perfectly entitled to say that, for the purpose of
Usefor, we define "id-right" to be different, so that the difference
automatically applies to all places in RFC 2822 where "id-right" was used.
Exactly the same as we did for "unstructured".

>These texts all manage to say "domain" if they mean "domain".

RFC 2822 did not exist at the time that charter was written, or at the
time that RfC 1036 and s-o-1036 were written (otherwise those documents
would certainly have been written differently). The present instructions
from our Chair are that Usefor is to be written by taking everything in
RFC 2822 that is relevant, and only mentioning the things that have
changed. You or I may not like that, but that is the contraint under which
we are working. If you don't like it, complain to the Chair, not to me.

>not propagated, because somebody else abused it before me.

That does not apply if the person who misuses your domain takes care to
use a different <unique> from what you use, or are likely to use. He would
indeed be in breach of Usefor/RFC2822 if he did not. But even such a
misuse does not amount to a protocol which involves extracting a domain
out of a message-id and looking it up in the DNS, which is what you
postulated and which I asked you to substantiate.

>fix his cancel-bot a.s.a.p.

Actually, the normal practice amongst the 'professional' spam cancellers
is for the Message-ID of the cancel message to be <cancel-unique@domain>
where <unique@domain> was the Message-ID of the cancelled message. This is
known as the $alz convention, and it is to ensure that cancels for the
same article issued by different cancellers do not propagate in
competition with each other.

It is, come to think of it, an excellent example of a situation in which
it is perfectly reasonable and correct to violate a SHOULD/RECOMMENDED.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 23 Feb 2005 13:58:01 GMT

>Anything else is an erroneous syntax for poster-text.

It is no more erroneous for "poster" than it is for the many other places
where CFWS of FWS occurs in at the beginning, middle or end of some rule.
All such cases are already covered (and forbidden) by the special wording
provided for the purpose, both in RFC 2822 and in USEFOR. Since it is
already forbidden, nothing is gained by forbidding it again. Indeed,
specifying the same think normatively more than once is generally
considered bad practice, since it may lead to unintended and unexpected
consequences.

>in the "style" of RfC 2822 is better than the correct syntax ?

There is nothng "erroneous" about the way RFC 2822 handles this matter (or
its slightly different version of this matter). Therefore there is
nothing "erroneous" for us to handle it in the same way.

>IIRC he had "FWS" as one of the issues outstanding.  Bye, Frank

He agreed that it could be discussed. We are discussing it. I hear nothing
like a consensus, nor even a majority, for changing it.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 23 Feb 2005 20:54:05 +0100

Charles Lindsey wrote:

 [FWS] %d112.111.115.116.101.114 [FWS]
> It is no more erroneous for "poster" than it is for the many
> other places where CFWS of FWS occurs in at the beginning,
> middle or end of some rule.

I didn't know that there are different degrees of erroneousness
in RfCs.  Apparently "poster" would be too erroneous, and that
forces you to say %d112.111.115.116.101.114 in the ABNF.

OTOH [FWS] belongs to the "less erroneous" class, and it's even
"better" than a correct *WSP, where the definition of "better"
is apparently unrelated to "complete number of ABNF characters".

> specifying the same think normatively more than once is
> generally considered bad practice, since it may lead to
> unintended and unexpected consequences

If RfC 2234 somewhere says that the "best common practice" are
vague ABNF syntax rules for all details specified elsewhere,
then I didn't know this.  Maybe you should delete...

| Although the keyword "poster" is case-sensitive, followup
| agents MAY choose to recognize case-insensitive forms such
| as "Poster".

...to avoid any "unintended and unexpected consequences" of
this over-specification.  Or say "poster" and add an explicit
"SHOULD be lower case" in the text.  It's a real challenge if
you insist on an ABNF which does not exactly reflect the text.

> There is nothng "erroneous" about the way RFC 2822 handles
> this matter

I'm not talking about RfC 2822 and how they solved their [CFWS]
problem with a MUST NOT.  It's different from the [FWS] problem
in the Usefor text, where clear, correct, simple, and obvious
solutions exist.  I'm a KISS extremist, and I hate vague ABNF
syntax allowing trivially invalid cases.  If Bruce did not see
it immediately we have a huge chance that many implementors and
many gateways get it wrong.

> I hear nothing like a consensus, nor even a majority, for
> changing it.

The consensus is that all odd numbers are prime, because that's
the way to avoid MicroSoft's new "nine IsNot prime" pat. pend.
<http://tinyurl.com/6d4wf>
                             Bye. Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 23 Feb 2005 23:58:05 +0100

Charles Lindsey wrote:

>> you MUST NOT use @xyzzy.claranet.de in your message IDs
>> without the permission of claranet,de

> There is no such MUST NOT in RFC 2822, nor in Usefor, nor is
> there any proposal to make it so.

It's unnecessary in all cases where it's clear that the RHS of
an address or Message-ID is a "domain" as specified in the
_relevant_ texts incl. domain literals and other creatures like
the SHOULD NOT hostname.uucp in 1036bis.

I would propose to add an explicit MUST NOT to anything which
isn't obviously a kind of "domain" as in the _relevant_ texts,
i.e. in STD 11, RfC 1036, and 1036bis.

> I agree is is bad practice, and maybe even a SHOULD NOT.

It's not only "bad practice", it's several pages of "security
considerations" if you keep the misleading name "id-right".
With all the fun-stuff like hip-crime and preemptive cancels.

> We are not using "domain" for the same reason that RFC 2822
> did not use "domain".

2822 split the old "domain" of STD 11 into a new "domain" for
the RHS of addresses, and a more restricted variant "id-right"
for Message-IDs.  The authors of 1036 and s-o-1036 had no time
machine allowing them to foresee this confusion, they simply
said "full_domain_name" and "domain" resp.

We don't need a time machine to see why "id-right" was a poor
choice, we have several dozens of messages here.  You have a
correct syntax for this beast, it's different from 2822, you
know the intended semantics, it's the same as in the _relevant_
texts, all you need is a good name to reflect this situation.

<id-left@id-right> is not good enough to reflect the complete
intended semantics, the _relevant_ texts did a better job.

> We are perfectly entitled to say that, for the purpose of
> Usefor, we define "id-right" to be different, so that the
> difference automatically applies to all places in RFC 2822
> where "id-right" was used.

You're planning to use that trick for the complete msg-id, you
don't need it again and again for all details.  RfC 2822 uses
the word "id-right" exactly twice:  In its definition, and for
"msg-id".  Same picture for the word "id-left".  Looking for
strings instead of words I get three additional 2822 lines incl.

| obs-id-left     =       local-part
| obs-id-right    =       domain

"id-left" and "id-right" were just poor choices, and there's no
reason to keep them in the new "real" msg-id defined by UseFor.
Just pick one:
  msg-id = "<" id-local "@" id-domain ">"
  msg-id = "<" msg-local "@" msg-domain ">"
  msg-id = "<" unique "@" mdomain ">"

The msg-* stuff is somehow in the spirit of similar names in
the UseFor drafts and 2822.

> RFC 2822 did not exist at the time that charter was written,
> or at the time that RfC 1036 and s-o-1036 were written

Then please stop to abuse it as an excuse for vague syntax like
[FWS] instead of *WSP, or for unclear semantics like "id-right"
instead of "msg-domain".

> The present instructions from our Chair are that Usefor is to
> be written by taking everything in RFC 2822 that is relevant,
> and only mentioning the things that have changed.

I call bullshit.  Alexey didn't say that you must take the "["
and the "FWS]" out of a 2822 "[CFWS]" if you really mean *WSP.

And the "msg-domain" syntax is different from "id-right", like
"msg-local" is different from "id-left".  It's a proper subset
with completely new rules to catch the must-quote cases, to get
rid of NO-WS-CTL, and with a total length limit not found in
RfC 2822.  This is a new "msg-id" justifying new names for its
LHS and RHS.  OTOH it's still the same <msg-local@msg-domain>
concept as it always was, before and after RfC 2822.

> If you don't like it, complain to the Chair, not to me.

"Hi Alexey, the UsePro editor wants me to complain about some
 bad names for syntax rules in a future UseFor draft I haven't
 seen written by an unknown stranger claiming that this is all
 your fault."

Is that a play by Kafka, and if yes, why does nobody pay us ?

>> Protocols, where articles with <[email-masked]>
>> are not propagated, because somebody else abused it before
>> me.

> That does not apply if the person who misuses your domain
> takes care to use a different <unique> from what you use, or
> are likely to use.

Unless s/h/it's clairvoyant s/h/it cannot judge this.  What I
"likely" use or don't use is strictly my business.  Some days
ago I used <421788F9.66E8?isindex=[email-masked]> -
see also <URL:http://article.gmane.org/gmane.test:2092:raw> or
<news://news.gmane.org/[email-masked]>

It was a test for your news-URI draft.  I only discuss it with
you and interested parties, but not with clairvoyant strangers.

Maybe I change my UA, I have slrn and Netscape 4.61 on my box.
Maybe I hack an article with telnet -p 119.  Nobody else has my
permission to create any @xyzzy.claranet.de Message-ID.

> He would indeed be in breach of Usefor/RFC2822 if he did not.
> But even such a misuse does not amount to a protocol which
> involves extracting a domain out of a message-id and looking
> it up in the DNS, which is what you postulated

I postulated that you can contact the owner of a domain found
in the RHS of addresses or Message-IDs, if different entities
disagree who is entitled to use this domain.  You might need a
nslookup -q=ns xyzzy.claranet.de to get rid of the vanity host,
or a nslookup -q=mx claranet.de, or something similar.  And if
you're feeling lucky ask [email-masked] who has the
right to use @xyzzy.claranet.de, maybe I'll answer it.

Same idea as for a forged From: address in a cancel message,
the owner of this address is defined to be the person who gets
any questions sent to this address.

> normal practice amongst the 'professional' spam cancellers
..........^^^^^^.^^^^^^ See ?

Yes, he followed all cancel conventions, it only was no spam.
The Skirvin-FAQ says that you have ONE chance to get it right.

                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 24 Feb 2005 15:23:33 GMT

> seen written by an unknown stranger claiming that this is all

Well, actually the "bad names" that you do not like are already in the
present Usefor draft, so there is no need to wait for a future Usefor
draft.

Anyay, you have asked the Chair. I suggest we halt discussion of this
issue until he has responded.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Feb 2005 09:41:32 +0100

Charles Lindsey wrote:

> Anyay, you have asked the Chair. I suggest we halt discussion
> of this issue until he has responded.

LOL, I hope that Alexey can handle our slightly different forms
of humour.  We should certainly halt the discussion until a new
draft is published, there are only so many ways to repeat the
same arguments again and again.

But I forgot one important argument so far:  "My" vanity host
is also a catch-all mailbox.  I'm used to get spam to very old
Message-IDs like <[email-masked]>, but I won't
tolerate it if anybody else publishs other @xyzzy.claranet.de
Message-IDs where stupid address harvesters could find them.
My RHS is my RHS even in a Message-ID.

                           Bye, Frank