Re: [Stox] Review on -im

[Peter Saint-Andre <[e-mail]>]

On 7/31/13 5:07 PM, Saúl Ibarra Corretgé wrote:
> 
> On Jul 31, 2013, at 4:47 PM, Peter Saint-Andre <[e-mail]>
> wrote:
> 
>> On 7/30/13 4:19 PM, Saúl Ibarra Corretgé wrote:
>>> 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.
>> 
>> 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.
>> 
> 
> 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.

>>> - Section 5 only mentions text/plain and text/html, I think we
>>> should 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.
>> 
> 
> 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.

>> (This document might be the place to talk about message receipts,
>> however.)
>> 
> 
> 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/