Subject: [Stox] Review of -chat

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Jul 2013 16:01:43 +0200

Hi,

Here is my review of the -chat document.

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

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

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

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

- In general: we don't have any example using CPIM, not sure if we should say anything about it.

* Editorial nits

- Examples (multiple): the gr parameter is a URI parameter, not a header parameter, so: "To: <sip:[email-masked]>;gr=balcony" should be "To: <sip:[email-masked];gr=balcony>". This applies to both To and Contact headers.

- Sec 1: "using the SIP INVITE and SEND request" -> "using the SIP INVITE and MSRP SEND request"

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Jul 2013 16:06:36 +0200

One more thing: the -chat document doesn't have the detailed DNS lookup mechanism description that the IM document does, I guess it should also contain it, right?

On Jul 30, 2013, at 4:01 PM, Saúl Ibarra Corretgé <[email-masked]> wrote:

> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

--
Saúl Ibarra Corretgé
AG Projects

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 30 Jul 2013 16:09:32 +0200

> One more thing: the -chat document doesn't have the detailed DNS lookup mechanism description that the IM document does, I guess it should also contain it, right?
I would prefer not to duplicate the same text among the different documents
unless there is not some specific DNS lookup detail that is specific for 
chat. Is this the case?

we can maybe think if the right place for the DNS lookup mechanism is IM 
document or we want to have it
in the Core draft

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Jul 2013 17:03:29 +0200

On 7/30/13 4:09 PM, Salvatore Loreto wrote:
>> One more thing: the -chat document doesn't have the detailed DNS
>> lookup mechanism description that the IM document does, I guess it
>> should also contain it, right?

As I recall, we already discussed the topic, starting here:

http://www.ietf.org/mail-archive/web/stox/current/msg00069.html

I think we *might* be able to provide some informational guidance, but I
don't know how strong it can be.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Jul 2013 17:06:12 +0200

> don't know how strong it can be.

But, if we do have text, I think it belongs in stox-core.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Jul 2013 16:37:21 +0200

On 7/30/13 4:01 PM, Saúl Ibarra Corretgé wrote:
> - 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?

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

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

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

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 31 Jul 2013 16:52:39 +0200

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

>   client, the order of events is as follows.

Sounds good to me.

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

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

> 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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 31 Jul 2013 17:09:07 +0200

> SIP entities will implement text/html, can we use that?
Or recommend multipart/alternative if it's a downgrade?
Which document says that SIP Uas will support text/html?

> 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…
Is the closing window notification more than just closing window? Is the chat dead, really?

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 31 Jul 2013 17:16:51 +0200

> Or recommend multipart/alternative if it's a downgrade?

I have never seen multipart used in MSRP and I'd rather not open that door ;-)

> Which document says that SIP Uas will support text/html?

Well, nobody says UAs will support it, it's negotiated with a=accept-types in SDP, but an MSRP client is very likely to implement it, directly or wrapped in CPIM.

> Is the closing window notification more than just closing window? Is the chat dead, really?

My understanding is that chat "sessions" in XMPP is a very loose thing, so you could actually resume it later, but as a concept, if you close the window and you signal that you are "gone" I wouldn't expect further conversation from him. XMPP clients usually say "Olle has left the conversation".

--
Saúl Ibarra Corretgé
AG Projects