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

On Sep 12, 2012, at 4:01 PM, 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.
> 

+1.

--
Saúl Ibarra Corretgé
AG Projects