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

[Ben Campbell <[e-mail]>]

> 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:
>> 
>>> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet
>>> <[e-mail]> wrote:
>>> 
>>>> On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote:
>>>>> On 2/9/15 4:27 PM, Ben Campbell wrote:
>>>>> (No hats)
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> (I apologize that these comments are late in the process.
>>>>> Please feel free to defer them to last call.)
>>>>> 
>>>>> This version mostly looks good, but there are a few minor
>>>>> issues:
>>>>> 
>>>>> -- Message Size
>>>>> 
>>>>> It might be worth a discussion on message size limits (e.g. the
>>>>> SIP MESSAGE method limits the size to 1300 octets except under
>>>>> some pretty narrow circumstances.)
>>>> 
>>>> Thank you for pointing this out. I had glossed over it in my
>>>> reading of RFC 3428. I think it deserves a section of its own in
>>>> the -im document.
>>> 
>>> I propose the following text:
>>> 
>>> [RFC3428] specifies that (outside of a media session) the size of
>>> a MESSAGE request is not allowed to exceed 1300 bytes.  Although
>>> in practice XMPP instant messages do not often exceed that size,
>>> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of
>>> XMPP stanzas.  However, XMPP server deployments usually do limit
>>> the size of stanzas in order to help prevent denial of service
>>> attacks, and [RFC6120] states that if a server sets a maximum
>>> stanza size then the limit is not allowed to be less than 10,000
>>> bytes.  Because of this mismatch, an XMPP-to-SIP gateway MUST
>>> return a <policy-violation/> stanza error if an XMPP user attempts
>>> to send an XMPP message stanza that would result in a SIP MESSAGE
>>> greater than 1300 bytes.
>>> 
>> 
>> That just stepped in a bit of discomfort on my part, in that I'm not
>> sure how a gateway that happened to support both stox-im and
>> stox-chat decides which to invoke. I'm mostly willing to ignore that
>> particular elephant, but would it be reasonable for an implementation
>> to decide that larger messages would get promoted to MSRP (assuming
>> support at the other end)? If so, the MUST return a
>> <policy-violation/> seems to forbid it.
> 
> We've been treating -im (page mode) and -chat (session mode) as entirely separate things. However, you're right that "upgrading" from page mode (SIP MESSAGE) to session mode (MSRP) might make sense in some situations. Without hearing in detail from those who've implemented such systems, I would be hesitant to specify guidelines for when such an upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and leaving the upgrade logic up to implementations.

A SHOULD works for me. Would it make sense to mention the possibility of upgrading, even if the procedures are not specified?


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

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

> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a message.

Hmm, you've lost me here. 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?

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

> 
> Sigh.
> 
> Peter
>