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