Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt

[Ben Campbell <[e-mail]>]

Hi Miguel, see inline. Also, be advised I leave on holiday tomorrow, through 3 Dec, so I might be laggy on email during the next several days.

On Nov 21, 2012, at 4:31 AM, Miguel A. Garcia <[e-mail]> wrote:

[...]

> [
>> 
>>>> If not, what does it mean to include only message/CPIM in
>>>> "accept-types" and not include "accept-wrapped-types"?
>>> 
>>> It means that the endpoint can receive message/CPIM bodies, as
>>> required by this draft, but we don't know which kind of wrapped type
>>> the endpoint supports. Therefore, the MSRP server will not screen
>>> supported media types, and will blindly send all the content to the
>>> endpoint, independently of its media type.
>> 
>> Again, I'm not sure how the endpoint will interpret that. (Maybe the
>> switch only accepts empty message/cpim docs?). If the switch wants to
>> accept anything, but only in a message/cpim wrapper, it should include
>> an accept-wrapped-types with a "*".
> 
> Let's back up a bit an analyze the scenarios. We have two scenarios:
> 
> a) The endpoint declare all its supported media types in the accept-wrapped-types attribute in SDP. The MSRP switch will screen those types, and if the MSRP receives a wrapped media type that this endpoint does not support, it won't forward that e-mail to the endpoint.
> 
> b) The endpoint declares a few of the supported media types, but not all, because it adds an asterisk '*' to the accept-wrapped-types attribute in SDP. Or, alternatively, the endpoint does not declare any supported media types (there is no accept-wrapped-types at all in SDP). In this case, the MSRP switch will not screen the wrapped types in received messages, and will forward all of them to the endpoint. Therefore, the endpoint may receive some media types that is not able to render. This is the same scenario we may have with web browsers today. Some implementations will incorrectly render it in binary, others will point to a plug-in download, etc.
> 
> I don't know what else should we do from the standards point of view, besides what MSRP mandates and does not mandate.

My concern is we seem to allow the case of putting "message/cpim" in accept-wrapped-types, and _nothing_else_. While that doesn't violate 4975, it creates a nonsensical case. That is, it can be interpreted to mean you can only accept message/cpim without content in it. I suppose some implementers might interpret it to mean you can accept message/cpim without restriction, but I don't think that will be universal.

So, if an endpoint or a switch includes message/cpim (or any other envelope type) it needs to also indicate one or more leaf types. It can do that in either accept-types or accept-wrapped-types, and it can wildcard it with a "*". 

So, back to your scenarios, in the case of a), the endpoint needs to put message/cpim in accept-types, and the other media types in either accept-types or accept-wrapped types, depending on whether it wants to _require_ vs _allow_ the use of message/cpim. In case b), the endpoint either puts "message/cpim" in accept-types and "*" in accept-wrapped-types, or it just puts "*" in accept-type, depending on the same question as in a). In no case does it make sense for the endpoint to include nothing but "message/cpim".

It seems to me that we could make this easier by not getting too wrapped around the MSRP mechanics, and state more what the endpoints need to indicate semantically. For example, it seems like a chat endpoint MUST support message/cpim, and MAY require it. If it requires it, it MUST indicate what leaf types it supports, either explicitly or in the form of a wildcard.  A switch MUST support message/CPIM and SHOULD require it. If it requires it, it also MUST indicate what leaf types it supports...

Endpoints and switches use accept-types and accept-wrapped-types to do these things as described in RFC 4975.

>>>> 
>>>> 7.1, third paragraph: "... character may be result encoded in
>>>> more than one octet" do you mean ...: may be as a result
>>>> encoded..."?
>>> 
>>> I meant "may result encoded". Fixed, thanks.
>> 
>> I'm still not clear on what "may result encoded" means. Do you mean
>> "may result in encoding..."?  (Or is result-encoded  a term of art
>> I've missed?)
> 
> Here I am using the term "result" as a verb, not as a noun. The definition of "result" in the Merriam-Webster dictionary is:
> 
> result: to proceed or arise as a consequence, effect, or conclusion. Example: <death resulted from the disease>
> 
> So, I believe "may result encoded" is correct, isn't it?
> 
> 

II get that you are using "result" as a verb. But "result encoded" doesn't parse.  I suggest either "As a result, the character may be encoded..." or "Therefore, the character may be encoded...". Or possibly, "This may result in the encoding of the character..."