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

On 12/09/2012 16:05, Ben Campbell wrote:
>
> On Sep 12, 2012, at 9:01 AM, "Miguel A. Garcia"
> <[email protected]> wrote:
>
> [...]
>
>>>
>>> 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.
>
> WFM. I thought about explicitly mentioning the "*" case, where the
> switch may not learn a format is unacceptable until it tries to send
> it. But on reflection, I think that's covered implicitly. For this
> purpose, the "*" case means everything is acceptable.

Yeah, I thought about adding some text like that, but at the end of the 
day, it will be annotated version of RFC 4575 on accept-wrapped-types, 
meaning, there is no normative text to add. I think we should expect the 
reader to be QUITE familiar with RFC 4975.

Also, I have now added the concept of a policy in the chat room to 
control the Supported Wrapped media type:

	    <t hangText="Supported wrapped media types: ">The list of
	    media types that the MSRP switch accepts in
	    Message/CPIM wrappers sent from participants. This list is
	    included in the 'accept-wrapped-types' attribute of the
	    MSRP message media line in SDP. If the MSRP switch accepts
	    additional media types than those explicitly listed, a "*"
	    is added to the list. A single "*" indicates that the chat
	    room accepts any wrapped media type.

I guess this also hints for what you are saying.

/Miguel


>
>>
>>
>>>
>>> /Miguel
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ Simple mailing list
>> [email protected] https://www.ietf.org/mailman/listinfo/simple
>

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