Re: Comments on draft-saintandre-xmpp-uri-04.txt

Hi Martin,

Thank you for your further review of this document. Comments below.

On Sun, Sep 05, 2004 at 08:52:39AM +0900, Martin Duerst wrote:
> 
> - You still seem to rely a lot on the general statement that an
>   XMPP address is UTF-8. Then in the actual conversion, you often
>   mention only percent-encoding. I'm affraid that some implementers
>   that for some reason e.g. internally use UTF-16 may get things
>   wrong. This in particular applies to 3.3, Character encoding
>   considerations.

I have made more explicit throughout that it is necessary to encode XMPP
addresses or parts thereof as UTF-8 before proceeding further.

> - Related to this, and in many locations, you say
>   "non-US-ASCII characters must be percent-encoded". You have to
>   say something like "non-US-ASCII octets must be percent-encoded"
>   (after you made clear that they are in UTF-8). The same the
>   other way round: replace "by converting each percent-encoded octet
>   into the appropriate reserved or non-US-ASCII character" e.g. with
>   "by converting each sequence of percent-encoded octets into
>   the appropriate sequence of reserved or non-US-ASCII characters
>   by first decoding percent-encoded octets into actual octets and
>   then interpreting the octets as UTF-8".

Fixed. Thanks for the text.

> - I'm wondering whether it is necessary to separate node, host,
>   and path, in the conversion process. Either mention the specific
>   normalization (stringprep) requirements for each of the components,
>   or simplyfy conversion by just converting the whole thing in one
>   go (or tell me why that wouldn't work).

In fact I have added more detail here, e.g., mentioning the specific
Stringprep profiles that must be applied.

> - I'm not happy with the modalities you have used where you describe
>   conversion. You write "it is necessary to use consistent
>   methods" and then "such methods are described below". Then you
>   write "An XMPP "node identifier" *can* be transformed". If this
>   is a *can*, are there other ways? Should other ways produce the
>   same result? I'm affraid of somebody implementing the spec and
>   doing something different and claiming: "well, it said 'can',
>   it didn't say that's the only way, so I choose something else".

Agreed. I have changed "can" to "MUST" throughout (with appropriate
modifications to sentence construction).

> - I like the examples. It would probably be good to have some
>   internationalization in the domain name part, too.

Agreed. I will add this. Is there an internationalized domain that is
reserved for use in IETF specifications (as example.com, example.org,
and example.net are reserved by RFC 2606)? I suppose I can simply use a
TLD of .example as mentioned in RFC 2606.

> - The title "Method" for 2.3.1 and 2.4.1 is extremely generic.

That was the intent. :-) I will change it to something more specific,
such as "URI Generation Method" and "URI Processing Method".

> - In 2.4.1, I think it might help readers to explain that the
>   first few steps of "XMPP handling" are similar e.g. to HTTP
>   authentication, whereas the later steps are similar to what
>   happens e.g. in the case of a 'mailto:' scheme.
>   [I hope I got this right; I think when I was asking in my
>    previous comments about what's really going on, I was trying
>    to find out how the stanza would be composed from data in
>    the URI, but that's not what's happening, similar to the
>    plain use of mailto:, where the user has to compose the
>    message before actually sending the mail.]

It strikes me that this is more appropriate for a document such as the
promised XMPP Implementation Guidelines.

> - You use the 'host' rule from rfc2396bis. This includes IPv4
>   and IPv6 addresses. Are you sure you want these?

Yes, I think that is right.

Once I finish further text adjustments and add the internationalized
domain names to the examples, I will submit a revised version of this
specification to the Secretariat.

Peter

Received on Tuesday, 7 September 2004 21:20:07 UTC