A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)
draft-saintandre-xmpp-uri-08

Last call comments received from Leslie Daigle :

In the context of the current muddle over IDNs, I'm pretty
concerned that draft-saintandre-xmpp-uri-08.txt is opening
the door to a new chapter on pain & heartache in IDNs.

In re-reading it, the current URI spec (RFC3986), and the
IDNA spec, I realize that the document wends its way
legally through the morasse, assuming they are intentionally
and willingly setting the scheme up to have a non-DNS reg-name
host, following RFC3986's definitions.  That is -- RFC3986
is quite clear that domain <-> ascii domain names, but it
is also inclusive of other naming schemes for "hosts", and
that's where the XMPP scheme would fall.

I assume that the authors believe there are more pct-encoding -> unicode
translations in interfaces than there are punycode -> unicode
translations, and that's why they've chosen that form of ascii
encoding in the XMPP URI.  That is, they believe the likelihood
the user will see characters they understand is greater with
pct-encoding than punycode.  Neither is particularly appealing
in raw form.  As a positioning, I'm not convinced it's a good
thing for the IETF to undercut its own IDN encoding by supporting
this in a modern standard.

I am also concerned that this scheme will appear to leverage
more existing tools (software and standards) for manipulating
URIs than in reality it will.  E.g., because it is using
IDNs in a host syntax element, it might appear to leverage parser code.
I.e., the host in the XMPP URI spec is explicitly not a domain name
(per the URI spec), and URI parsers are likely to handle it as
an undifferentiated block of characters.  That may be what the
authors expect -- in anticipation that any software that uses
XMPP URIs is specifically written for the scheme, and will Do The
Right Thing.  There are other schemes that rely on their own
authority component parsing, certainly.  However, are we clear
enough up front that's what this is, that it's valuable as
such, and that there won't be confusion (sticking pct-encoded
data into DNS resolution calls, for eg)?


Overall, this is part of my heartburn that calling IDN's a superset
of domain names is making it very hard for software & protocol
developers to distinguish between which form they are handling,
and when they need to translate between them.  That horse is
already out of the gate, but I wonder to what extent we should
be goading it to run faster?

AD review comments: The ABNF in sections 2.2 and 3.2 contains a few illegal ' (%x27) characters that should be changed to " (%x22) characters.  Why does the ABNF appear twice?  Note to self: is text needed to describe comparison rules for xmpp URIs?