Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt

[Aki Niemi <aki.niemi at nokia.com>]

Inline.

ext Adam Roach wrote:
> By and large, this is far more palatable than previous versions. I'm
> still a little apprehensive about the fact that we will ultimately end
> up with more than one way to send messages to a subset of participants
> (either using the "To" CPIM field *or* using the conference control
> protocol), but I have convinced myself that these mechanisms can
> probably coexist with minimal pain. Time permitting, I'll put together
> some suggested text for your document that talks (in general terms)
> about how these mechanisms can interact with each other in a sane fashion.

That text will be much appreciated.

> I *do* have some of the same reservations as Paul does about nicknames.
> 
> As has been brought up repeatedly: nicknames are most emphatically not
> an IM-only issue. The representation of conference participants is an
> extremely generalizable problem, and I can't as easily see how to
> harmonize two different mechanisms.

What we are essentially doing is creating a new namespace as strictly a
sub-namespace under the conference or chat room name. I think this is
the only reasonable way forward, because nicknames in any other, global
namespace really is a big problem, since that is really more a general
use anonymizing service we end up defining.

> In other words, the nickname reservation protocol that you're defining
> with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My
> suggestion, for what it's worth, is that you (1) split the nickname
> reservation mechanism out into a separate draft, and (2) use either SIP
> or the XCON Conference Control Protocol instead of MSRP.

I think these two are actually reasonable suggestions, as long as the
same disclaimer we have in the draft still holds (namely, scope it for a
particular room only, first-come-first-served policy, defining "sticky"
nicknames out-of-scope, etc.).

As a forward-warning, the current draft talks about sidebars as being
one of the core features of chat rooms of today, but it doesn't define a
mechanism for reserving such sidebars within a chat room. This is
planned for the next version. ;)

Essentially, sidebars within a chat room are similar to nicknames in
that it's simply another sub-namespace to the chat room name. To reserve
a sidebar, we could define a similar mechanism to what's already defined
for nicknames. The only difference (in addition to method name :) would
be that sidebars would presumably need to be both opened and closed.

This proposal didn't make it to the draft, and I was supposed to send
text to the list for a proposal, but haven't until now. Of course, I was
thinking of a pair of OPEN-SIDEBAR, CLOSE-SIDEBAR methods in MSRP, but
surely this could be done with SIP and/or XCON as well. Joining, asking
others to join and leaving sidebars would use SIP INVITE, REFER, and BYE.

> As a minor additional issue: one of the fundamental precepts of the
> conferencing framework (even pre-XCON) was that non-conference-aware
> participants should be able to participate in conferences, albeit with
> less control of the conference itself. To that end, it would probably be
> beneficial to indicate how participants who don't have CPIM clients will
> work.

Good point.

> I think there are sensible ways of addressing this (e.g. if such a user
> sends a message, then the MSRP mixer adds a CPIM envelope that includes
> the user's identity, as learned during session establishment) -- they
> should probably be called out so that implementors of MSRP mixers will
> have some guidance around how they should behave..

Yes, and presumably, the chat server would need to decapsulate the
messages from CPIM and send it in plain text, *possibly* copying the
meta-data from the CPIM header into this plain text message as well.

Cheers,
Aki

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple