Re: Message fragmentation via message/partial and news-specific header fields

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

>Bruce Lilly <blilly <at> erols.com> writes:

>> Briefly (this was discussed on ietf-822 in June 2003) the DSN RFC
>> introduced header fields which need to be treated similarly to
>> Message-ID w.r.t. first part message header and enclosed message header
>> for fragmentation and reassembly.  Several of the news-specific fields
>> will also need to be treated differently than what is the case per RFC
>> 2046 rules in lieu of any amendments to those rules.  To take one
>> particular example, the Control field par RFC 2046 rules would have to
>> be copied to the first part message header in order to survive
>> fragmentation/reassembly (only specific fields in the enclosed message
>> header from the original message header which is encapsulated in the
>> first part are copied during reassembly).  That means that that first
>> part will be interpreted as if it were a (complete) control message.  If
>> RFC 2046 rules were to be amended (as they were for DSN-specific fields
>> by RFCs 2298/3798) then the Control field could remain encapsulated
>> within the first part, not copied to the first part message header, the
>> partial messages would not be treated as control messages (only the
>> reassembled whole would be treated as such).

>Ah, I see.  Yes, that makes sense.  I don't personally find work on
>message/partial important enough to spend time on it, but if you come up
>with language to deal with these issues, I'd be willing to review it and
>say whether I think it makes sense.

Well it would be stupid to split a control message using message/partial,
but in the event that it did happen, it would be better to have the
Control-header in the first part (I don't care whether it is also included
in the encapsulated article, though it would be illogical not to do so).

The point is that most agents receiving the message, and particularly
serving agents which are the ones that would implement any control action,
are most unlikely to possess the capability of reassembling the various
parts, or even to have any concept of message/partial at all. Therefore it
is essential that they see the first part as an ordinary control message
and act upon it accordingly. The subsequent parts would then appear in the
relevant groups as ordinary articles, which might be confusing but would
not be likely to do any harm.

In the event that some serving agent did have reassembly capability, then
either

1) It would notice the Control-header first and act upon it. It should
then be smart enough not to bother with reassembly or, if it did
reassemble, to know that it had already done the Control stuff. But even
if it tried to act upon the Control message twice, that would not actually
cause any harm. Or:

2) It would notice the Content-Type: message partial first, in which case
it would then reassemble the message and insert it back into the system,
in which case it would be acted upon as a control message.

>Splitting text messages that small is obnoxious and anti-social and is
>something that I'd filter out on my news server.  General consensus in
>news.software.nntp among news administrators (this came up as well) pretty
>much matched that feeling.  Nothing smaller than 1MB should be split on
>Usenet, and preferrably as far as I'm concerned nothing smaller than 10MB
>(although 1MB is the more common metric).

And indeed there is a NOTE in draft-13 which makes that point. I don't
think it has found its way into the new drafts yet, but it should.

--

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