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

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?

/Miguel

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