Subject: RE: [Simple] Re: MSRP: Max message size indication

From: Adam Roach <[email-masked]>
Date: Mon, 7 Jun 2004 11:34:41 -0500

Hisham Khartabil wrote:

> Mandating chunking for messages larger than x bytes seems to 
> enable receivers to send back a 4xx response telling the 
> sender to stop.

I'm not certain this is necessary, and I'm pretty sure
that it's not sufficient.

For starters, we haven't yet said that you must wait for
the end of a message before you respond to it. I see
no reason that you couldn't send an error response to
a SEND transaction while it's still streaming at you.
The adjacent hop could then stop sending you the content
(that is, send the boundary with a "+" indicator at
the end -- or possibly, we could add a new "!" indicator
that means "aborted.").

The issue of squelching the message all the way back to
the sender (in the case of a session with relays) is
also slightly problematic, unless we do something like
mandate that negative DSNs are always on. I don't think
that all parties involved in this discussion would be
happy with such a decision.

/a

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Tue, 08 Jun 2004 19:29:20 +0300

> the end -- or possibly, we could add a new "!" indicator

This could work. Of course it sort of stretches the concept of
request-response, if it requires waiting for a response for a request
that is still in the process of being sent. But this may not be such a
big problem.

I like the "!" indicator a lot. Actually, it is useful also in case the
*sender* needs to abort mid-message. It avoids the recipient rendering
content that is incomplete, possibly resulting in all sorts of weirdness
and garbled content being displayed to the recipient.

> happy with such a decision.

Well, I have a hard time seeing this protocol work unless there is
always the possibility for end-to-end error responses. But this is
probably just because I don't fully understand the requirement for
optionality of the DSNs. In fact it doesn't make any sense to me.

What application is happy to keep on sending a message when the
recipient has already aborted it, and the relay is simply forwarding the
stream to /dev/null? Examples, please.

Cheers,
Aki