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

Hi Ben,

Inline comments.

On 05/09/2012 21:05, Ben Campbell wrote:
>
> On Sep 5, 2012, at 9:35 AM, Miguel A. Garcia <[email protected]> wrote:
>
>> I am now addressing the issue with accept-types and accept-wrapped-types.
>>
>> There are two affected sections:
>>
>> Section 5.2 discusses the SDP offer/answer when joining a chat room. The text now reads:
>>
>>           The conference focus of a chat room MUST include support for
>>           a <xref target="RFC3862">Message/CPIM</xref> top-level
>>           wrapper for the MSRP messages by setting the 'accept-types'
>>           MSRP media line attribute in the <xref target="RFC3264">SDP
>>           offer or answer </xref> to include 'Message/CPIM'.
>
> _only_ Message/CPIM, right? Or can other media types be included at the root?

Well, I expect the UA to be common to chat (through chat server) and 
point-to-point instant messaging. If this is the case, the UA will add 
the accept-types including types that are supported and useful for both 
chat and point-to-point IM. Then the MSRP switch will response with only 
Message/CPIM.

So, to summarize, the UA populatse the accept-types with all the formats 
that it supports, including Message/CPIM; the server will reply with 
Message/CPIM. The text to support this reads:

    The conference focus of a chat room MUST include support for a
    Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by
    setting the 'accept-types' MSRP media line attribute in the SDP offer
    or answer [RFC3264] to include 'Message/CPIM'.


>
>> The
>>           actual payload type is negotiated in the
>>           'accept-wrapped-types' attribute in SDP (see <xref
>>           target="RFC4575">RFC 4575 </xref> 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.
>
> Assuming you mean 4975, it looks good. We could mention the use of "*", but I think that's already covered by the reference, and we don't want to restate too much here.
>
>>
>>
>> The other paragraph is in Section 6.1 (Regular messages), when we want to say that the MSRP SEND request needs to use one of the payloads negotiated in the accept-wrapped-types:
>>
>> 	  The SEND request MUST contain a top-level wrapper of type
>> 	  'Message/CPIM' according to <xref target="RFC3862">RFC
>> 	  3862</xref>. The actual instant message payload MUST be
>> 	  included as payload of the 'Message/CPIM' wrapper, and,
>> 	  according to <xref target="RFC4575"> RFC 4575</xref>, it
>> 	  needs to be one of those negotiated in the
>> 	  'accept-wrapped-types' attribute in SDP.
>>
>> Please note that in this last paragraph there is a bug in the current version of the draft. The last sentence incorrectly pointed to the 'accept-types' attribute, rather than the 'accept-wrapped-types'. I believe the proposed text above is now correct.
>
> Looks good, again assuming you mean 4975.

Ouch. Fixed now, yes 4975. I am fixing other similar errors.


Thanks,

      Miguel


>
>>
>> /Miguel
>>
>>
>> On 05/09/2012 9:19, Miguel A. Garcia wrote:
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Section 6.1 (trivial nit)
>>>>>>>>>>
>>>>>>>>>> The SEND request MUST contain a top-level wrapper of type
>>>>>>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862].  The actual
>>>>>>>>>> instant message payload MUST be included as payload of the
>>>>>>>>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the
>>>>>>>>>> SDP 'accept-types' attribute according to the MSRP rules.
>>>>>>>>>>
>>>>>>>>>> I think s/MAY/may/. That is, a type must be set, and the type must
>>>>>>>>>> be only one of those that has been negotiated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> I think this MAY should actually be a MUST, because as you said, a
>>>>>>>> types must be said, and this type cannot be anyone, but it MUST be
>>>>>>>> one of those negotiated.
>>>>>>
>>>>>> This is already mandated in RFC4975 (as you go on to say...). The only
>>>>>> thing new is the normative requirement for a particular wrapper type.
>>>>>> It might be worth commenting that this is accomplished by putting only
>>>>>> Message/CPIM in accept-types, and all allowed leaf types in
>>>>>> accept-wrapped-types.
>>>>
>>>> Ok, we can clarify it. Actually, we do not mention what can go in an
>>>> accept-wrapped-types, because it was obvious that any type can go in. But
>>>> it might be worth adding some explicit mention to it.
>>>>
>>
>> --
>> 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