Re: [Stox] Review of -chat

[Saúl Ibarra Corretgé <[e-mail]>]

>> 
>> - What should a gateway do when it gets a message with XHTML-IM body?
>> I guess send it with content-type text/html, but is there any
>> translation required?
> 
> I know about the use of XHTML in XMPP, but I don't know much about the
> use in SIP. Is there a profile of (X)HTML that most SIP entities implement?
> 

SIP entities will implement text/html, can we use that?

>> - Section 4 mentions what should happen if no formal sessions are
>> used, but doesn't say anything of the opposite. Should we say that
>> those are out of the scope of this specification?
> 
> Precursors to this document talked about formal chat sessions in XMPP
> (XEP-0155), however no clients support that model so I remove all of
> that text. The first paragraph of Section 4 reflects the earlier specs.
> I think we just need to remove a few words from Section 4...
> 
> OLD
>   When an MSRP client sends messages through a gateway to an XMPP
>   client that does not support formal sessinos, the order of events is
>   as follows.
> 
> NEW
>   When an MSRP client sends messages through a gateway to an XMPP
>   client, the order of events is as follows.
> 

Sounds good to me.

>> - I think we should define a mapping between XMPP chatstates
>> (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the
>> "gone" state in XMPP should trigger a BYE on the SIP side, and vice
>> versa.
> 
> Could you describe a bit why you think that would be useful? (You
> explained it to me in person, but I think it would be helpful to discuss
> it on the list so that it's in the records of the WG. And for the record
> I am pretty sure I agree with you.)
> 

For one, both SIP and XMPP clients usually implement typing indications so translating the semantics between the two is useful to get that information through. Now, as for the 'gone' state case, it's used by XMPP clients when the conversation is closed, so the other party can know that the window was closed on the other side and conversation has ended. Ending a conversation in SIP would mean sending a BYE, and this is particularly useful, because otherwise the SIP / MSRP session would stay up forever since there is no ending condition.

>> - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)?
>> They do map very well semantically. Now, XEP-0184 says that the ack
>> may not be sent if "The recipient simply does not wish to return a
>> receipt for the content message.", which pretty much renders it
>> useless. Anyway, I think we do need some text explaining how MSRP
>> success and failure ports should be dealt with.
> 
> I wonder if this belongs in the stox-chat spec or in an extension document.
> 
> (And BTW XMPP message receipts can be used outside of chat sessions, so
> I think it applies more broadly than the stox-chat spec.)
> 

I didn't know they could be used for other things, but I do think that their use in the context of a chat session should be translated since the meaning they have is basically the same as the MSRP REPORT chunk.

>> - In general: we don't have any example using CPIM, not sure if we
>> should say anything about it.
> 
> What do you have in mind for CPIM examples? Do you mean examples other
> than MSRP, or examples with CPIM payloads?
> 

Examples with CPIM payloads. But I see we have them in the group chat document, so you can skip this point.

--
Saúl Ibarra Corretgé
AG Projects