Re: Section_7.02.02

New Message Reply About this list Date view Thread view Subject view Author view

From: Clive D.W. Feather (clive@demon.net)
Date: Mon Nov 08 1999 - 07:45:40 CST


Russ Allbery said:
>> 7.1.3. Initial Articles
> This is rather weird. It also requires that the server parse MIME,
> although I guess this whole new implementation of article bodies for
> control messages does in theory. I'm still sort of unsure what I think
> about that.

I don't see a problem with it. It's not going to be the core server, but
rather a subsystem that understands control messages. This already needs to
parse the body.

>> 7.3. The 'mvgroup' Control Message

> I don't see any point served by this note. Any overview mechanism, which
> pretty much all reading servers support these days, immediately makes it
> more complicated than that. There are a lot of things to think about when
> doing mvgroup right; I think that if this note has any effect on
> implementations at all, it will be to encourage poorly-thought-out and
> partially broken ones.

In particular, you need to ensure that the NNTP semantics to do with
arrival times still work. This will be okay for a simple move, but not for
anything more complex.

>> If both groups exist, the groups MAY be "merged". If this is done,
>> it MUST be done correctly, i.e. implementations MUST take care that
>> the messages in the group being deleted are renumbered accordingly
>> to avoid overwriting articles in one group with those of the other,
>> and that crossposted articles do not appear twice.

> Ew... I wouldn't want to touch an implementation of this.

Nor would I. I am not convinced that it is even possible to do without
breaking the NNTP semantics.

> Cancels of that form will not work with many existing servers and that
> should at least be explicitly stated in a NOTE. I also don't see any
> utility at all in adding this to the standard; if you have a bunch of
> messages to cancel, you'll want to put them in the body anyway. News
> headers are not the place to put potentially extensive data.

I agree. We should look at a separate bulkcancel command.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel: +44 20 8371 1138
Internet Expert     | Home:  <clive@davros.org>  | Fax: +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.