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

[Paul Kyzivat <[e-mail]>]

Some followups inline.

	Thanks,
	Paul

Geir Arne Sandbakken wrote:
> Hi Paul,
> 
> Thank you for the review!  Comments inline.
> 
> Thanks,
> Geir Arne
> 
> Paul Kyzivat wrote:

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

I don't necessarily think *that* opens a can of worms.
The issue is if the client must do something unusual to achieve 
anonymity. If this draft is proposing that there be a unique process 
then that needs to be spelled out very clearly. It feels like this has 
been hinted at without really stating what is required.

IMO the thing that would be most straightforward for anonymity would be 
for the UA to simply get an anonymous gruu from its own registrar, or 
get any sort of anonymous URI that suits it from anyplace, and then join 
the conference using that as the From-URI. But then the issue is whether 
it will be allowed to join with an unrecognized identity. I'm assuming 
the approach of getting the gruu from the focus or its domain is to 
solve that problem. But it introduces this new problem that the UA now 
needs to be programmed to use this special mechanism to achieve 
anonymity with the chatroom.

Suggesting that the UA get the gruu from the domain of the chatroom 
rather than from the chatroom itself in a way raises even more issues. 
It implies that a chatroom have a special privileged relationship with 
its domain in order to get access to otherwise restricted information.

The degenerate form of this is to assume that chatrooms are only for use 
by participants with AORs belonging to the same domain as the chatroom. 
I hope that isn't the assumption.

In any case, the key is to very clearly spell out the behavior that is 
required, using normative language where appropriate.

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

OK. That makes perfect sense to me, but I could find nothing that said 
that. Please spell that out. Then the switch need not be concerned with 
authentication.

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

When I authorize you to participate in my conference, I may know you 
will be using an anonymous URI (possibly I will have to authorize you to 
be anonymous), but I most likely will not know what anonymous URI you 
will be using. (Anonymous GRUUs are very volatile, and likely won't be 
assigned until the moment before connecting.)

The most likely scenario I can see here is using digest authentication 
to verify the identity of callers that can't be identified by their From 
URI.

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

Ah. That was not clear. So the only way I will learn your nickname (for 
use in my display of messages from you) is via the conference event package?

I'm fine with that. But can you make that clearer?

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

OK. Thanks!!!