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

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

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

Peter

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