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

Hi Ben.

See further discussion below.

On 20/11/2012 16:08, Ben Campbell wrote:
>
> On Nov 20, 2012, at 2:48 AM, "Miguel A. Garcia"
> <[email protected]> wrote:
>
>> Hi Ben,
>>
>> thanks for your comments. See inline answers.
>>
>> On 19/11/2012 22:12, Ben Campbell wrote:
>>> Thanks Miguel. I think this version is much improved. But of
>>> course, here's a few questions and comments:
>>>
>>> Questions:
>>>
[snip]
>
>>
>>
>>> 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.

>
>>
>>>
>>> The last paragraph of 5.2 says that the focus must inform the
>>> switch of the chat room capabilities of each participant, and that
>>> it does this with the SDP "chatroom" attribute. Do we assume
>>> anything about how the focus and switch communicate? I thought the
>>> chatroom attribute was more about how the focus communicates this
>>> with _endpoints_.
>>
>> The communication between the focus (SIP UA) and the MSRP switch is
>> outside the scope of the document. I suspect most implementations
>> implement a single function offering both focus and MSRP switch, in
>> which case standardization is not required. I mean, this is an
>> internal interface.
>
> I agree. But the text appears to say that it uses the SDP chatroom
> attribute to do so. Is that the intent?
>


No, that is not the intent. I will revise this paragraph to clarify that 
this interface is not SDP.

>
>>>
>>> Editorial:
>>>
>>> 6.1, 3rd paragraph: Seems like this paragraph is now redundant due
>>> to the additions in 5.2.
>>
>> Fair enough. In Section 5.2 I have added a reminder of the mandatory
>> nature of the accept-types, and have deleted that redundant
>> paragraph in Section 6.1
>>
>>>
>>> 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?


/Miguel

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