[Stox] review draft-ietf-stox-core

["Olle E. Johansson" <[e-mail]>]

A few comments based on the document and not discussions on the list :-)

5.1

Separate URI schemas defined by SIP and URI schemas the protocol support. SIP supports any URI, and implementations should accept XMPP:, URN: and other schemas - even though there's no requirement to support it.

The "Tel:" URI should propably be mentioned in this section.

In theory I would like to use XMPP: uri's in SIP, but I understand few implementors and implementations would understand this. ;-) I am not sure about the implementation status of IM: and PRES: either, maybe that's something we should add to the questionnaire at SIPit. We do test support of strange URI schemas, like PIZZADELIVERY: 

"IDNs are not allowed in the SIP address format"

I think that's a bit too hard. We don't carry IDNs in the protocol, but support of it is up to the user agent. Would propose: "IDNs are only handled in encoded format in the SIP protocol." 

5.3

Since SIP is declared to be UTF-8 by default, I'm not sure that the gr parameter can only contain ASCII. Im no expert in ABNF parsing, but quoted-string seems to my I can quote UTF-8.
quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
      qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
                        / UTF8-NONASCII
The text in the draft can be parsed to say this, but I would like it to be more clear and add the UTF-8 acronym, so it's clear that it's just transcoding - quoting - but not translating or stripping.
I would also like to mention that Contacts can include display names, like "Olles superduperphone" or "Conference Room Jupiter Phone". I don't know if this can be translated into XMPP.
6.1. Table 2
Yes, this is an art form :-)
I notice that 407/401 is translated to different things. I would propose that we always translate to 401 or that we add both 401/407 to the entries <not-authorized>, <registration-required/> and <subscription-required/>. <
401 is for an endpoint delivering a server, a UAS like a registrar or a b2bua. 407 is for an intermediary like a proxy. A single request can have multiple 407 challenges, but only one 401. After reading mail on the mailing list I think we have gateways considering itself an endpoint and a possible architecture with a gateway that acts more like a proxy.
I'm not sure about the translation of xmpp "Gone" to SIP "410 Gone" either. 410 Gone in sip means that an AOR existed at some point, but is no longer in use and no redirection is possible. XMPP gone seems to me more like someone that left the chat, but is still alive and fine and may show up by the balcony another night.
<policy-violation/> should be translated to 403 Forbidden
<redirect/> to 300 Multiple Choices may be correct, but I would prefer a 302 or 301. I haven't seen many implementations of 300 for redirects, but many using good old 302.
<jid-malformed/> is not a 484. 484 Address Incomplete is used for overlapped dialling. Malformed URI should be 400.
<not-allowed/> should translate to 403 Forbidden I guess. Needs review. 405 indicates that the METHOD is not accepted, like a SIP message using PUBLISH to a server that doesn't support PUBLISH.
<remote-server-not-found/> with a translation to 502 is maybe not fully wrong, but in real life if the DNS entry is there and we can't reach the server, a 408 is sent. If there's no DNS entry at all, a 404 will be sent. Depends a bit on the meaning of this XMPP error code.
<remote-server-timeout/> is a 408 Request Timeout.
Section 6.2. table 3
(see above and apply in reverse :-)
Section 8
I'm happy to see loop detection, but I think we need a way to transport the values across XMPP for the case we have SIP -> XMPP -> SIP
We don't want to loop around or fork in crazy ways in such a network. I can create such a loop easily with Asterisk today. People will end up building this kind of gateway constructs. I don't think we can say "that's not what we intend" since it will happen and possibly already is in use out there. It may be something for another draft, but it will have to be approached at some point.
/O