headers
Russ Allbery | 1 Jan 2007 01:04
Picon
Favicon
Gravatar

Re: Moderation issues


Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:
> Russ Allbery wrote:

>> This area is not going to get any better until there's a strong
>> authentication system for moderator approvals.  Until then, anything we
>> write about the mechanics of this is written on quicksand; in practice,
>> there are a bunch of ad hoc conventions that are not suitable for
>> standardization.

> If we can't identify a least common denominator or a "KISS" procedure
> we're forced to state that X-Posts affecting more than one moderated
> group are not covered by the spec. and be done with it.

I can accept saying that any crossposts between two moderated groups will
have to be worked out between the two moderators via means not covered by
the standard.  I think what we do have now is a minor improvement over
that and was the result of a long working group debate, so I wouldn't
agree with removing it without clear working group consensus and would
oppose that change, but I can see an argument for leaving it
unstandardized.

> From my POV (moderators as part of the protocol) modifying the content
> is an abomination.  But if your "higher-layer moderators" do it anyway,
> then yes, of course they MUST use their own Message-ID.  While they're
> at it they could also use their own From, and formulate their text as
> citation giving credits to the submitter of the original text as needed.

> So I'd be happy if you simply write that moderated groups transporting
> modified content are out of scope.  We could then focus on the straight
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Jan 2007 17:34
Picon
Picon

Re: Decision: Let's get draft-allbery-usefor-usepro-00 right and publish it as draft-ietf-usefor-usepro-07


In <87y7oqimka.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:
>> Russ Allbery wrote:
> 
>>> The situation only gets interesting when the poster themselves has
>>> provided the message ID, which is an entirely different case.

>> It's the interesting case - I don't care about any provisional M-ID used
>> for the communication between the server where the article was
>> submitted, and the moderator(s).  If the first (and only the first)
>> moderator somehow identifies a provisional M-ID he's free to beautify
>> it.  But modifying an original M-ID is utter dubious, and it could cause
>> complete confusion if a later (not the first) moderator starts to modify
>> an already approved M-ID.

>How?  Could you provide some specific examples of what interoperability
>problems you believe could result?  As previously mentioned, cancels are
>not an insolvable issue; cancels of a message in a moderated group have to
>be approved by the moderator anyway, at which point the correct message ID
>can be used.

Yes, but for that to work a moderator would have to keep a list of
original message-ids vs new message-ids, and I can't see many moderators
being willing to go to that trouble.

And then there the posters who try to cancel the message themselves by
Approving it themselves. Naughty, but it's going to happen, as Frank has
said.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Jan 2007 17:20
Picon
Picon

Re: charset of application/news-{groupinfo,checkgroups}


In <873b6yk25y.fsf_-_ <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Here's what I currently have:

>   The content of the application/news-groupinfo body part is defined
>   as:

...........

>         newsgroup-description
>                             = eightbit-utext *( *WSP eightbit-utext )
>         moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
>                                  ; case sensitive "(Moderated)"
>         eightbit-utext      = utext / %d127-255

OK, <eightbit-utext> was clearly needed, but it still excludes those ASCII
characters not in <utext> notably CR, LF and HT, so you could not use
EBCDIC (where I am sure those octets correspond to useful characters) nor
any charset which could be escaped into or out of ASCII and in which those
octets had some other meaning when escaped.

>   This unusual format is backward-compatible with the scanning of the
>   body of newgroup control messages for descriptions done by Netnews
>   implementations that predate this specification.  Although optional,
>   the <newsgroups-tag> SHOULD be included for backward compatibility.

>   The <newsgroup-description> MUST NOT contain any occurrence of the
>   string "(Moderated)" within it.  Moderated newsgroups MUST be marked
>   by appending the case sensitive text " (Moderated)" at the end.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Russ Allbery | 1 Jan 2007 19:20
Picon
Favicon
Gravatar

Re: charset of application/news-{groupinfo,checkgroups}


Charles Lindsey <chl <at> clerew.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> writes:

>>         newsgroup-description
>>                             = eightbit-utext *( *WSP eightbit-utext )
>>         moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
>>                                  ; case sensitive "(Moderated)"
>>         eightbit-utext      = utext / %d127-255

> OK, <eightbit-utext> was clearly needed, but it still excludes those
> ASCII characters not in <utext> notably CR, LF and HT,

By HT I assume you mean HTAB?  That's is added back in by WSP in the
newsgroup-description production, so only CR and LF are disallowed, which
is intentional.

> so you could not use EBCDIC (where I am sure those octets correspond to
> useful characters) nor any charset which could be escaped into or out of
> ASCII and in which those octets had some other meaning when escaped.

Right.

> Yes, that almost gets you there, and maybe near enough. But it does result
> in some oddities:

> 1. Suppose you specify a charset that works for the
> <newsgroup-description> but renders the <newsgroup-name> as gibberish.

Surely this is obviously invalid?  It would mean that the newsgroup name
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 1 Jan 2007 18:35
Picon
Picon

Re: Control message propagation


In <45967D89.61C9 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Same here, a "checkgroups" listing _all_ newsgroups in the Newsgroups
>header field would be odd.  Get rid of "for example", the qualifier is
>confusing without "mvgroup".

Hmmmm! Please can somebody say what IS the correct Newsgroups header for a
checkgroups? I don't think any of our documents have mentioned this yet.

--

-- 
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: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 2 comments |
headers
Charles Lindsey | 1 Jan 2007 18:32
Picon
Picon

Re: Control message propagation


In <87odpmil35.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>I now have:

>   Exceptionally, control messages creating or removing newsgroups
>   (newgroup or rmgroup control messages, for example) SHOULD be relayed
>   if the affected group appears in its Newsgroups header field and the
>   sending agent would have supplied and the receiving agent would have
>   received the newsgroup affected by the control message had it existed,
>   even if it currently does not.

I presume that is intended to go after the current 2nd paragraph of 3.5.

In which case, since that existing paragraph clearly indicates that it is
a matter of the configuration of the sending and receiving relaying
agents, you might as well continue with that terminology. So perhaps:

"...if the affected group appears in its Newsgroups header field and the
sending agent and receiving relaying agents are both configured to relay a
newsgroup of that name (whether or not such a newsgroup yet exists)."

>for the propagation rule, the following under group control messages:

>   Group control messages affecting specific groups (newgroup and
>   rmgroup control messages, for example) SHOULD include the <newsgroup-
>   name> for the group or groups affected in their Newsgroups header
>   field.  Other newsgroups MAY be included in the Newsgroups header
>   field so that the control message will reach more news servers, but
>   due to the special relaying rules for group control messages (see
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 1 Jan 2007 18:48
Picon
Picon

Re: ihave/sendme syntax (was: draft-allbery-usefor-usepro-00 errata)


In <87k60aik36.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Russ Allbery <rra <at> stanford.edu> writes:

>I've since reviewed RFC 1036 and Son-of-1036.  The former makes the
>relayer name optional and requires that the message IDs be in the control
>header field.  The latter makes the relayer name mandatory and RECOMMENDS
>that the message IDs be put in the body.  I think the following is the
>most reasonable compromise; it makes the relayer-name mandatory if there
>are no message IDs (the form never allowed in RFC 1036 but according to
>Son-of-1036 the most widely used in practice), and if there are message
>IDs, permits the same syntax as RFC 1036.

I don't see why the optionality or otherwise of the <relayer-name> should
correlate in any way with whether the list of msg-ids is in the header or
the body (except to ensure that these headers never have empty content,
which does not sound like a particularly good reason).

So I would think it better to follow Son-of-1036 and make it obligatory
regardless. I think we can assume that Henry had sufficient experience of
the way Ihave and Sendme were used at that time that it is safe to follow
his lead.

In any case, the paragraph which follows explaining how to use these two
headers is written on the assumption that a <relayer-name> will be
provided.

If any pair of existing relayers is currently using this protocol without
<relayer-name>s, then good luck to them, and 'lang may their lum reek'.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles Lindsey | 1 Jan 2007 18:51
Picon
Picon

Re: to.* newsgroups (was: draft-allbery-usefor-usepro-00 errata)


In <87fyayijf8.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>I'm convinced.  I now have:

>   These control messages are normally sent as point-to-point articles
>   between two sites and not then sent on to other sites.  Newsgroups
>   beginning with "to." are reserved for such point-to-point
>   communications and are formed by prepending "to." to a <relayer-name>
>   to form a <newsgroup-name>.  Articles with such a group in their
>   Newsgroups header fields SHOULD NOT be sent to any news server other
>   than the one identified by <relayer-name>.

Fine!

--

-- 
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: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Jan 2007 21:52
Picon
Picon

Re: Path header field


In <87bqlmigu8.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>As promised, here is the new section.  I also made the corresponding
>updates to the other sections (removing the description and replacing it
>with a reference to this section) and moved the Path header field example.

>3.2.1.  Constructing the Path Header Field

>   If a relaying or serving agent receives an article from an injecting
>   or serving agent that is part of the same news server, it MAY leave
>   the Path header field of the article unchanged.  Otherwise, every
>   injecting, relaying, or serving agent that accepts an article MUST
>   update the Path header field as follows.  Note that the Path header
>   field content is constructed from right to left by prepending
>   elements.

I think that is more restrictive than we intended. The idea was that if
there was a "farm" of servers at one site, splitting the various duties
(incoming articles, outgoing articles, local storage of articles) amongst
themselves in some manner, it was not necessary to include every server
the article actually passed through (i.e. we do not need to see, from the
outside, the detailed internal structure of that site).

>   1.  The agent MUST prepend "!" to the Path header field content.

>   2.  An injecting agent SHOULD prepend the <path-diagnostic>
>       "!.POSTED", optionally followed by "." and the FQDN or IP address
>       of the source, to the Path header field content.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Allbery | 2 Jan 2007 07:16
Picon
Favicon
Gravatar

Re: Control message propagation


Charles Lindsey <chl <at> clerew.man.ac.uk> writes:
> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>> Same here, a "checkgroups" listing _all_ newsgroups in the Newsgroups
>> header field would be odd.  Get rid of "for example", the qualifier is
>> confusing without "mvgroup".

> Hmmmm! Please can somebody say what IS the correct Newsgroups header for a
> checkgroups? I don't think any of our documents have mentioned this yet.

There isn't a correct one from a protocol standpoint -- whatever achieves
the propagation one wants.  Traditionally one uses the administrative
announcement newsgroup for the hierarchy.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 1 comment |

Gmane