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

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].

> 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.

- 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.

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'.

- 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.

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.

	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
>