Subject: [Stox] Comments on stox-chat-09

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Feb 2015 16:59:51 -0600

(Resending to include STOX list)
(No hats yet)

Hi Peter and Alissa,

I've looked over draft-ietf-stox-chat-09. It looks mostly good, but there are still a few issues.

Thanks!

/Ben

----------------------------

MSRP Failure-Report headers:

The examples assume the MSRP Failure-Report header field is set to no. It's missing from the first SEND, but explicitly set to no in the rest. The responses to SEND requests are left off throughout. This is allowed, but non-default behavior for MSRP. If the intent is to set Failure-Report: no, it would be good to say a few words about it. If the intent is to leave that to the implementation, then I would expect the examples to follow the defaults.

SIP Response From/To:

The SIP responses swap the From and To from the associated requests. This is not correct, To and From of a SIP response matches the To and From of the original request. (More to the point, the To and From in a response do not change to indicate the direction of the response message.) I note that the groupchat draft had this issue at one point, but it's been fixed.

Session Termination

I would like to see a little more prominent discussion about when the XMPP side might terminate a session. It's mentioned in the "Composing" section, but that seems to bury an important concept. I note both primary examples show the SIP side terminating the session--it would be nice to see one of those examples let the XMPP side do it.  (Is the "gone" composing state the only way this would happen?)

SIP CSeq:

CSeq is missing from most SIP requests, except oddly for BYE requests. (And note that the CSeq of a BYE, sent by the peer that initiated the INVITE, would never be "1")

Security Considerations, last sentence:

The text non-normatively "suggests" the use of RFC3862 for end-to-end protection. That seems to want to have it both ways (non-normative and recommended) . I suggest either making that normative, or reducing the strength to say RFC3862 could be used for this purpose. (I realize we do this all the time with "ought to", but it seems like we need a sharper line for something like e2e crypto.)

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Feb 2015 20:35:34 -0700

On 2/9/15 3:59 PM, Ben Campbell wrote:
> (Resending to include STOX list) (No hats yet)
>
> Hi Peter and Alissa,
>
> The examples assume the MSRP Failure-Report header field is set to
> no. It's missing from the first SEND, but explicitly set to no in the
> rest. The responses to SEND requests are left off throughout. This is
> allowed, but non-default behavior for MSRP. If the intent is to set
> Failure-Report: no, it would be good to say a few words about it. If
> the intent is to leave that to the implementation, then I would
> expect the examples to follow the defaults.

As I see it:

Because the XMPP message receipts specification (XEP-0184) does not 
support failure reports, there is no mapping for the MSRP Failure-Report 
header field and gateways SHOULD set that header field to "no".

> SIP Response From/To:
>
> The SIP responses swap the From and To from the associated requests.
> This is not correct, To and From of a SIP response matches the To and
> From of the original request. (More to the point, the To and From in
> a response do not change to indicate the direction of the response
> message.) I note that the groupchat draft had this issue at one
> point, but it's been fixed.

Noted. Will fix.

> Session Termination
>
> I would like to see a little more prominent discussion about when the
> XMPP side might terminate a session. It's mentioned in the
> "Composing" section, but that seems to bury an important concept. I
> note both primary examples show the SIP side terminating the
> session--it would be nice to see one of those examples let the XMPP
> side do it.  (Is the "gone" composing state the only way this would
> happen?)

There is no concept of an explicit messaging session in RFC 6121: the 
conversation just trails off. The "gone" state is the only way to 
indicate that the session is over, but that's not defined in RFC 6121.

> SIP CSeq:
>
> CSeq is missing from most SIP requests, except oddly for BYE
> requests.

Are you saying that CSeq is typically not included in SIP requests (even 
in dialogs) per the specs, or that we have mistakenly left them off 
here? I think the latter, but I want to make sure.

> (And note that the CSeq of a BYE, sent by the peer that
> initiated the INVITE, would never be "1")

True.

> The text non-normatively "suggests" the use of RFC3862 for end-to-end
> protection. That seems to want to have it both ways (non-normative
> and recommended) . I suggest either making that normative, or
> reducing the strength to say RFC3862 could be used for this purpose.
> (I realize we do this all the time with "ought to", but it seems like
> we need a sharper line for something like e2e crypto.)

See previous reply about the -im document.

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Feb 2015 23:01:05 -0600

> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 
> Because the XMPP message receipts specification (XEP-0184) does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no".
> 

That's reasonable. A few words to that effect might help keep others from tripping over it.

[...]

> There is no concept of an explicit messaging session in RFC 6121: the conversation just trails off. The "gone" state is the only way to indicate that the session is over, but that's not defined in RFC 6121.

Got it. Then my only real comment here is it might be nice (but completely optional) to say something about that in the main flow examples, instead of bury it in the "composing" state section.

> Are you saying that CSeq is typically not included in SIP requests (even in dialogs) per the specs, or that we have mistakenly left them off here? I think the latter, but I want to make sure.
> 

The latter. "most SIP requests" should have been "most SIP requests in this draft".

[...]

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 12 Feb 2015 15:02:36 -0700

On 2/11/15 10:01 PM, Ben Campbell wrote:
>>> The examples assume the MSRP Failure-Report header field is set
>>> to no. It's missing from the first SEND, but explicitly set to no
>>> in the rest. The responses to SEND requests are left off
>>> throughout. This is allowed, but non-default behavior for MSRP.
>>> If the intent is to set Failure-Report: no, it would be good to
>>> say a few words about it. If the intent is to leave that to the
>>> implementation, then I would expect the examples to follow the
>>> defaults.
>>
>> As I see it:
>>
>> support failure reports, there is no mapping for the MSRP
>> Failure-Report header field and gateways SHOULD set that header
>> field to "no".
>>
>

Here's what I have in Section 7 of my working copy...

    Because the XMPP Message Receipts specification does not support
    failure reports, there is no mapping for the MSRP Failure-Report
    header field and gateways SHOULD set that header field to "no".

> [...]
>
>>> Session Termination
>>>
>>> I would like to see a little more prominent discussion about when
>>> the XMPP side might terminate a session. It's mentioned in the
>>> "Composing" section, but that seems to bury an important concept.
>>> I note both primary examples show the SIP side terminating the
>>> session--it would be nice to see one of those examples let the
>>> XMPP side do it.  (Is the "gone" composing state the only way
>>> this would happen?)
>>
>> There is no concept of an explicit messaging session in RFC 6121:
>> the conversation just trails off. The "gone" state is the only way
>> to indicate that the session is over, but that's not defined in RFC
>> 6121.
>
> Got it. Then my only real comment here is it might be nice (but
> completely optional) to say something about that in the main flow
> examples, instead of bury it in the "composing" state section.

Perhaps this at the end of Section 4:

    In addition, there is no explicit method defined in [RFC6121] for an
    XMPP user to formally terminate a chat session, so a gateway would
    need to listen for a "gone" chat state notification from the XMPP
    user or institute a timer that considers the XMPP informal chat
    session to be ended after some amount of time has elapsed.

>> Are you saying that CSeq is typically not included in SIP requests
>> (even in dialogs) per the specs, or that we have mistakenly left
>> them off here? I think the latter, but I want to make sure.
>>
>

OK, we'll add those in. I notice that the presence document has them...

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Feb 2015 20:31:28 -0600

All points WFM.

Thanks!

Ben.

> On Feb 12, 2015, at 4:02 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
>