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

We solved the three-out-of-four endpoints understand D problem years ago.  
See RFC 3459. UAC's mark the message as critical (gets rejected if unable to  
send to all recipients) or not critical (gets silently dropped or  
destination gets a notice).

--
Sent from my mobile device. Thanks be to lemonade!  
http://www.standardstrack.com/ietf/lemonade/

-----Original message-----
From: Paul Kyzivat <[email protected]>
To: [email protected]
Sent: Tue, Sep 11, 2012 15:33:00 GMT+00:00
Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types'

On 9/11/12 10:23 AM, Ben Campbell wrote:
>
> 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.

+1

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

Isn't that what is discussed below?

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

I prefer B to C. Otherwise you have given each endpoint a veto over what 
can be exchanged. In the extreme, one endpoint could indicate it doesn't 
support either plain text or html and effectively shut down the chatroom.

It is however unpleasant for the sender not to know that some recipients 
didn't get his message.

Perhaps the focus could send a message back to the sender indicating 
that some recipients couldn't receive his message. But this could get 
tiresome if you get this for every message you send. And it's hard to 
decide on what the message type and content should be. I think it is 
better to leave this as an implementation issue rather than a standards 
issue.

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

This has the same issues as sending a message back to the sender. And I 
think I prefer the same solution - leave it as an implementation issue.

Perhaps for both, the draft can carry a note to implementers that they 
might want to consider this.

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

I guess if anything it would be text/plain. But that might exclude 
certain specialized conferences where the messages are consumed by 
automata rather than displayed. (E.g. game systems.)

Again I think it is sufficient as an implementation issue.

	Thanks,
	Paul

>> 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
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple