headers
Bruce Lilly | 1 Sep 2004 17:33
Picon

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


We had had some discussion about message fragmentation via the MIME media type
message/partial,, and there was some text in earlier drafts, however the
matter is conspicuously absent from the recently-produced usefor-usepro-00
draft.  The rules for message fragmentation and assembly based on standard
header fields are discussed in RFC 2046 as amended by RFC 3798.  There was
some discussion of the matter on the ietf-822 mailing list in June 2003 (q.v.).
I also expect some relevant considerations to be reintroduced into ietf-822
mailing list discussion in the near future.

There are several implications for message fragmentation and reassembly
which appear not to have been adequately considered.  I plan to mention
several of these implications.

First there are some questions that need to be considered:
1. a) Where is message fragmentation expected to occur (e.g. during transport
   between transfer agents when it is recognized that the receiving agent
   has some message size limit), and b) by what criteria (presumably some
   site-dependent size limit, but how is that communicated to that site's
   feeding agents)?
2. Where does reassembly take place?
3. How is multiple fragmentation to be handled? [e.g. a 1GB original
   message might be fragmented into 100 MB pieces at some point, which
   might then be further fragmented into 10 MB pieces, etc.  That means
   that a given article may appear multiple times at various places in
   the network; unfragmented, and broken into various different-sized
   pieces -- the original message and the various pieces each having
   separate, unique message identifiers.)
4. a) During fragmentation, which message header fields are to be copied
   to the enclosing message header, and which are to be preserved in
(Continue reading)

Permalink | Reply | 11 comments |
headers
Russ Allbery | 2 Sep 2004 10:27
Picon
Favicon
Gravatar

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


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

> We had had some discussion about message fragmentation via the MIME
> media type message/partial,, and there was some text in earlier drafts,
> however the matter is conspicuously absent from the recently-produced
> usefor-usepro-00 draft.  The rules for message fragmentation and
> assembly based on standard header fields are discussed in RFC 2046 as
> amended by RFC 3798.  There was some discussion of the matter on the
> ietf-822 mailing list in June 2003 (q.v.).  I also expect some relevant
> considerations to be reintroduced into ietf-822 mailing list discussion
> in the near future.

Is there really any point in talking about this in our drafts?

It seems highly unlikely to me that we're going to get the people who
fragment Usenet messages to adopt MIME to do so, even if it would be the
right thing.  There have been extensive discussions in news.software.nntp
about this and the outcome was quite clear.  Given that, I think this
would mostly be an exercise in protocol design for its own sake, and I'm
not sure that it's worth spending the time and effort on it given the
unlikeliness of widespread use.

I'd rather just not mention it and expend our resources on more pressing
problems, unless there's some significant need to attack this problem and
some reasonable belief that people will adopt a standardized solution in
any significant numbers.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bruce Lilly | 2 Sep 2004 18:01
Picon

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


Russ Allbery wrote:

> Is there really any point in talking about this in our drafts?

Yes, for the same reason that the issue was addressed in RFC 3798 (and
2298 before it).

> It seems highly unlikely to me that we're going to get the people who
> fragment Usenet messages to adopt MIME to do so, even if it would be the
> right thing.

1. Message/partial fragmentation has already been used on Usenet.
2. Fragmented messages via message/partial may appear at mail-to-news
   gateways.
3a. Message/partial is, AFAIK, the only standardized method for
   message fragmentation and reassembly.  And since it is part of
   MIME, it is widely applicable (e.g. to HTTP as well as Internet
   Message Format).
3b. If there is some other method of fragmentation/reassembly, the same
   sort of issues need to be discussed

> There have been extensive discussions in news.software.nntp
> about this and the outcome was quite clear.

Clear to whom and from what perspective?  Since the discussion didn't
take place here, can you summarize the discussion or point to an
archived summary?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Russ Allbery | 2 Sep 2004 19:54
Picon
Favicon
Gravatar

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


Bruce Lilly <blilly <at> erols.com> writes:
> Russ Allbery wrote:

>> Is there really any point in talking about this in our drafts?

> Yes, for the same reason that the issue was addressed in RFC 3798 (and
> 2298 before it).

What was that reason?  I'm not familiar with either of those RFCs.

> 1. Message/partial fragmentation has already been used on Usenet.
> 2. Fragmented messages via message/partial may appear at mail-to-news
>    gateways.
> 3a. Message/partial is, AFAIK, the only standardized method for
>    message fragmentation and reassembly.  And since it is part of
>    MIME, it is widely applicable (e.g. to HTTP as well as Internet
>    Message Format).
> 3b. If there is some other method of fragmentation/reassembly, the same
>    sort of issues need to be discussed

This is all nice and good and my point is that message fragmentation is
something that's only useful on Usenet for binary messages and 99.99% of
the binary posters are never going to use it based on the *extensive*
discussions that have been had with the authors of that software and with
news administrators on news.software.nntp.

So while this might be useful to someone, it is an extreme edge case and
one with which we have little to no implementation experience, which makes
me doubt in the extreme that this working group is going to be able to do
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Davidsen | 2 Sep 2004 20:30

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


Russ Allbery wrote:
> Bruce Lilly <blilly <at> erols.com> writes:
> 
>>Russ Allbery wrote:
> 
> 
>>>Is there really any point in talking about this in our drafts?
> 
> 
>>Yes, for the same reason that the issue was addressed in RFC 3798 (and
>>2298 before it).
> 
> 
> What was that reason?  I'm not familiar with either of those RFCs.
> 
> 
>>1. Message/partial fragmentation has already been used on Usenet.
>>2. Fragmented messages via message/partial may appear at mail-to-news
>>   gateways.
>>3a. Message/partial is, AFAIK, the only standardized method for
>>   message fragmentation and reassembly.  And since it is part of
>>   MIME, it is widely applicable (e.g. to HTTP as well as Internet
>>   Message Format).
>>3b. If there is some other method of fragmentation/reassembly, the same
>>   sort of issues need to be discussed
> 
> 
> This is all nice and good and my point is that message fragmentation is
> something that's only useful on Usenet for binary messages and 99.99% of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 2 Sep 2004 20:44
Picon

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


Russ Allbery wrote:
> Bruce Lilly <blilly <at> erols.com> writes:
> 
>>Russ Allbery wrote:
> 
> 
>>>Is there really any point in talking about this in our drafts?
> 
> 
>>Yes, for the same reason that the issue was addressed in RFC 3798 (and
>>2298 before it).
> 
> 
> What was that reason?  I'm not familiar with either of those RFCs.

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Allbery | 3 Sep 2004 20:11
Picon
Favicon
Gravatar

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


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.

> No, it's useful for any message whose size exceeds some threshold,
> including large text documents (such as, oh, maybe
> draft-ietf-usefor-article-13.txt for example).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 13 Sep 2004 14:57
Picon
Picon

The great mailing list muddle


If seems that our Chair has switched to the new mailing list without at
the same time posting a warning message to the old list for the benefit of
those who had omitted, or more likely who had tried and failed, to
subscribe to the new.

So here is a heads up that the submission address for the Usefor Working
Group list is now ietf-usefor <at> imc.org and requests to subscribe should be
sent to ietf-usefor-request <at> imc.org with the single word 'subscribe' in
the body of the message. Well, actually, it is a majordomo system, so the
usual majordomo commands will work.

But, if you try to do anything fancy, like having a different subscription
address (such as a gateway to a local mailing list) but still want to post
as from your usual mail address, then you will get a reply like

Your request to majordomo <at> vpnc.org:

subscribe ietf-usefor local.usefor <at> clerew.man.ac.uk

has been forwarded to the owner of the "ietf-usefor" list for approval. 

and after that, you will hear nothing even if, as I did, you ask our Chair
to ensure that your subscription is processed promptly and he assures you
that he has done so.

Sadly, this seems to be a common situation with mailing lists hosted at
imc.org.

So now we have the ridiculous situation of a Working Group whose Editor is
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Davidsen | 14 Sep 2004 13:00

Re: The great mailing list muddle


Thanks for the heads-up, it explains why I no longer get any mail for 
this list. I've sent the subscribe several times, and even gotten ack 
the first time IIRC, but clearly the new list is more bozo'd than the 
old. Pity it couldn't have been moved to somewhere competent, like 
lists.debian.org or such.

Nice to know this has become a closed list, rather than dead.

Charles Lindsey wrote:
> If seems that our Chair has switched to the new mailing list without at
> the same time posting a warning message to the old list for the benefit of
> those who had omitted, or more likely who had tried and failed, to
> subscribe to the new.
> 
> So here is a heads up that the submission address for the Usefor Working
> Group list is now ietf-usefor <at> imc.org and requests to subscribe should be
> sent to ietf-usefor-request <at> imc.org with the single word 'subscribe' in
> the body of the message. Well, actually, it is a majordomo system, so the
> usual majordomo commands will work.
> 
> But, if you try to do anything fancy, like having a different subscription
> address (such as a gateway to a local mailing list) but still want to post
> as from your usual mail address, then you will get a reply like
> 
> Your request to majordomo <at> vpnc.org:
>  
> subscribe ietf-usefor local.usefor <at> clerew.man.ac.uk
>  
> has been forwarded to the owner of the "ietf-usefor" list for approval.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 14 Sep 2004 20:03
Picon
Favicon
Gravatar

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


Charles Lindsey <chl <at> clerew.man.ac.uk> writes:

> This message, posted to the old list, is now reposted to the new list
> for the benefit of anyone no longer reading the old one.

This is the first time I've seen this message, so either the old list is
no longer working or I've been silently unsubscribed from it for some
reason.

--

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

Gmane