Re: [Simple] Fwd: WGLC on draft-ietf-simple-chat-05.txt

Hi Paul,

Thank you for the review!  Comments inline.

Thanks,
Geir Arne

Paul Kyzivat wrote:
>
>
> Hisham Khartabil wrote:
>> Hi Paul,
>>
>> Do you think you can give the chat draft a quick wglc review?
>>
>> Thanks,
>> Hisham
>
> Hisham,
>
> I had missed this. Here is a *quick* review of the document.
> I do find a few things missing.
>
> ISSUES/CONCERNS:
>
> Section 5.2:
>
>    If a participant wants to remain anonymous to the rest of the
>    participants in the conference, the participant's UA can register or
>    acquire by other means a temporary GRUU with the conference focus.
>    The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu
>    [I-D.ietf-sip-gruu].  The temporary GRUU can be used in the From and
>    To header in the 'Message/CPIM' wrapper concealing the participant's
>    SIP AOR from the other participants in the conference.
>
> Does this mean REGISTER with the focus server to obtain a gruu?
> That presumes it will permit such a thing. Because this is somewhat 
> unusual behavior, I think it needs some explanation of what is 
> envisioned. (For instance it seems likely that the client would be 
> registering its *AOR* as a *contact* with the chat room.) Also, this 
> should probably be shown in the call flows.
The wording .."can register or acquire by other means".. is deliberate, 
but as you point out to wage.  I do see that it would be unusual to 
register a temporary GRUU directly with the focus, but it permits having 
a stand alone server supporting anonymous participants.  IMHO the 
vanilla use case would be utilizing a temporary GRUU received from the 
registrar of the domain associated with the focus, and I will add some 
explicit text explaining this.   If registering directly to the focus 
opens a can of worms, we can just remove this possibility.

> Section 6.1:
>
> Do we expect that the sender will always use the same URI used when 
> establishing the dialog with the chat room? Or might it be using 
> something else that must be independently verified by the MSRP switch?
> (I see later in the examples that they do sometimes differ.)
The sender will have a dialog with the conference focus, and the MSRP 
switch must be notified of the URI of which the sender is identified to 
the focus.  The sender must utilize this URI in the From header of the 
CPIM wrapper.   If the sender has multiple dialogs with a focus, the 
MSRP switch will handle each URI independently.

> If it can differ, then I assume the switch only allows certain values 
> to be used. So something needs to be said about how this usage is to 
> be verified.
They can not differ inside a single dialog.

> If it is the URI used when establishing the dialog, and its an 
> anonymous gruu, then hopefully something will be said about how that 
> is verified as being acceptable if the chat room restricts admission. 
> I gather the expectation is that if its an anonymous gruu, then it 
> isn't just *any* anonymous gruu, but only one that was issued by a 
> registrar associated with the chat room, and the mapping to the actual 
> identity is known. (This is also hinted at in 9.6. But not called out 
> explicitly.)
An anonymous GRUU is just like any other URI that a participant is 
authorized to use towards the focus.  I will make the wording more explicit.

> Section 6.3:
>
>    participants URI associated with a participant.  If the URI in the To
>    header can not be resolved (e.g. cased by a mistyped URI or that the
>    recipient has abandoned he chat room), the response error code is
>    427.  The new 427 status code indicates a failure to resolve the
>    recipient URI in the To header field.  If the recipient doesn't
>
> Why is a new error code required? ISTM that the sip 404 code is 
> appropriate here, and could be borrowed into MSRP rather than 
> inventing a new code.
Good idea!  I'll can change the MSRP response code from 427 to 404.

> Section 7.1:
>
> There is good detail of how to request and be granted use of a 
> nickname. But there is no normative language about how to use the 
> nickname once it has been received, either by the sender or the 
> recipient. This goes back to my earlier question about the 
> relationship between the From in MSRP and the URI used to connect to 
> the focus.
The nickname is only used for display purposes, and in-text references 
to participants.  Not used for any message switching - nor in any CPIM 
wrapper headers.

> I later see in the examples, that the nickname is being combined with 
> the domain name of the focus to create a sip uri (with some escaping 
> being done to make it legal). If that is the intent, then it needs 
> better explanation. On the receiving side, I suppose it is intended 
> that the user part of the URI be rendered as the sender, rather than 
> the full URI. But how would the recipient know to do that? It can't do 
> so with all URIs, so how does it know this one is special?
The example is a regular SIP URI, but looks mysteriously like the 
previously example allocated nickname.  I'll rename it to be only "Bob" 
- not to confuse regular readers of RFC's :-)

> This seems to require more technical work to be fully sorted out.
>
> NITS:
>
> Section 6.1:
>
>    An MSRP endpoint that receives a SEND request from the MSRP switch
>    containing a Message/CPIM wrapper SHOULD first inspect the To header
>    field of the Message/CPIM body.  If the To header field is set to the
>    chat room URI, it should render it is a regular message that has been
>
> s/it should render it is a/it should render it as a/
Fixed.
>
> Section 6.3:
>
>    participants URI associated with a participant.  If the URI in the To
>    header can not be resolved (e.g. cased by a mistyped URI or that the
>
> s/cased/caused/
Fixed.
> Section 9.2:
>
>    MSRP d93kswow NICKNAME
>    To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
>    From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
>    Use-Nickname: "Alice the great"
>    -------d93kswow$
>
>      Figure 7: MSRP NICKNAME request with an initial nickname proposal
>
>    F2: The MSRP switch analyzes the existing allocation of nicknames and
>    detects that the nickname "Alice is great" is already provided to
>    another participant by the conference.  The MSRP switch answers with
>    a 423 response.
>
> The nicknames used in the request and response are different.
Fixed.

> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

Thanks again,
Geir Arne