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

"Miguel A. Garcia" <[email protected]> Wed, 12 Sep 2012 16:01:56 +0200
Newsgroups gmane.ietf.simple
Message-ID <[email protected]>
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.


>
> /Miguel
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain