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

Correct. That makes it backwards-compatible.

On Sep 11, 2012, at 1:34 PM, Paul Kyzivat wrote:

> On 9/11/12 2:17 PM, Eric Burger wrote:
>> 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).
> 
> Good point.
> 
> So you are suggesting we assume the use of the Content-Disposition header in the CPIM wrapper? And the default is REQUIRED, so the focus should reject the message if it can't be delivered to all recipients and it *doesn't* contain a c-d of OPTIONAL?
> 
> That WFM.
> 
> 	Thanks,
> 	Paul
> 
>> --
>> 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" 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