Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 03 May 2013 09:13:13 -0600

[moving to the STOX mailing list]

On 4/7/13 10:47 AM, Saúl Ibarra Corretgé wrote:
> Hi Peter,
> 
> Are you planning to include mappings for MSRP REPORT chunks and
> XEP-0184 delivery receipts? (not sure if I asked this earlier, I may
> have forgotten).

Hmm. I see that as a more advanced feature, not something that we'd
expect most implementations to support. However, if MSRP REPORT chunks
are widely used then I think it makes sense to define the mapping. I
know that delivery receipts are not all that common in XMPP (yet?).

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 3 May 2013 22:21:45 +0200

> know that delivery receipts are not all that common in XMPP (yet?).

The MSRP REPORT chunk is defined in the core MSRP spec, so all implementations must support it AFAIK. While this is not the case in XMPP, I guess it wouldn't hurt to specify how it should be done, would it?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 05 May 2013 20:18:43 -0600

On 5/3/13 2:21 PM, Saúl Ibarra Corretgé wrote:
>>> XEP-0184 delivery receipts? (not sure if I asked this earlier, I
>>> may have forgotten).
>> 
>> Hmm. I see that as a more advanced feature, not something that
>> we'd expect most implementations to support. However, if MSRP
>> REPORT chunks are widely used then I think it makes sense to define
>> the mapping. I know that delivery receipts are not all that common
>> in XMPP (yet?).
>> 
> 
> The MSRP REPORT chunk is defined in the core MSRP spec, so all
> implementations must support it AFAIK. While this is not the case in
> XMPP, I guess it wouldn't hurt to specify how it should be done,
> would it?

In general, there's a wide range of things we *could* specify. Whether
it makes sense to specify everything now, or in the documents we've been
working on so far, is another question. If a WG is formed, I'm sure we
might have some interesting discussions on this topic. :-)

In part, the question is: how widely implemented is the feature? You
might have noticed that there is a large diff between versions 04 and 05
of draft-saintandre-sip-xmpp-chat. That's because I deleted everything
about negotiation of formal one-to-one chat sessions in XMPP, which is
defined in XEP-0155 but not implemented in any of the clients.

Message receipts (XEP-0184) is more widely implemented, but it's not a
universal feature by any means. Furthermore, I think we'd need to
compare it to the MSRP REPORT chunk to understand if it is really
solving the same problem.

(BTW, while we are chatting about chat sessions, a more popular feature
for which to define mappings might be is-typing notifications.)

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 6 May 2013 10:23:26 +0200

> solving the same problem.

Basically, it allows for end to end acknowledgement of a chunk (when not using partial reports). I had no idea about XEP-0184 but I found it while looking at XMPP traces and I thought it matched the idea of a REPORT, that's why I ended up implementing it in SylkServer :-) However, the XEP says the following: "The recipient simply does not wish to return a receipt for the content message." which means that if a client which does support receipts but choses not to send them leaves us in a weird state in which we don't know if the message was received or not, so I chose to send a negative REPORT back after a reasonable amount of time. But we can look into this later on.

> for which to define mappings might be is-typing notifications.)

Oh, we did that in SylkServer, I can probably propose some text based on how we translated RFC3994 into XMPP chatstates and vice versa, I can send something over next week.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 May 2013 21:25:11 -0600

On 5/6/13 2:23 AM, Saúl Ibarra Corretgé wrote:
>>> implementations must support it AFAIK. While this is not the case
>>> in XMPP, I guess it wouldn't hurt to specify how it should be
>>> done, would it?
>> 
>> In general, there's a wide range of things we *could* specify.
>> Whether it makes sense to specify everything now, or in the
>> documents we've been working on so far, is another question. If a
>> WG is formed, I'm sure we might have some interesting discussions
>> on this topic. :-)
>> 
>> In part, the question is: how widely implemented is the feature?
>> You might have noticed that there is a large diff between versions
>> 04 and 05 of draft-saintandre-sip-xmpp-chat. That's because I
>> deleted everything about negotiation of formal one-to-one chat
>> sessions in XMPP, which is defined in XEP-0155 but not implemented
>> in any of the clients.
>> 
>> Message receipts (XEP-0184) is more widely implemented, but it's
>> not a universal feature by any means. Furthermore, I think we'd
>> need to compare it to the MSRP REPORT chunk to understand if it is
>> really solving the same problem.
>> 
> 
> Basically, it allows for end to end acknowledgement of a chunk (when
> not using partial reports). I had no idea about XEP-0184 but I found
> it while looking at XMPP traces and I thought it matched the idea of
> a REPORT, that's why I ended up implementing it in SylkServer :-)
> However, the XEP says the following: "The recipient simply does not
> wish to return a receipt for the content message." which means that
> if a client which does support receipts but choses not to send them
> leaves us in a weird state in which we don't know if the message was
> received or not, so I chose to send a negative REPORT back after a
> reasonable amount of time. But we can look into this later on.

Well, several times a year someone asks whether XEP-0184 can tell you
whether the recipient actually has read the message, and we tell them
no. If MSRP REPORT chunks make that kind of guarantee, then the two
technologies are not equivalent. XEP-0184 is very careful to specify
what it does and does not provide. :-)

>> (BTW, while we are chatting about chat sessions, a more popular
>> feature for which to define mappings might be is-typing
>> notifications.)
>> 
> 
> Oh, we did that in SylkServer, I can probably propose some text based
> on how we translated RFC3994 into XMPP chatstates and vice versa, I
> can send something over next week.

Great, thanks.

Peter