Re: Chat: questions on 'accept-wrapped-types'

Hi,

On Sep 11, 2012, at 2:46 PM, Miguel A. Garcia wrote:

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

Well, that "never interprets" cannot be guaranteed. I'm toying with an idea for using a specific content type to be used as a control protocol for some specific functionality, for example, so the server would need to interpret it.

Also, in the implementation I've working on, we keep a short history of the messages sent to a room, to give newcomers some context. I don't want to store composing indication chunks and send a newcomer a storm of them, so I'm selective in what I save to this "history".

IIRC private messages sent through the room are actually identified as private after checking the CPIM headers, so checking the From and To headers vs checking the Content-Type in order to validate the wrapped types doesn't make much of a difference, does it?

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

+1 for b.

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

I think someone brought this up further down the thread, but given that this is a specification for "chat" shouldn't this specification mandate a lowest common denominator type (for the focus) such as text/plain ?


Regards,

--
Saúl Ibarra Corretgé
AG Projects