Re: [Stox] Comments on draft-ietf-stox-im-11

[Peter Saint-Andre - &yet <[e-mail]>]

On 2/12/15 8:57 PM, Peter Saint-Andre - &yet wrote:
> On 2/12/15 8:30 PM, Ben Campbell wrote:
>>
>>
>>
>>> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet
>>> <[e-mail]> wrote:
>>>
>>>> On 2/12/15 7:58 PM, Ben Campbell wrote:
>>>>
>>>>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet
>>>>> <[e-mail]> wrote:
>>>>>
>>>>>> On 2/11/15 8:07 PM, Ben Campbell wrote:
>>>>>>
>>>>>> (While I'm still standing in it--what happens in stox-chat if
>>>>>> the MSRP side sends a message larger than the largest allowed?
>>>>>> Apologies if the draft talks about that--I don't have it in front
>>>>>> of me.)
>>>>>
>>>>> That's messy. :/
>>>>>
>>>>> Ideally we'd be talking about unchunked MSRP messages.
>>>>
>>>> Yes, or a message reassembled from chunks by the gateway.
>>>
>>> Ah, true. That might give us a way out.
>>>
>>>>> In RFC 3921/6121 we don't have the concept of chunking afor regular
>>>>> chat messages, and the only chunking method we have in XMPP is not
>>>>> used for chat messages but for file transfer (XEP-0047). For chat
>>>>> purposes, a typical XMPP client won't have the necessary
>>>>> application logic to handle chunked messages ...
>>>>
>>>> Right, that would be the gateway's problem. I had assumed that the
>>>> since the gateway is for all practical purposes the MSRP endpoint, it
>>>> would reassemble any chunks before sending toward the XMPP side.
>>>
>>> Right.
>>>
>>>>> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a
>>>>> message.
>>>>
>>>> Hmm, you've lost me here.
>>>
>>> That's because I was thinking out loud. :-)
>>>
>>>> Do you mean the gateway can't assume it's
>>>> okay to chunk towards the XMPP client (which makes sense) or towards
>>>> the MSRP client?
>>>
>>> Towards the XMPP client. But as you say that's not necessary.
>>>
>>>>> However, I don't see a way in RFC 4975 for an entity such as a
>>>>> gateway to advertise that it doesn't support chunking.
>>>>
>>>> There's not a way, because the assumption has always been that any
>>>> MSRP endpoint can at least receive chunked messages.
>>>>
>>>>> Although in theory the max-size a-line could help, that applies to
>>>>> full messages before chunking. I also don't see a way in RFC 4975
>>>>> to reject a particular MSRP SEND because it's too big.
>>>>
>>>> You can sort of do this with 413. But I think it's the whole message
>>>> size that is important here, not the size of a particular SEND
>>>> request.
>>>
>>> Yes.
>>>
>>> Let me propose some text. Stay tuned...
>>
>> This seems like the right track, although it's worth considering how
>> much buffering a gateway might be willing to do, and think about
>> memory depletion attacks. This is mentioned in 4975, so it may already
>> be covered well enough.
>
> True.
>
> Proposed text for a new section in stox-chat...
>
> ###
>
> 8.  Message Size
>
>     Unlike page-mode messaging [RFC3428] (which specifies that the size
>     of a MESSAGE request is not allowed to exceed 1300 bytes), session-
>     mode messaging [RFC4975] can be used to send larger messages.  MSRP
>     includes a chunking mechanism such that larger messages can be broken
>     up into multiple MSRP SEND requests.  Because the MSRP gateway at an
>     XMPP service acts as an MSRP endpoint, it is responsible for
>     receiving chunked messages and reconstructing them into a single
>     message for delivery toward the XMPP recipient.  (Naturally,
>     implementations need to be careful about accepting very large
>     messages; see Section 14.5 of [RFC4975].)
>
>     Although there is no hard limit on the size of an XMPP stanza, in
>     practice most XMPP services (at least on the public Internet) are
>     configured with a maximum stanza size in order to help prevent denial
>     of service attacks.  As specified in Section 13.12 of [RFC6120], this
>     maximum is not allowed to be less than 10,000 bytes.
>
>     The administrators of an XMPP service need to ensure the associated
>     MSRP gateway is configured with the same or smaller maximum MSRP
>     message size as the maximum XMPP stanza size; this enables the
>     gateway to return an appropriate value for the SDP "max-size"
>     attribute and to properly handle messages larger than the configured
>     limits.
>
>     If an MSRP-to-XMPP gateway implementation receives an MSRP message
>     that exceeds its configured limit as just described, it MUST return
>     an MSRP 413 error (e.g., in response to the first SEND request whose
>     Byte-Range header field indicates a byte total exceeding the limit).
>
> ###

Ben, let me know if that text looks OK. It seems that we'll want to add 
a pointer from the -groupchat document to this section, too, eh?

I think this is the last open issue from your reviews, so once you say 
it's OK I'll submit revised I-Ds for -im, -chat, and -groupchat.

Thanks!

Peter

-- 
Peter Saint-Andre
https://andyet.com/