Subject: [Stox] Reminder WGLC on -im and -chat

From: Yana Stamcheva <[email-masked]>
Date: Wed, 4 Dec 2013 14:17:24 +0100

This is a reminder for the WGLC on:

draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
draft-ietf-stox-chat-03 : http://tools.ietf.org/html/draft-ietf-stox-chat-03

Less than a week left until the deadline December 9, 2013.

If you've reviewed the documents, please don't forget to send a note to the list with any remaining issues you may have found or just that you find the documents complete.

Regards,
Yana Stamcheva

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 08 Dec 2013 12:38:27 +0100

> If you've reviewed the documents, please don't forget to send a note to the list with any remaining issues you may have found or just that you find the documents complete.

Looking good to me, even though I think that numbering the examples 
would be highly appreciated by readers.

table 1: might be worth mentioning that type has no mapping since we're 
only dealing with single instant messages for which this is not set.

table 2: Request-URI or To can map to 'to', right?

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 08 Dec 2013 12:45:14 +0100

> If you've reviewed the documents, please don't forget to send a note to the list with any remaining issues you may have found or just that you find the documents complete.

Looking good to me with just a single comment on section 1:
I think it's worth mentioning that RFC 6121 section 5.1 encourages the 
inclusion of a <thread/> element, which makes it easier to track the 
informal construct.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Dec 2013 14:22:00 +0000

World's shortest reviews to try and sneak past the deadline:

On Wed, Dec 4, 2013 at 1:17 PM, Yana Stamcheva <[email-masked]> wrote:

> <http://tools.ietf.org/html/draft-ietf-stox-im-05 draft-ietf-stox-chat-03>

FWIW, I don't think you could actually do much of this wrong - that is,
beyond -core (and therefore address and error mappings), I suspect
everything else can fall into a quality-of-implementation issue - so as
such, I think this only needs to supply guidance and wisdom rather than
laying down the law - I'm reviewing accordingly.

This largely seems OK.

§6 appears to have interesting mangling of the characters. I think
&amp;#xC3A9; is intended to be &#xC3A9; isn't it?

I think this is an unfortunate choice of notation, actually, because in the
XMPP case this is valid as-is, whereas in the SIP case it needs to be
unencoded UTF-8 - I don't know whether the Content-Type should also include
a charset parameter for SIP.

It may be better to show either C-style or URL escaping of the UTF-8 in the
SIP version, or else a <U+C389>, or something. This will impact the
Content-Length of course.

Security Considerations should probably refer back to -core as well,
shouldn't they?

draft-ietf-stox-chat-03 <http://tools.ietf.org/html/draft-ietf-stox-im-05
> draft-ietf-stox-chat-03> :
> http://tools.ietf.org/html/draft-ietf-stox-chat-03

This draft appears to consist mostly of two giant examples. :-)

However, it seems to be sufficient guidance to build an interoperable
gateway, so I'm happy this is ready - however as with the above, Security
Considerations should probably refer back to -im and -core.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 08:47:12 -0700

On 12/8/13 4:38 AM, Philipp Hancke wrote:
>> draft-ietf-stox-chat-03 :
>> If you've reviewed the documents, please don't forget to send a note
>> to the list with any remaining issues you may have found or just that
>> you find the documents complete.
> 

Yes. The examples in the other documents have numbers, so it's an
oversight that these don't.

> only dealing with single instant messages for which this is not set.

That's true as far as it goes, but I think this document is making the
more general claim that there's no direct mapping of XMPP message 'type'
values (such as "chat", "headline", and "groupchat") to SIP headers.

> table 2: Request-URI or To can map to 'to', right?

Correct.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 09:18:18 -0700

> inclusion of a <thread/> element, which makes it easier to track the

Noted!

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 10:22:06 -0700

> World's shortest reviews to try and sneak past the deadline:

Hi Dave, thanks for the review. Comments inline.

> On Wed, Dec 4, 2013 at 1:17 PM, Yana Stamcheva <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Yes. <![CDATA[]]> is your friend for escaping purposes.

> I think this is an unfortunate choice of notation, 

It's driven by the limitations of the RFC format.

> actually, because in
> the XMPP case this is valid as-is, whereas in the SIP case it needs to
> be unencoded UTF-8 

What is "unencoded UTF-8"? UTF-8 is itself an encoding. Plus, RFC 3261 says:

   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
   [7]).

> - I don't know whether the Content-Type should also
> include a charset parameter for SIP.

Like this?

OLD
Content-Type: text/plain

NEW
Content-Type: text/plain; charset=utf-8

Given that SIP natively "uses the UTF-8 charset", it strikes me that the
charset parameter is unnecessary here.

> It may be better to show either C-style or URL escaping of the UTF-8 in
> the SIP version, or else a <U+C389>, or something. 

I'm not convinced that this is needed.

> Security Considerations should probably refer back to -core as well,

Yes.

>     draft-ietf-stox-chat-03
>     <http://tools.ietf.org/html/draft-ietf-stox-im-05
> gateway, so I'm happy this is ready - however as with the above,
> Security Considerations should probably refer back to -im and -core.

Agreed.

Peter

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