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

[Ben Campbell <[e-mail]>]

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

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