Subject: Re: draft-ietf-usefor-usepro-02

From: John Stanley <[email-masked]>
Date: Tue, 14 Dec 2004 13:49:52 -0800 (PST)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>And the only last-ditch possibility left is to include something in the
>body of the message, such as:

>THIS ARTICLE HAS ALREADY PASSED ONCE THROUGH <name of gateway>.

>Which will look pretty ugly to people who see that in the body, but what
>else could be done to prevent the loop?

Unfortunately, this method is also very likely to prevent responses from 
that message to be gated. Once that string appears in the body, it is ripe 
for being quoted. Just as it was quoted in this response. 

You might think that you could simply look for that string at the start of
a line. But the "other medium" might not have the concept of "start of a
line"! Or it might change the lines somehow. Or something else. You cannot
rely on it appearing at the start of a line, or even remaining on one
line. In the same encoding. Or even in the same language.

Then you have to rely on the INCOMING gateway to look for this line and 
take appropriate action. If it does not, it will generate a news message 
with a different message id, which IS a DIFFERENT MESSAGE according to the 
news system. If your gateway treates messages with different message ids 
as the same message, it is broken.

If we are going to talk about gating articles into a horribly broken 
messaging system (one that has no concept of message identifiers), then we 
have to accept that it is broken and isn't our responsibility or within 
our ability to fix. Since it also requires enforcing structure on an 
entirely unstructured message element, it is impossible to accomplish.

If you thought the arguments were harsh when you wanted structure in an 
unstructured subject header, just think what it will be like when group A 
that uses "other medium" realizes that you are trying to enforce structure 
on THEIR messaging system's unstructured components.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 14 Dec 2004 14:03:38 -0800

John Stanley <[email-masked]> writes:

> messaging system (one that has no concept of message identifiers), then
> we have to accept that it is broken and isn't our responsibility or
> within our ability to fix.

Right.

This is what my original text about gatewaying said, long, long ago, so I
don't understand why we're even discussing it.  It's completely outside
the scope of our document to specify how gateways into other media should
deal with the shortcomings of that media.  All we can say is what's
important to Usenet and leave it to the person writing the gateway, or to
a separate specification aimed only at gatewaying.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Dec 2004 11:15:58 GMT

>a separate specification aimed only at gatewaying.

Indeed so. The text in the current draft contains various SHOULD/MUST
[NOT] provisions. It also tries to be helpful by explaining why these
provisions are necessary, and gives a few hints where it is not obvious
how some provision might be implemented (including a rather full example
of one particular gateway). I think it makes it clear that gateway
implementors need to have a thorough understanding of the foibles of the
"other medium", and that there is no "one size fits all" solution.

There is no mention of writing stuff into bodies (so I am not sure how we
came to be dicussing that), except for one suggestion that the news
message-id should be included in a "comment" if there is nowhere else to
put it (though that might turn out to be of more use to human debuggers
that to automated loop detectors).

The whole of this text is little changed from what Russ wrote years ago,
and I see no reason to make any significant change to it now.

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