RE: Review of XMPP URI draft (possible encoding issue)

Ted Hardie Wrote: 
> RFC 2718, Section 2.2.5 already sets
> out the recommendation that "unless there is some compelling 
> reason for a particular scheme to do otherwise, translating 
> character sequences into UTF-8 (RFC 2279) [3] and then 
> subsequently using the %HH encoding for unsafe octets is 
> recommended."  

Given the clarity of the recommendation, the steps for resolving an XMPP
URI would then be:
1)	Obtain URI 
2)	Convert from %hexhex format to UTF8
3)	Perform IDNA translation against UTF8 string
4)	Verify UTF8 String passes NamePrep
5)	Resolve server name against DNS
6)	Submit URI to server, and obtain result 

This seems like a fairly reasonable set of steps to perform. 

One more question - the "host" portion of the ID may be 1023 bytes long.
Are there any length limitations in the URI / IRI spec that need to be
resolved against this length? Is this max length long enough to justify
using punycode (IDNA) rather than the %hexhex format - punycode is
designed for efficient encodings, while the %hexhex certainly is not. 

Then the question becomes, how do you submit this beast to the XMPP
server in question, how does that server return a result, and what
happens from there?

--

-- 
Chris Mullins