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

On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" <[email protected]> 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.

I concur. It could use this to express policy about what types it allows, but it could just set it to "*" if it doesn't care.

Do we need to talk about what happens if a _recipient_ does not support a type? I suppose the focus could set accept-wrapped-types based on what all the participants have expressed--but that sounds like a recipe for re-invite storms. The focus could send a 415 response to any type where it knows that that one or more recipients cannot accept 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?
> 

See my previous comment.

I'm on the fence between B and C. It seems like the undetermined state of "some recipients got it but others didn't" is one of the worst outcomes. I'm not sure I agree about the DoS issue--If a participant wants to screw with the conference, there's lots of other ways he can do so. 

Another option would be to push a warning to the recipient saying that the someone had sent a type that he had not expressed support for.


> I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types.

If necessary, we could mandate a must-support leaf type (but I'm not sure if I want to go there.)

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

What happens if the recipient sends a 415 response? I guess it's like any other error. That means the sender doesn't learn about it unless the switch synthesis some sort of warning, right?

I also wonder if switches and/or chat participants should be a little less generous about what types they accept in a chat. Otherwise, this starts to look like a file transfer exploder :-)


> 
> Comments?
> 
> BR,
> 
>         Miguel
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple