Subject: [Stox] Review on -im

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

Hi,

Here is my review on the -im document:

- Section 3 suggests that the thread element in XMPP should be mapped to the Call-ID header. I see why this was done, but it looks a bit like abusing it. I would probably take it out or define it as a CPIM header, in case CPIM is used. Thoughts?

- Section 5 only mentions text/plain and text/html, I think we should add message/cpim in there.

- Similarly to chat, I think we should define a mapping between XMPP chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but in this case there would be no mapping for the 'gone' state.

* Editorial nits:

- In the examples: From, To and Contact header URIs are not enclosed in angle brackets
- In the example in section 4, the RURI should have the gr parameter as well,as the To header is not used for routing

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Jul 2013 17:54:25 +0200

One more thing: IMHO we should also mention that "headline" XMPP messages should be translated like the normal ones in this spec. Not in -chat though.

On Jul 30, 2013, at 4:19 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: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Jul 2013 18:03:55 +0200

On 7/30/13 5:54 PM, Saúl Ibarra Corretgé wrote:
> One more thing: IMHO we should also mention that "headline" XMPP 
> messages should be translated like the normal ones in this spec.
> Not in -chat though.

Agreed.

Peter

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

---

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

On 7/30/13 4:19 PM, Saúl Ibarra Corretgé wrote:
> - Section 3 suggests that the thread element in XMPP should be mapped
> to the Call-ID header. I see why this was done, but it looks a bit
> like abusing it. 

What are your specific concerns? Would something break? Is it insecure?
Does it horribly violate the semantics defined in RFC 3261? I thought it
was a pretty good match:

   The Call-ID header field acts as a unique identifier to group
   together a series of messages.

But maybe I don't understand the "oral tradition" of how Call-ID has
actually be used.

> I would probably take it out or define it as a CPIM
> header, in case CPIM is used. Thoughts?

I don't see a header in RFC 3862 that we could map to. Our charter says
we're not allowed to define new protocols. Someone could define a new
CPIM header, but I don't think that would be widely adopted anytime soon.

> add message/cpim in there.

No objections here.

> - Similarly to chat, I think we should define a mapping between XMPP
> chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but
> in this case there would be no mapping for the 'gone' state.

The stox-im spec is only for single messages, so I don't see how chat
states apply.

(This document might be the place to talk about message receipts, however.)

Peter

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

---

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

> But maybe I don't understand the "oral tradition" of how Call-ID has

It doesn't horribly violate it, but it's use has been to correlate messages within a dialog, together with the tags. Since MESSAGE requests could come retransmitted when using UDP, duplicated Call-ID detection is a way to avoid it.

> CPIM header, but I don't think that would be widely adopted anytime soon.

I see. In that case I'd go for not really mapping it, but I won't fight to death if you leave it in ;-) However, since this document is for single messages ('normal' or 'headline' in XMPP), not sure if the thread is all that useful. 

> The stox-im spec is only for single messages, so I don't see how chat

Hum, I think you are right, that would apply if we created a -chat equivalent document but mapping chat sessions to SIP MESSAGE it would be useful, but not here, forget it.

> (This document might be the place to talk about message receipts, however.)

Why? These are just one-off messages, aren't they?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Jul 2013 17:13:22 +0200

On 7/31/13 5:07 PM, Saúl Ibarra Corretgé wrote:
>>> - Section 3 suggests that the thread element in XMPP should be
>>> mapped to the Call-ID header. I see why this was done, but it
>>> looks a bit like abusing it.
>> 
>> What are your specific concerns? Would something break? Is it
>> insecure? Does it horribly violate the semantics defined in RFC
>> 3261? I thought it was a pretty good match:
>> 
>> But maybe I don't understand the "oral tradition" of how Call-ID
>> has actually be used.
>> 
> 
> It doesn't horribly violate it, but it's use has been to correlate
> messages within a dialog, together with the tags. Since MESSAGE
> requests could come retransmitted when using UDP, duplicated Call-ID
> detection is a way to avoid it.

Ah, I see.

>>> I would probably take it out or define it as a CPIM header, in
>>> case CPIM is used. Thoughts?
>> 
>> I don't see a header in RFC 3862 that we could map to. Our charter
>> says we're not allowed to define new protocols. Someone could
>> define a new CPIM header, but I don't think that would be widely
>> adopted anytime soon.
>> 
> 
> I see. In that case I'd go for not really mapping it, but I won't
> fight to death if you leave it in ;-) However, since this document is
> for single messages ('normal' or 'headline' in XMPP), not sure if the
> thread is all that useful.

I see your point.

>>> - Similarly to chat, I think we should define a mapping between
>>> XMPP chatstates (XEP-0085) and the iscomosing indication (RFC
>>> 3994), but in this case there would be no mapping for the 'gone'
>>> state.
>> 
>> The stox-im spec is only for single messages, so I don't see how
>> chat states apply.
>> 
> 
> Hum, I think you are right, that would apply if we created a -chat
> equivalent document but mapping chat sessions to SIP MESSAGE it would
> be useful, but not here, forget it.

Agreed.

> Why? These are just one-off messages, aren't they?

Well, the sender might really really want to know if the message was
delivered to the recipient. :-)

My feeling about message receipts is that we leave them out for now and
maybe define a mapping for them in another specification, but I am open
to persuasion on the topic.

Peter

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

---

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

> delivered to the recipient. :-)

Unfortunately there is no way to do that with a SIP MESSAGE. Unless we invent a special payload for acknowledging reception of a given SIP MESSAGE, but I think that is really out of the scope of what we are doing in the IM document.

> to persuasion on the topic.

As I said above we have no way to use them in the -im document, but there is a clear equivalence between the receipt and the MSRP REPORT chunk which we use in -chat. If the SIP endpoint requests success and failure reports, we'd need to fool it by always sending a report, regardless of the acknowledgement of the message (in case receipts are supported). I can live with that if we add some text clarifying she a REPORT should be sent.

--
Saúl Ibarra Corretgé
AG Projects

---

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

> Which you should not do. You should use all of the SIP transaction identifiers - cseq included.
> 

I know. Anyway, as I said, given that this is -im, not -chat, I don't think we should translate it.

> Page mode messages is proper terminology I believe ;-)
> 

Yeah, that!

--
Saúl Ibarra Corretgé
AG Projects

---

From: <[email-masked]>
Date: Wed, 31 Jul 2013 16:24:38 +0000

Hi Saul, Peter,

Saúl Ibarra Corretgé wrote:
> Unfortunately there is no way to do that with a SIP MESSAGE. Unless we
> invent a special payload for acknowledging reception of a given SIP
> MESSAGE, but I think that is really out of the scope of what we are doing in
> the IM document.
> 

Please take a look at RFC 5438 (http://datatracker.ietf.org/doc/rfc5438/) and see if it applies to what would be required.

Markus