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

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
>