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

[Paul Kyzivat <[e-mail]>]

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.

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.)

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.

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.)

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.

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.

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?

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/

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/

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.