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

From: John Stanley <[email-masked]>
Date: Fri, 10 Dec 2004 11:52:58 -0800 (PST)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>No, it implies no such thing. Agents may or may not be able to detect
>validity/invalidity of various classes of address, as Seth has pointed
>out. The "MAY" permits them to make use of such information as they may
>have available.

Since they do not have the information that says "your address is invalid" 
in the general case, there is no use to be made of that "information". 
Pretending they CAN know this is the problem. 

>Consequently, people who use invalid addresses may well
>find their articles rejected. Or not.

Consequently, people who use perfectly valid addresses may well find their
articles rejected, because we've told server admins they can pretend to
know if they are valid or not.

If you don't know it is invalid, you ought to do nothing about it. Knowing 
it is invalid takes more than saying "you must use an example.com email
address".

>>Excuse me? Nothing else can exist that can do the same thing? Sorry, but
>>you are patently wrong.

>No, there is nothing else that will nearly always work on Usenet as it
>presently exists.

Well, DOH! But that is not an excuse for preventing it from being created.
There is no reason to demand in the standard that "by email" be the only
method of sending articles to the moderator. If that is the only current 
implementation, that's one thing, but to close out any other 
implementation is just ridiculous.

>Other mechanisms may be used in small cooperating subnets, but until they
>become commonplace we have no way of standardizing them.

I'm sorry, but in another section of the draft you try to "standardize" 
the "exceptional" cases of reinjection. Which is it? Something must be 
commonplace before it can be standardized, or standards can be written to 
allow exceptional cases?

>>>So if the Injection-Date is earlier than the expiry date
>>>(however computed) that it implements (probably of a per group basis), 
>>>then it MUST drop it.

>>I asked once, and I expected an answer. Why is this a MUST? Expiration 
>>policy is the site's responsibility, not ours. 

>This is nothing to do with controlling the expiration dates of sites. It
>is a matter of preventing loops, for which purpose that MUST is essential.

I see nothing in that statement about "loops", and everything about 
"expiry date". 

>... both Frank and Seth seem to he saying that it is about
>right as I currently have it. 

So? They are wrong, if that is what they are saying. It is
self-contradictory if we tell people in one place that they may do
something and then not tell the admins in another place that they need to
allow it. It would be like allowing the followup agent to create message
ids of the form "<something.somethingelse.but.no.at.sign>" and then
telling injecting agents that they don't have to accept them.

>I.e. we encourage people to use ".invalid",

No, we tell them explicitely they may use it. There is a difference.

>I agree that the
>way it is currently worded seems to be pulling two ways at once and will
>probably need to be changed. But I need guidance as to which direction to
>change it in.

Well, that's what I've been giving you. 

>>There is no reason to redefine a standard english word when there is 
>>already a standard english word that conveys the correct meaning.

>"Take" is also a standard english word, and conveys the intended meaning
>in this case. 

No, it does not. "Take" means that something is removed from one place and
moved to another. "Take" is how SBC convinced the courts to levy such
harsh consequences against those people who "took" copies of telco
documents. It is only after you redefine "take" to mean "copy" that "take"
comes even close to the correct meaning. And yet, "copy" already has that
meaning. There is no reason to redefine "take" so it means "copy"; just
use "copy".

>I do not see your problem with it. Does anyone else?

And yet, the draft used to say "copy", before you decided unilaterally to 
change it.

>>Nonsense. We tell it what it must use. We do NOT tell the user what he 
>>uses. Since there is only ONE thing that the followup agent is allowed to 
>>do ("copy the content") that is the default. There is no other default.

>There are TWO things the followup agent can do. One is to accept (without
>demur) what the user types in. 

The user has typed NOTHING in at the point in question. We are telling it 
what it must do when it prepares the article for user action. There is 
only ONE THING that it does -- and that means that ONE action is the 
default. Saying that it must, by default, do the only thing we tell it it 
can do is just silly. 

>>You want to trim the one in the followup. "If the resulting 
>>References-header is excessively long, it may be trimmed by removing 
>>message identifiers other than the first and the last."

>But OK, I will buy that, except that it has to be the "last two" (i.e. you
>MUST keep the last one from the precursor).

Why? What breaks if the parent of the precursor is no longer threaded? 
Justify the MUST.

>The only limitations are those imposed by the lack of appropriate
>facilities in the reading agent. The whole point of the wording is to
>indicate that the poster cannot assume that every reading agent will be
>able to make sense of everything, however bizarre, that he might choose to
>put in the article.

Then say that. But that's so obvious that I don't think it needs to be 
said. That whole section about "reading agent" is a definition seeking a 
purpose. And the title implies that a reading agent HAS some duties, which 
it does not. There is nothing we can say about what a reading agent MUST 
or SHOULD do, since we already acknowledge that "reading agent" doesn't 
even necessarily display anything to anyone. 

The only place we need to mention "reading agent" is in the definitions, 
and then we can say:

	A "reading agent" downloads articles from a serving agent for 
	reading or other processing outside the news system. 

>Neither sentence is meaningless. Does either of them say anything that is
>untrue?					

Do you understand the difference between "meaningless" and "untrue"? If 
the only justification for putting things in the draft is that they be 
true, then we ought to be saying things like "the euro is the current 
monetary standard of the EU" and "upwelling on the Oregon Coast is 
responsible for the vast nature of abundant sea life found there.".

>>We already cover the possibility of loops, so there is no need for this 
>>paragraph at all.

>There are various ways in which loops can arise. It is necessary to draw
>attention to them.

We already draw attention to them, in the previous section where it is 
stated as "the primary dictat": Above all, prevent loops.

The only content to the entire first paragraph of that section is to say:
loops are possible, please prevent them. We've already said that. There is 
no need for the entire paragraph. It adds no meaning to the draft, so 
while it may be completely true, it is also completely meaningless. But it 
is wrong in that it says that the limits are due to the PRESENCE of 
another incoming gateway, and that is not true. The operation MUST 
consider the POSSIBILITY of an incoming gateway, not just the PRESENCE of 
one.

So, to solve the problem, and make things shorter (something you like to 
do), remove it. One paragraph shorter.

>>It is unlikely that an outgoing gateway is going to see an incoming 
>>message.

>On the contrary, that is just the kind of loop we are trying to catch.

That kind of loop is easy to catch: simply do not allow an outgoing 
gateway to accept incoming messages. Problem solved. In fact, I doubt 
there are many outgoing gateways that do accept incoming messages. I know 
the ones I have written do not. There is, in fact, no way to SEND an 
incoming message to my outgoing gateway. 

In fact, if a gateway accepts INCOMING messages, then it is an INCOMING 
gateway, and is dealt with elsewhere.

>If
>the article is gatewayed to the "other medium" and there exists some other
>gateway elsewhere that puts it back into Netnews, then the flooding
>algorithm is very likely indeed to bring it back to the first gateway.

You mean like how I mentioned in the very next sentence? 

>>However, if you meant that the same outgoing gateway is going to 
>>see the same message outgoing more than once, then it already has the 
>>mandatory message id (not in the body) to work with.

>There might not be such a thing as a message id in the other medium. 

There is a MANDATORY message id in news. An outgoing gateway takes NEWS 
articles and sends them to the other medium. If you think an outgoing 
gateway author is going to throw the message id away prior to checking for 
dupes just because the "other medium" doesn't understand message ids, then 
you are being foolish.

>> A comment in the body 
>>of a messsage is not likely to prevent loops. Saying it does is silly.

>No. If the gateway to the "other medium" (which presumably understands the
>rules for contructing messages in the other medium) can manage to insert
>some distinct identifier into whatever passes for a body in the other
>medium, then it is quite capable (and indeed it is the only agent in the
>whole world with that capability) of recognizing the identifier that it
>itself placed there, should it ever come back again. 

So you expect outgoing gateways to parse the BODIES of the messages it 
converts looking for things that look like something it understands? Well 
now, that's a serious requirement. But since the content of the body is 
UNSTRUCTURED, you've got a long row to hoe defining structure of headers 
in the body. But before you can claim that a comment in the body of a 
message (in some other medium than news, to boot) is likely to prevent 
loops, you need that structure.

>It is nowhere stated that a separate injecting agent is involved in an
>incoming gateway. 

Nowhere is it stated that it is not.

>If there is, then it can be relied on to do the checks.

Not when we tell the gateway author that the gateway author that the 
articles the gateway forms must follow all the standards. 

>>It takes a bit of thought there to realize that a duplicated message id is 
>>an illegal content for the message id header. And most injecting agents 
>>do, indeed, reject duplicates.

>How?

By trying to inject it and getting a rejection, because the duplicate ID 
is already in the history. 

>And if it is the same message come round again, then it is not even
>illegal to have the same message id.

So this discussion about MUST generate unique ids is frivolous?

>>>I would suggest checking for and noting the presence of the cancel message
>>>_before_ removing it.

>>There is no cancel message before removing it. I am told I must remove it 
>>before I can inject it.

>Eh?

I have an incoming gateway for group X. User Y sends a message to the 
gateway containing the header "Control: cancel <[email-masked]>". My 
gateway is told I MUST NOT pass that message without removing or renaming 
that header. On the other hand, since I can determine that this is a valid
cancel message, I can create a cancel message of my own. How? By passing
the message WITH the control header. 

I MUST NOT pass the message, but I SHOULD pass it.

Now, YOU told me that I was supposed to look for a cancel message before I
remove the header. I ask my server for that message and, not surprisingly,
since I have not yet posted one, it does not yet exist. So how does this 
help the problem? If the cancel message already existed, yes, I'm out of 
the woods, I don't have to process the incoming message. But since it does 
not, and I MUST NOT/SHOULD process it, I'm stuck.

>If an article with a Supersedes header arrives at an outgoing gateway,

So what? We're talking about duties of an INCOMING gateway here.

>The word "poster" is in widespread usage throughout usenet and does not
>seem to cause any real problems out there, 

The word "log in" is in widespread usage on the web, even for sites that 
have no login/password function. It has not seem to cause any real 
problems in that usage, but it is still completely incorrect.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Dec 2004 16:55:22 GMT

In <[email-masked]> John Stanley <[email-masked]> writes:

Will the rest of the Working Group please tell me whether it wants me to
continue to reply in detail to John's long rants, given that he keeps
repeating the same complaints ad nauseam, he deliberately
misreads/misunderstands what is said to him (or else he is even stupider
than I thought), and jumbles up unrelated topics so that it is hard to
spot what he is talking about at any given moment.

I have replied fully to this one, but I see little point in continuing to
do so in the future.

>Pretending they CAN know this is the problem. 

As usual, you fail to distinguish between what some particular agents are
able to do, and what agents in general are able to do. SOME agents may be
able to determine (or think they are able) that an address is "invalid",
in which case they MAY choose to reject. It nowhere says that ALL agents
are able to make that determination, which inevitably means that there
will exist SOME agents that are unable to take advantage of that "MAY". So
what?

>know if they are valid or not.

We have told server admins no such thing.

For those who are confused by John's snipping, the discussion has suddenly
moved on to communication with moderators. ...

>implementation is just ridiculous.

That is the only implementation currently deployed on Usenet. You
yourself agreed that other arrangements would only be available on Private
networks. A Private network is, by definition, a "cooperating subnet"
which is, by definition, permitted to use additional protocols not defined
by the standard. Such additional protocols may, at some future date,
become defined as extensions to the standard; but for the moment the only
universally accepted way on Usenet to send articles to a moderator is by
email, and no alternative mechanism is on the table; that is therefore
what we are going to standardize.

>the "exceptional" cases of reinjection.

That is because there was some small existing usage of reinjection,
because there were good reasons why it should happen in a small number of
situations, and because we discussed it and concluded that the possibility
should be mentioned (because there needed to be some restrictions on
exactly how it was done). None of those preconditions applies in the case
of novel methods of communicating with moderators.

Now we have switched to Injection-Date. ...

>I see nothing in that statement about "loops", and everything about 

The word "expiry" does not appear in the text under discussion. That text
was an agreed part of the protocol as discussed when we introduced the
Injection-Date header, and before we added that header it was an agreed
part of the protocol applying to the Date header.

Note that the critical date for a site is that of "the earliest articles of
which it normally keeps record", which will usually be earlier than that
of the earliest expired article, since it is usual to keep message-ids in
the history file for a further period even after those articles have been
expired. So if an article arrives with an even earlier Injection-Date than
that, then it MUST be dropped.

Now we are back on ".invalid" again. ...

>Well, that's what I've been giving you. 

And other people have been giving different guidance.

Now we have switched to "take". ...

>moved to another.

Take v.t. to lay hold of; to get into one's possession: to seize: to
catch: to capture: to captivate: to receive or come to have willngly or by
an act of one's own; to appropriate: to assume, adopt: to accept: to
receive: to admit: to submerge (scot.): to have normally assigned to one:
to find out, come upon, surprise, detect: to swallow or inhale: to apply
to oneself: to obtain: to engage, secure: to seek and receive: to have
recourse to: to attend a course in: to visit: to call for, necessitate,
use up: to remove: to cause to go: to subtract: to convey: to escort: to
detract: to derive: to understand: to apprehend: to assume, suppose: to
mistake: to conceive: to accept as true: to tolerate: to ascertain: to
observe or measure: to ascertain something from: to execute, perform: to
set down: to portray: to photograph: to charge oneself with: to
asseverate: to strike: to come upon and affect: to bewitch: to blight: to
deliver, give (obs.): to betake - and then there are the intransitive
forms ...

A very versatile word, as you can see. To determine its meaning in any
given case, you have to examine its context. Fortunately, in this case,
the context is clear, because I have given an explicit definition of the
term.  I think, of the bunch listed above, "to ascertain something from"
fits my defined meaning best.

Switching now to followup agents. ...

>default. Saying that it must, by default, do the only thing we tell it it 

A followup agent is, by definition, a special case of a posting agent, so
its duties are not complete until it has handed over the final text to an
injecting agent. Therefore, its duties include accepting text from the
user and using it in place of whatever default it might otherwise have
used. Our draft carefully defines the allowed defaults and, in the
circumstances "default" is a perfectly proper word to use.

And now References. ...

>Why? What breaks if the parent of the precursor is no longer threaded? 

The original text said "... but the first and last message identifiers
from the precursor MUST NOT be removed". So if the precursor had:

References: <A> <B> <C>
Message-ID: <D>

then the followup article will have

References: <A> <B> <C> <D>
Message-ID: <E>

The original wording allowed the trimming of <B>, but not of <A> or <C>.
The new wording allows precisely the same. You asked me for a change of
wording, not for a change of meaning, so that is what I did.

If somebody wants a change of meaning, then that is a separate issue, to
be discussed. However, allowing both <B> and <C> to be trimmed away might
well cause threading with the earlier articles to fail if the precursor
had failed to be delivered. Consider the case where <C> and <E> are
available, bur <D> is missing, for example.

There was a time when our draft suggested keeping at least 20, plus the
first one (and USEAGE still says that, although some recent experiences
with excessively long References breaching the 998 limit makes me think 20
is too large). So I could easily be persuaded that keep "last two" should
actually be increased to, maybe, "last three".

Now we are at Duties of a Reading Agent. ...

>purpose.

Maybe so, but that is a separate issue for separate discussion (there
exist some people wanting to keep the whole section and some to remove
it).

But what you asked me to do, and which I did do, was to weaken the
over-strong wording thjat was originally present. You said nothing then
about removing the whole section.

Now you have suddenly switched to gateways. ...

>while it may be completely true, it is also completely meaningless.

That text was originally written by Russ. You have to persuade him if you
want it taken out.

> But it 

You have already said that, and I have already changed it at your request.
Why are you still complaining? It now says (as I have posted previously):

7.9.1.  Duties of an Outgoing Gateway

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent. The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated. The operation of the outgoing gateway
   is subject to additional constraints due to the possibility of one or
   more corresponding incoming gateways back from that medium to
   Netnews, since this opens the possibility of loops.

>gateway to accept incoming messages.

Since the whole purpose of the outgoing gateway (which is presumably
attached to some serving agent) is normally to gateway the whole of some
newsgroup to the "other medium", then if it (or rather its serving agent)
never receives any messages it will never gateway anything. Normally,
these will be messages that have arrived via other relaying agents in the
normal manner (and that includes the ones which might turn out to be parts
of loops).

> Problem solved. In fact, I doubt 

So your outgoing gateway never has any messages to process at all then?
Why did you go to all that trouble to write it?

>gateway, and is dealt with elsewhere.

NO! Incoming messages don't just come from incoming gateways. They arrive
by the usual Usenet relaying mechanisms. Consider the following setup:

In Usenet:

    Site A ---> Site B ---> Site C ---> Site D --->
                  ^                       |
                  |                       |
                  | inGate                | outGate
In the other      |                       |
medium:           |                       |
                  |                       |
    Site E <--- Site F <--- Site G <--- Site H <---

>There is a MANDATORY message id in news.

There is no MANDATORY message id in the other medium. Maybe even no
message-id concept at all.

>An outgoing gateway takes NEWS 

Then what do YOU want outGate to do with the News message-id? And how can
you be sure that, wherever you hide it, inGate will subsequently put it
back in the News message-id before handing it over to Site B? You have to
allow for the possibility that the 2nd time outGate sees the message it
will have a different message-id.

>converts looking for things that look like something it understands?

Yes, if it can't find a better way to do it (which hopefully it can).

> Well 

But fortunately inGate is in a position to invent the little bit of
structure that it needs.

>Nowhere is it stated that it is not.

True. So what?

>articles the gateway forms must follow all the standards.

Why ever not? It has the responsibility of causing the necessary checks to
be done. It has a choice. Either it does them itself, or it ensures that
the injecting agent it hands off to will do it. What is so wrong with
that? It is not our job to tell implementors how to do it - just to tell
them that it must be done somehow.

>is already in the history. 

Injecting agents don't keep histories. With a bit of luck their friendly
neighbourhopod serving agent will keep one and silently reject it.

But that is no use if the message-id got changed to a different message-id
within the other medium.

>the message WITH the control header. 

You are postulating another medium whose cancel messages are in the same
format as Netnews cancel messages. I agree that a typical mail2news
gateway has this property.

Yes, if you follow the draft, you notice two things:

1. The incoming message is a cancel message, so you generate an equivalent
(brand new) News cancel message.

2. The incoming message contains a Control-header, so you remove it before
you pass it on (so you have now inserted two messages into the News
system). OTOH, in the case of a pure cancel message there is little point
in passing on the emasculated message (which is why I used a message with
a Supersedes header in my example) so maybe you just drop it.

And yes, in this very particular case of a mail2news gateway there is an
obvious optimization just to let it through. But strictly speaking that is
wrong. When Russ wrote this, he concluded that letting Control messages
through as received was a Bad Thing. If you disagree with him, then please
try to persuade him otherwise. Otherwise, I will not change it.

>not, and I MUST NOT/SHOULD process it, I'm stuck.

You are in fact hoist with your own petard. Nobody required you to
implement your gateway in such a stupid way.

>So what? We're talking about duties of an INCOMING gateway here.

The draft has discouraging things to say about control messages for BOTH
kinds of gateway.

-- 
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: Henry Spencer <[email-masked]>
Date: Mon, 13 Dec 2004 12:43:53 -0500 (EST)

On Mon, 13 Dec 2004, Charles Lindsey wrote:
> continue to reply in detail to John's long rants...

I long ago stopped reading John's endless screeds, never mind replying to
them, and think the list would be better off if everyone ignored them
until he learns to accept defeat on his old issues and present any new
ones clearly and concisely. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Dec 2004 21:51:06 +0100

Charles Lindsey wrote:

> Will the rest of the Working Group please tell me whether
> it wants me to continue to reply in detail

Maybe s/perverse/strange/ or odd, peculiar, idiosyncratic.

I'm still not sure what you have in mind with a gateway saving
Message-IDs as comments.  Maybe replace it by ten repetitions
of "above all avoid loops".  Or add some jokes:  "If you're a
news to avian carrier gateway make sure that you're the only
one."  "While it's funny to gateway news to IRC you'll be shot
if somebody else gateways IRC back to news (and a Message-ID
in a comment is no excuse in this case)".

                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 14 Dec 2004 12:03:51 GMT

>in a comment is no excuse in this case)".

The best means for preventing loops is to ensure that Message-IDs are
propagated correctly. That is the first line of defence, but it sometimes
fails because message-ids get lost/changed/whatever somewhere in the other
medium. So we need a backup method.

The commonest backup is to insert an extra header in the gatewayed
article, such as:

X-Gatewayed-By: <name of gateway>

which the named gateway can then check for before gatewaying any message.

That is the second line of defence, but if fails if the other medium does
not allow X-headers of that nature, or even any headers at all, or if it
cannot be relied upon to propagate such headers reliably. So we need a
last-ditch backup, for use only in these really nasty situations.

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?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Dec 2004 10:43:09 +0100

Charles Lindsey wrote:

> The best means for preventing loops is to ensure that
> Message-IDs are propagated correctly.

Unfortunately that's not the case.  Loops cause two kinds of
problems:  dupes and nopes.  Saving the Message-ID is only a
part of a possible solution.  In your examples it would be
better to have a "do NOT reimport to Usenet" flag instead of
the Message-ID.

Here's a scenario where your strategy fails miserably:

you -> A - B - C -> me
       |   |
       a   b
       |   |
       other

I never see some of your articles in group ABC.test, they do
not exist on server C (= "nope").  A, B, C, the gateways a
and b, and the other net followed your strategy, they kept
the Message-ID, but it didn't work as expected.

I always considered nopes as worse than dupes, because dupes
are at least obvious.  With nopes the only hint you might get
are replies to articles you've never seen.

> it sometimes fails because message-ids get
> lost/changed/whatever somewhere in the other medium. So we
> need a backup method.

We don't need a backup method, we need a clear understanding
why loops generally don't work.  The text about Message-IDs in
comments only helps against dupes, but not nopes.

You could use the A - a - other - b - B - C example as shown
above in the draft, and then explain both problems, dupes and
nopes.

> X-Gatewayed-By: <name of gateway>

Yes, that's a good idea, it's the "do not reimport" flag.

> we need a last-ditch backup, for use only in these really
> nasty situations.

No, the last ditch backup is "do not gateway if you don't know
what you are doing".  And for a proper understanding of these
problems dupes _and_ nopes are the very minimum.  You could
use the same example A - a - other - b - B - C example to show
other problems like lost References (if the other net has no
concept of References and cannot preserve any X-References).

"Save the Message-ID somehow, maybe in the body" is completely
misleading, because it's simply not good enough.

BTW, if I'd "demand" to save FidoNet SeenBy and Path as some
X-SeenBy, X-Path, and X-Original-Fido-Zone, then that would be
also almost useless.  In FidoNet loops are _always_ illegal,
no matter how you do it.
                         Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 20 Dec 2004 14:36:31 GMT

>better to have a "do NOT reimport to Usenet" flag instead of

I don't think there is any reason to forbid "reimport to Usenet" as such
(for example, it may come back into Usenet in a different group and with a
different message-id).  What is important is to deal with it properly when
it comes back to the place where it was gatewayed out of usenet in the
first place.

>the Message-ID, but it didn't work as expected.

But you have not explained to me why it never got to server C, or indeed
exactly what a "nope" is. Please could you describe your scenario in more
detail.

>what you are doing".

Have you ever met a gateway admin who would admit that he "didn't know
what he was doing" :-). No, I think it is up to admins to decide when
the place he is supposed to be gatewaying to is just too bizarre that he
should give up the attempt. So long as it doesn't cause loops and so long
as the people on the other side of his gateway can accept what he sends,
he should be allowed to try.

>misleading, because it's simply not good enough.

Well we are not actually recommending that in our draft. However, I would
not preclude that there might be some sufficiently bizarre "other medium"
where such a thing made good sense.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Dec 2004 01:04:36 +0100

Charles Lindsey wrote:
 
> I don't think there is any reason to forbid "reimport to
> Usenet" as such (for example, it may come back into Usenet
> in a different group and with a different message-id).
.......................^^^

>> I never see some of your articles in group ABC.test
[...]
> you have not explained to me why it never got to server C

"a" exported ABC.test to B.other in the other net,  Then "b"
reimported B.other to B.local on server B.  C doesn't get the
article in ABC.test.  The "and" in your statement (see above)
is important.
  
What "b" could do is to create a new Message-ID, quite the
opposite of your idea to preserve Message-IDs in the body.

> Have you ever met a gateway admin who would admit that he
> "didn't know what he was doing" :-)

Not in the former German "gateways" and "gatebau" groups, all
GiGo users were legend, and dead gateway admins don't post :-)

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 21 Dec 2004 13:57:56 GMT

>article in ABC.test.  The "and" in your statement (see above)

Ah! So it was gatewayed back into a different newsgroup. In that case, a
new message identifier should have been provided somewhere along the line,
probably by b. Our draft does cover this (or something pretty close to it)
by the following text:

   Exceptionally, if there are multiple incoming gateways for a
   particular set of messages, each to a different newsgroup(s), each
   one SHOULD generate a message identifier unique to that gateway. Each
   incoming gateway nonetheless MUST ensure that it does not gate the
   same message twice.

        NOTE: Consider the example of two gateways of a given mailing
        list into the world-wide Usenet newsgroups, both of which
        preserve the email message identifier. Each newsgroup may then
        receive a portion of the messages (different sites seeing
        different portions).  In these cases, where there is no one
        "official" gateway, some other method of generating message
        identifiers has to be used to avoid collisions. It would
        obviously be preferable for there to be only one gateway which
        crossposts, but this may not be possible to coordinate.