Re: accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)]

Hi Paul:

Thanks for your comments. See inline.

On 10/09/2012 18:00, Paul Kyzivat wrote:
> On 9/10/12 9:20 AM, Miguel A. Garcia wrote:
>> Ben, and the SIMPLE WG:
>>
>> To clarify the usage of accept-types, I propose two paragraphs to
>> Section 5.2 (Joining a chat room). The first paragraph is new and
>> discusses the participant's SDP. Here, I propose not to add normative
>> text mandating the UA to add 'a=accept-types:Message/CPIM' in SDP. The
>> reason is that such normative text would require a mechanism for the UA
>> to know in advance that it is joining a chat room, perhaps by examining
>> the chat room URI. But in general, such mechanism does not exist. The UA
>> will create an INVITE request with SDP, not knowing if at the other end
>> there is a chat room or a regular user. If this SDP contains
>> 'm=message', the attributes included afterwards will be the same, no
>> matter whether the participant is joining a chat room or just another
>> endpoint. Please verify that the proposed words are acceptable:
>> "...needs to include at least...
>>
>>      This participant's INVITE request contains an SDP body.  This SDP
>
> There are possibilities beyond the one mentioned here:
> - the participant might send an INVITE without an offer.
> - the focus might send the INVITE, with or without an offer.
>
>>      body includes the description of MSRP 'message' media line as per RFC
>>      4975 procedures [RFC4975].  This specification requires all instant
>>      messages to be wrapped in a Message/CPIM wrapper [RFC3862],
>>      therefore, the 'accept-types' attribute for the MSRP message media in
>>      the participant's SDP offer needs to include at least the value
>>      'Message/CPIM', otherwise the conference focus will reject the
>>      request.  The actual instant message payload type is negotiated in
>>      the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975]
>>      for details).  There is no default wrapped type.  Typical wrapped
>>      type values can include: text/plain, text/html, image/jpeg, image/
>>      png, audio/mp3, etc.  It is RECOMMENDED that participant endpoints
>>      add an 'accept-wrapped-types' attribute to the MSRP 'message' media
>>      line in SDP, where the supported wrapped types are declared, as per
>>      RFC 4975 procedures [RFC4975].
>
> So how about the following instead?
>
>      This specification requires all instant
>      messages to be wrapped in a Message/CPIM wrapper [RFC3862].
>      Therefore the 'accept-types' attribute for the MSRP message media in
>      both the SDP offer and answer need to include at least the value
>      'Message/CPIM'. If not, the conference focus will reject the
>      request.  The actual instant message payload type is negotiated in
>      the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975]
>      for details).  There is no default wrapped type.  Typical wrapped
>      type values can include: text/plain, text/html, image/jpeg, image/
>      png, audio/mp3, etc.  It is RECOMMENDED that participant endpoints
>      add an 'accept-wrapped-types' attribute to the MSRP 'message' media
>      line in SDP, where the supported wrapped types are declared, as per
>      RFC 4975 procedures [RFC4975].

Your proposed text works for me. I will change it.


>
>> Now, the second paragraph was already present in the previous version,
>> and is now divided into two paragraphs. It tackles the conference focus.
>> I have added text to indicate that the focus must only accept
>> Message/CPIM, and also that the focus should add an
>> 'accept-wrapped-types'. The text reads:
>>
>>      The conference focus of a chat room MUST only use a Message/CPIM
>>      [RFC3862] top-level wrapper as a payload of MSRP messages, and this
>>      needs to be declared in the SDP offer and answer as per regular RFC
>>      4975 procedures [RFC4975].  This implies that if the conference focus
>>      receives from a participant's endpoint an SDP offer that does not
>>      include the value 'Message/CPIM' in the 'accept-types' attribute for
>>      the MSRP message media line, the conference focus SHOULD either
>>      reject the MSRP message media stream or the complete SDP offer by
>>      using regular SIP or SDP procedures (e.g., creating an SDP answer
>>      that sets to zero the port of the MSRP message media line, responding
>>      the INVITE with a 488 response, etc.).
>
>>      If the conference focus accepts the participant's SDP offer, when the
>>      conference focus generates the SDP answer, it MUST set the 'accept-
>>      types' attribute for the MSRP message media line to a value of
>>      'Message/CPIM'.  This specification requires all instant messages to
>>      be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types'
>>      attribute in this SDP body contains a single value of 'Message/CPIM'.
>>      The actual instant message payload type is negotiated in the 'accept-
>>      wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details).
>>      The conference focus SHOULD also add an 'accept-wrapped-types'
>>      attribute to the MSRP message media line in SDP containing the
>>      supported wrapped types.
>
> I'm not sure this says quite what you mean either. Couple of issues:
>
> - I guess the intent is that every message sent to/from the focus is
>     wrapped in Messsage/CPIM. That is easy for messages *from* the focus.
>     But to ensure it for messages *to* the focus I think you are trying
>     to say that the SDP *from* the focus must include *only*
>     message/CPIM in 'accept-types'. I think the MUST is in the wrong place
>     above for that.

Yes, you got the intention of the text. To clarify: SDP sent from the UA 
to the focus need to contain Message/CPIM, but most likely, it will 
contain something else, because the endpoint does not know it is 
connecting to a chat room.

SDP sent from the focus to the UA will only contain an 'accept-types' of 
Message/CPIM, in order to force UAs to send only MSRP messages containing 
Message/CPIM. Therefore, I believe the following MUST is correct:

    If the conference focus accepts the participant's SDP offer, when the
    conference focus generates the SDP answer, it MUST set the 'accept-
    types' attribute for the MSRP message media line to a value of
    'Message/CPIM'.

>
> - I am a little concerned that if you only allow message/CPIM, that you
>     will be cutting off a point of extensibility. Some future extension
>     may need to add something that requires a new mime type here -
>     presumably one that is a functional superset of message/CPIM. But
>     a mandatory requirement to include *only* message/CPIM will exclude
>     such a future focus from being backward compatible with this spec.

I don't think so. Future extensions will update this draft/RFC. We have 
done it this way many times, when some normative text is updated by a 
subsequent document. So, I don't believe we are cutting off extensibility.

>
> ISTM that the desired behavior is:
>
> - if focus is the answerer, and the offer doesn't include message/CPIM,
>     then it can't support this spec on that m-line. It then MUST either
>     reject the m-line, fail the call, or use this m-line in accord with
>     some spec other than this one. (E.g. a future extension.)
>     If the offer *does* include message/CPIM, and the focus wants to
>     use this spec, then it MUST include *only* message/CPIM in
>     'accept-types'.

The above is correct. But I don't want to enter the future extensibility 
trap. We should publish normative statements for this document. Future 
documents will have to update this done in many places, I guess.

>
> - if the focus is the offerer, and wishes to support this spec, then
>     it MUST include message/CPIM in 'accept-types'. It should only
>     include other types in 'accept-types' if there are other alternative
>     specs is is prepared to support.

Yes, modulo the future extensibility issue.

>
> I don't have alternative text for that. It may be hard to write, and I'm
> not going to try unless the above is really the intent.

So, the text is much easier if you don't consider the future 
extensibility now, but leave it as a future exercise. I believe that the 
text in the draft is correct (with the modifications you suggested at the 
beginning of this message).

BR,

         Miguel


>
>          Thanks,
>          Paul
>
>
>> Please indicate if there are problems with the proposed text.
>>
>> /Miguel
>>
>>
>>
>> On 07/09/2012 10:41, Miguel A. Garcia wrote:
>>> On 06/09/2012 22:12, Ben Campbell wrote:
>>>> But the text talks about the what the conference focus sends, not UAs
>>>> in_general_. If the focus includes anything_other_  than Message/CPIM
>>>> in accept-types, it better be prepared to receive it. Is that the
>>>> intent?
>>>
>>> Ben, I see your point. The conference focus MUST only send an
>>> accept-types of Message/CPIM. There is no reason for using any other
>>> value.
>>>
>>> I will revise this text to make clear the intention.
>>>
>>> BR,
>>>
>>>        Miguel
>>
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>

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