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

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

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.

> (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. In RFC 3921/6121 
we don't have the concept of chunking for 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 
and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a 
message. 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. 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.

Sigh.

Peter