Re: [Stox] review draft-ietf-stox-core

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

Hej Olle, thanks for the review.

On 8/22/13 2:10 AM, Olle E. Johansson wrote:
> 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.

We're focused here on interoperability. I doubt that any SIP software
out there knows what to do with a 'urn:' URI in a SIP request (and I
have no idea what that would mean for communication!).

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

Agreed.

> 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.

Sounds like a good idea.

On the XMPP side, I don't think that many IM clients support the 'im'
and 'presence' schemes.

> 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."

By encoded, do you mean percent-encoded as in RFC 3986?

> 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

Is it quoted-string or pvalue that we care about here? I think it's
pvalue because RFC 5627 defines a new parameter for SIP URIs, as follows:

   uri-parameter   =/ gr-param
   gr-param        = "gr" ["=" pvalue]   ; defined in RFC 3261

However, pvalue does allow Unicode characters outside the ASCII range,
as long as they are encoded:

pvalue            =  1*paramchar
paramchar         =  param-unreserved / unreserved / escaped

So strictly speaking it's only ASCII characters that allowed directly,
although UTF-8 characters outside the ASCII range can be included if
they are percent-encoded.

> 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 prefer the term "percent-encoding" (RFC 3986) to any of those terms.
But yes, the text needs to be clearer.

> 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.

XMPP doesn't have display names in addresses (as email and SIP do),
although those could be translated into a nickname / handle using XEP-0172:

http://xmpp.org/extensions/xep-0172.html

So adding a note about that seems reasonable.

> 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.

Proxy or B2BUA? Someone said B2BUA and that sounds right. If that's
right, then we probably would use 401 and not 407.

> 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.

Oh, there are two kinds of "gone" in XMPP.

One is a chat state:

http://xmpp.org/extensions/xep-0085.html#definitions

The other is a stanza error that maps quite well to SIP 410, I think:

http://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone

> <policy-violation/> should be translated to 403 Forbidden

That sounds reasonable.

> <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.

OK.

> <jid-malformed/> is not a 484. 484 Address Incomplete is used for
> overlapped dialling. Malformed URI should be 400.

OK.

> <not-allowed/> should translate to 403 Forbidden I guess. 

I think that's OK, because XMPP <not-allowed/> is defined as:

   The recipient or server does not allow any entity to perform the
   action (e.g., sending to entities at a blacklisted domain)...

> Needs
> review. 405 indicates that the METHOD is not accepted, like a SIP
> message using PUBLISH to a server that doesn't support PUBLISH.

Right, that sounds more like <feature-not-implemented/> in XMPP.

> <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.

In XMPP the spec doesn't distinguish between those two cases for
<remote-server-not-found/>:

   A remote server or service specified as part or all of the JID of
   the intended recipient does not exist or cannot be resolved (e.g.,
   there is no _xmpp-server._tcp DNS SRV record, the A or AAAA fallback
   resolution fails, or A/AAAA lookups succeed but there is no response
   on the IANA-registered port 5269)...

So I think we need to mention both codes and add some text.

> <remote-server-timeout/> is a 408 Request Timeout.

Sounds right.

> Section 6.2. table 3
> 
> (see above and apply in reverse :-)

Yes. :-)

> 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

Hmm.

The only way to do that would be to use SHIM headers in XMPP:

http://xmpp.org/extensions/xep-0131.html

But those aren't widely deployed.

> 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.

It sounds to me as if we might be defining something new for XMPP, which
it outside of our charter. But perhaps it makes sense to mention
XEP-0131 and sketch out how that would be used.

Peter

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