[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416: USEPRO 3.9: Reinjection and Injection-Date
Russ Allbery wrote:
Forrest J Cavalier <mibsoft@xxxxxxxxxxxxxxx> writes:
Russ Allbery wrote:
Since the normal case for disjoint Netnews networks is that they'll
have disjoint sets of articles as well. (Also, one doesn't need to
limit it to one in each network necessarily. I was trying to avoid
making that limitation in my language.)
Simple changes. Make it conditional... "To cause an article to appear
on disjoint networks a posting agent SHOULD..."
And "s/one/at least one/"
Yeah, that fixes my concerns there.
Charles has a valid point that it's really beyond the ability of a
posting agent to determine whether two Netnews networks are truly
disjoint.
Yes, this point bothered me as I was going to bed. Relays ought to
check Path and would rewording indicate that? Would this be adequate.
What sort of checking of Path do you have in mind? I can't figure out
exactly what that would entail.
We need to say *what* other header fields it will rename. I think we
also have to allow for drop as well as rename; for example, if I'm
posting to a disconnected INN server and then gatewaying those articles
to Usenet, my local trace information is entirely irrelevant and
there's no reason to retain it.
Isn't that permitted by the last SHOULD? Why is the trace information
entirely irrelevant? It isn't any more irrelevant than opaque trace
information from all the other servers.
It often is. The hostname is localhost, the IP address is 127.0.0.1, etc.
It's allowed by SHOULD, but I don't think we need a SHOULD-level decision
to decide to throw away useless tracking information. Although I guess I
don't feel strongly about it.
Yes, it is often 127.0.0.1, but it is not necessarily 127.0.0.1. It may
include other information that is not useless. It's opaque information.
A corporate private leaf node site or mom-and-pop-and-mickey-mouse ISP (if there
are any left) may have enough users internally that they have use for
preservation.
I'm don't feel strongly about this either.
If this is the complete section, we're not saying that the gatewaying
rules apply anywhere, which I think we still need to do since there may
be bidirectional gatewaying at work (among other things).
Unnecessary complexity. Why make people at private leaf nodes consider
the requirements of bidirectional gatewaying, discarding half of those
requirements?
Er, I don't understand. I'm not proposing that one-directional gateways
be subject to the constraints of bidirectional gateways, of course. I'm
saying that this *is* a gateway and therefore needs to follow the rules of
gateways, including such things as not gatewaying a message that it had
already gatewayed, marking messages it has gatewayed, etc. This is needed
particularly in the case of bidirectional gatewaying, which you may not
know is happening. All that is spelled out in the gateway section, and I
don't want to copy it all into this section again.
All those cautions and caveats are applicable here, so I'd like to just
cite that section and be done with it.
I'm almost OK with that. The trouble I see is that 3.9 Duties of
Gateways is almost all about mailing lists. (And most of the trouble is
there too.) Despite the 3.9 paragraph that says "reinjection is handled
separately below", "proto-article" is mentioned exactly once thereafter,
(just to say it must be valid.)
More seriously The outgoing gateway description in 3.9.1 seems to even
contradict the RFC2119 language I wrote for the special case (handling local
posts from a private leaf node.) I'm not thrilled with the awkwardness and lack
of clarity in 3.9. I can live with it because it is probably wordy enough that
clueful people do the right thing when they read it. I don't count the typical
private leaf node operators in that group....not a slur, just a statement of
skill level.
My idea was to standardize the special case, and then provide enough detail that
it works. If people fall outside that special case, then they are gateways. If
people can fit themselves into the special case, it is better to have the
RFC2119 imperatives rather than the wishy washy 3.9.1.
If the Path checking and idea is sound, do we really gain anything by having
them keep lists of previously gatewayed articles? Tagging them? Are those
really PROTOCOL requirements, necessary to get the end result?
I appreciate your concerns that there is lots to consider in the general case.
Can we "have it both ways" and say, under reinjection....
"Requirements and precautions to avoid problems are described in detail
at 3.9 Duties of Gateways."
Does that work?