Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08

[Ben Campbell <[e-mail]>]

(Alissa pointed out that I left the STOX list of of these--resending.)

One more thing: The SIP CSeq headers are incorrect in several places. CSeq is missing from most SIP messages, except in BYE requests.

(This is also true for stox-chat. I will send notes on that separately.)

/Ben

> On Feb 6, 2015, at 11:11 PM, Ben Campbell <[e-mail]> wrote:
> 
> 
>> On Feb 6, 2015, at 6:08 PM, Peter Saint-Andre - &yet <[e-mail]> wrote:
>> 
>> Ben, thanks again for your careful reviews. If you don't mind I'll address these as IETF LC feedback, unless Alissa would like me to push out a revised version incorporating the relevant fixes.
>> 
> 
> Certainly, that works for me.
> 
> Thanks!
> 
> Ben.
> 
>> On 2/6/15 4:34 PM, Ben Campbell wrote:
>>> (No hats)
>>> 
>>> Hi Peter and Alissa,
>>> 
>>> I just reviewed version groupchat-09, and it looks good. I just noticed a few nits:
>>> 
>>> Section 4: The bulleted text for example.org and chat.example.org don't seem to quite match the figure. The figure calls both the focus and switch chat.example.org (which may not be what you want.  Example.org is a SIP proxy.
>>> 
>>> 5.1: The indented paragraph about MSRP URLs could be interpreted to mean that the explicit port is only required for a literal address. In fact, it's always required.
>>> 
>>> /Ben
>>> 
>>> 
>>>> On Feb 2, 2015, at 10:59 AM, Peter Saint-Andre - &yet <[e-mail]> wrote:
>>>> 
>>>> On 1/31/15 5:10 PM, Alissa Cooper wrote:
>>>>> I have reviewed this draft in preparation for IETF LC. I have a couple of comments/questions that I’d like to discuss before issuing the LC. I’ve also included some editorial nits that should be addressed together with any LC comments.
>>>>> 
>>>>> = Section 5 =
>>>>> All of the flow labels as used in the text and the examples need to be checked against the labels in the diagram. I found a bunch of inconsistencies where the labels used in the text are not describing the right flows in the diagram (e.g., Example 20, all the labels in Section 5.8). This is sort of editorial but given that the spec is basically defined by the diagrams and examples, I think it needs to be fixed before IETF LC. It confused me quite a bit.
>>>> 
>>>> Yes, we changed them all around based on Ben Campbell's review and I recall making the modifications late at night, so it doesn't surprise me greatly that there are errors. Will review again.
>>>> 
>>>>> In fact, I would suggest checking every label in the document to make sure it corresponds to the appropriate diagramed flow.
>>>> 
>>>> +1
>>>> 
>>>>> = Section 5.1 =
>>>>> "As specified in [RFC7247], the mapping of XMPP syntax elements to SIP
>>>>>  and [RFC4566] syntax elements is as shown in the following table.”
>>>>> 
>>>>> This doesn’t seem quite right since RFC 7247 doesn’t actually provide the mapping of from->From and to->To — that’s what the table right here is doing. I would suggest that the text here follow the same pattern used in the -im draft, namely:
>>>>> 
>>>>> "The mapping of XMPP syntax to SIP syntax [MUST] be as shown in the following table.
>>>>> 
>>>>> Table 1: Message syntax mapping from XMPP to SIP/SDP
>>>>> 
>>>>>      +-----------------------------+-----------------------------+
>>>>>      |  XMPP Element or Attribute  |  SIP Header or SDP Contents |
>>>>>      +-----------------------------+-----------------------------+
>>>>>      |  from                       |  From                       |
>>>>>      |  to (without the /nick)     |  To                         |
>>>>>      +-----------------------------+——————————————+
>>>>> 
>>>>> As shown in the foregoing example and described in [RFC7247], the
>>>>>      XMPP-to-SIP gateway [MUST] map the bare JID
>>>>>      ("localpart@domainpart") of the XMPP sender to the SIP From
>>>>>      header and include the resourcepart of the full JID as the GRUU
>>>>>      portion [RFC5627] of the SIP URI.”
>>>>> 
>>>>> Note that I’ve replaced the SHOULDs with MUSTs as explained in my comments on the -im draft.
>>>> 
>>>> Great, thanks.
>>>> 
>>>>> = Section 5.4 =
>>>>> OLD
>>>>> The following table shows the syntax mapping from the RFC 4575
>>>>>  payload to the XMPP participant list.
>>>>> 
>>>>> NEW
>>>>> The syntax mappings from the RFC 4575
>>>>>  payload to the XMPP participant list MUST be as shown in the following table.
>>>>> 
>>>>> OLD
>>>>> The mapping of SIP and [RFC4575] payload syntax elements to XMPP
>>>>>  syntax elements is as shown in the following table.
>>>>> 
>>>>> NEW
>>>>> The mapping of SIP and [RFC4575] payload syntax elements to XMPP
>>>>>  syntax elements MUST be as shown in the following table.
>>>>> 
>>>>> = Section 5.5 =
>>>>> OLD
>>>>> The mapping of XMPP syntax elements to MSRP syntax elements is as
>>>>>  shown in the following table.
>>>>> 
>>>>> NEW
>>>>> The mapping of XMPP syntax elements to MSRP syntax elements MUST be as
>>>>>  shown in the following table.
>>>> 
>>>> WFM.
>>>> 
>>>>> = Section 6 =
>>>>> As in Section 5, something is awry with the labels of the protocol flows in this section, both in the diagram and the examples that follow. I believe the first flow in the diagram, SIP INVITE from the SIP user to the SIP proxy, should be F35, not F33.
>>>>> 
>>>>> Then in 6.1 the SUBSCRIBE flow is listed in Example 29 as F40, but it should be F38 as in the diagram. From there, the flow numbers listed in the examples are all off by 1 or 2.
>>>> 
>>>> Yes, we'll check all of these.
>>>> 
>>>>> = Section 6.3 =
>>>>> OLD
>>>>> The mapping of MSRP syntax elements to XMPP syntax elements is as
>>>>>  shown in the following table.
>>>>> 
>>>>> NEW
>>>>> The mapping of MSRP syntax elements to XMPP syntax elements MUST be as
>>>>>  shown in the following table.
>>>> 
>>>> Yes.
>>>> 
>>>>> = Section 6.3.1 =
>>>>> Why does the SIP-to-XMPP gateway send an MSRP 200 OK back to the sender before seeing that the groupchat message has been reflected back? Doesn’t this give the sender the wrong impression in the event that a transport error causes the groupchat message to fail to reach the XMPP MUC?
>>>>> 
>>>>> "In MSRP this reflected message is unnecessary."
>>>>> 
>>>>> What does it mean for it to be “unnecessary”?
>>>> 
>>>> Perhaps that was a poor choice of words. In MSRP, the switch doesn't reflect the message because it is explicitly acknowledged (200 OK). In XMPP, the MUC room doesn't explicitly acknowledge receipt of groupchat messages.
>>>> 
>>>> I think it would be better for the switch + gateway to not generate the MSRP 200 OK until it receives the reflected message back from the MUC room. That is, move F45 after F47 and remove F48 & F49.
>>>> 
>>>>> Why does the MSRP gateway send it (F48 in the diagram)?
>>>> 
>>>> I suggest we remove F48 and F49.
>>>> 
>>>>> = Section 7 =
>>>>> "Implementations are strongly encouraged to apply the
>>>>>  rules for preparation and comparison of nicknames specified in
>>>>>  [I-D.ietf-precis-nickname].”
>>>>> 
>>>>> draft-ietf-precis-nickname is listed as a normative reference. Should its use be a normative requirement?
>>>> 
>>>> Probably.
>>>> 
>>>> If we can ever finish the PRECIS work...
>>>> 
>>>>> "Therefore, for display purposes SIP implementations
>>>>>  ought to use the <display-text/> element if the XCON 'nickname'
>>>>>  attribute is not present, and XMPP implementations ought to use the
>>>>>  resourcepart of the occupant JID if the <nick/> element is not
>>>>>  present.”
>>>>> 
>>>>> Should these be normative requirements?
>>>> 
>>>> I don't think that display name mappings are critical for interoperability.
>>>> 
>>>>> = Section 9 =
>>>>> 
>>>>> I don’t think it’s sufficient to refer to the security considerations of the underlying specifications.
>>>>> 
>>>>> This section omits discussion about whether the gateways needed for groupchat are expected to support the security requirements of the protocols they are gatewaying. The other two drafts address this point and it needs to be addressed here as well.
>>>> 
>>>> Good catch.
>>>> 
>>>>> Same goes for end-to-end security protections — some discussion is needed.
>>>> 
>>>> To my knowledge, end-to-end security protections do not exist for multiparty text chat in MSRP or XMPP MUC. It's a hard problem (even harder than the 1:1 cases for IM and chat).
>>>> 
>>>>> Also, many of the groupchat features that are left unspecified in this draft could be considered to be application security features: room administration, moderation, semi-anonymous rooms/anonymous participation, kicking and banning, etc. It seems at least worth mentioning that implementations supporting the feature set specified here cannot afford users with those features as they may be accustomed.
>>>> 
>>>> Yes, we'll note that.
>>>> 
>>>> Thanks again,
>>>> 
>>>> Peter
>>>> 
>>>> --
>>>> Peter Saint-Andre
>>>> https://andyet.com/
>>>> 
>>>> _______________________________________________
>>>> stox mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/stox
>