Re: Chat: questions on 'accept-wrapped-types'
Paul Kyzivat <[email protected]> Wed, 12 Sep 2012 12:07:17 -0400
| Newsgroups | gmane.ietf.simple |
|---|---|
| Message-ID | <[email protected]> |
On 9/12/12 10:01 AM, Miguel A. Garcia wrote: > On 12/09/2012 15:50, Miguel A. Garcia wrote: >> On 11/09/2012 21:24, Paul Kyzivat wrote: >>> On 9/11/12 2:51 PM, Ben Campbell wrote: >>>> >>>> On Sep 11, 2012, at 1:46 PM, Ben Campbell <[email protected]> wrote: >>>> >>>>> >>>>> On Sep 11, 2012, at 1:17 PM, "Eric >>>>> Burger"<[email protected]> 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). >>>>> >>>>> That's an interesting and likely useful approach. I'm concerned >>>>> that it's a bit of feature creep for this draft, though. At least, >>>>> it's a non-trivial feature that the working group had not >>>>> contemplated so far. Mapping rfc3459 to MSRP seems like an effort >>>>> roughly equivalent effort to when we did the delivery status >>>>> notification work for MESSAGE. >>>> >>>> Okay, before anyone jumps on that, on a more careful read of 3459, I >>>> realize it would be less work than DSN. But it's still a substantial >>>> new feature for this late in the draft's life cycle. That doesn't >>>> mean we can't add it if we Really Need It (TM) for the rest of the >>>> draft to be useful. Do we? >>> >>> ISTM that now we are realizing we have had the feature all along and >>> just never realized it. So there is nothing to do other than maybe point >>> out to people that they should do it. >>> >>> Thanks, >>> Paul >>> >>>>> >>>>> Can we live with some implementor guidance that they need to think >>>>> about this, and leave a formal solution as future work if anyone >>>>> wants to do it? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >> >> At this point in time, I believe we don't really understand all the use >> cases and problems that we will get when we introduce the >> Content-Disposition handling parameter. Let me give you one example of >> added complexity: >> >> Alice sends a message to the chat room. The MSRP switch distribute to Bob >> and Charlie, because both indicated an accept-wrapped-types of "*". Bob >> accepts the content, but not Charlie. Charlie "MUST take the appropriate >> failure action " [RFC3459], but which one is it? And then, when the MSRP >> switch receives such 'failure action', what should it do towards the >> sender? And should it wait to aggregate 'failure actions' from several >> potential receivers? >> >> So, let's be pragmatical. We don't have time nor requirements to have >> this sophisticated feature at this late point in time. I will try to >> think of something simple (e.g., discard on error). If someone is >> interested, he or she should collect requirements and write an extension. >> >> Is this reasonable? If so, I will come up with text for review? > > This is the text I propose to add. Please comment. > > When generating a copy of the SEND request to each > participant in the chat room, the MSRP switch MUST evaluate > the wrapped media types that the recipient is able to > accept. This was learned through the 'accept-wrapped-types' > attribute of the MSRP message media line in SDP. If the > current. If the MSRP switch is aware that the media type of > the wrapped content is not acceptable to the recipient, the > MSRP switch SHOULD NOT forward this message to that > endpoint. Note that this version of the specification does > not require the MSRP switch to notify the sender about this > failure. Extensions to this specification may improve > handling of unknown media types. Yes, this works for me. Thanks, Paul