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

[Ben Campbell <[e-mail]>]

> On Feb 12, 2015, at 5:00 PM, Peter Saint-Andre - &yet <[e-mail]> wrote:
> 
>> On 2/12/15 3:28 PM, Peter Saint-Andre - &yet 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.
> 
> Proposed text:
> 
> ###
> 
> 6.  Message Size
> 
>   [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 SHOULD 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.  Although
>   such a gateway might decide to "upgrade" from page mode to session
>   mode using the Message Session Relay Protocol (MSRP) and thus
>   treating the instant message as part of a chat session as described
>   in [I-D.ietf-stox-chat], such behavior is application-specific and
>   this document provides no guidelines for how to complete such an
>   upgrade.
> 
> ###
> 

WFM

Thanks!

Ben.


>