Chat: questions on 'accept-wrapped-types'

Hi,

the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a 
minimum set of supported types inside the Message/CPIM wrappers.

While I was replying to Stephen Farrell's IESG review, he had a question, 
and that one brought me another one. I am seeking advice as for how to 
proceed.

So, here are the questions:

1) Version -16 of the draft is a bit silent with respect 
'accept-wrapped-types. I first proposed these two paragraphs to be added 
to version -17, however, I have concerns with one of them (see below).

    It is RECOMMENDED that participant endpoints
    add an 'accept-wrapped-types' attribute to the MSRP 'message' media
    line in SDP, where the supported wrapped types are declared, as per
    RFC 4975 procedures [RFC4975].

    The conference focus SHOULD also add an 'accept-wrapped-types'
    attribute to the MSRP message media line in SDP containing the
    supported wrapped types.

My question is... does the conference focus need to add an 
'accept-wrapped-types'? The MSRP switch never interprets the actual 
payload contents, so, for the MSRP switch, the actual payload in instant 
messages is transparent. So, why should the MSRP switch care? Why should 
the focus add an 'accept-wrapped-types' at all?

I propose to replace the initially proposed "SHOULD" with a "MAY" in the 
previous paragraph.


2) Stephen Farrel is questioning what should the MSRP switch do if one 
sender sends an instant message to the chat room, the message containing 
a type (inside Message/CPIM) that not all the recipients can understand. 
In other words, the MSRP switch/focus has received SDP indicating that an 
endpoint supports types A, B, and C. If another participant sends a 
message with type D, what should the MSRP switch do?

Possibilities include:
a) Do nothing; forward the message to D, he should deal with the issue. I 
don't like this, because it is bypassing the MSRP accept-* negotiation.

b) Do not forward the message to this user, but forward to others who 
accept this type. It is possible that the MSRP switch injects a warning 
instant message to the sender, indicating this condition.

c) Reject the message to the sender (i.e., do not forward to any user). I 
don't like this option either, because the poor sender has done nothing 
wrong. Additionally, this is the dictatorship of the minority (a few 
people who do not support a type that will be supported by the majority 
will impose their rules). And it will be so easy to kill a chat room by 
just logging in supporting only weird type that none else supports.

So, probably b) is the less worst of all. Comments?

I also want to highlight that this is a bit theoretical problem. I expect 
most implementations to support all commonly known types. Additionally, I 
expect implementations to add a "*" to indicate support for additional 
types that have not been explicitly listed, in which case, the MSRP 
switch will not do any filter, and it is about the endpoint to render the 
content or not.

Comments?

BR,

          Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain