Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
RFC 4622

Note: This ballot was opened for revision 04 and is now closed.

Lars Eggert No Objection

(Lisa Dusseault; former steering group member) (was Discuss) Yes

Yes ()
No email
send info

(Ted Hardie; former steering group member) Yes

Yes ( for -)
No email
send info

(Bill Fenner; former steering group member) (was Discuss) No Objection

No Objection (2006-03-30)
No email
send info
I slept on this, and decided it's non-blocking.  Anyone who understands the character vs. encoding thing will be able to figure out what's intended.

I'm confused by the description of encoding of a query component.

   If included in an XMPP IRI, the query component MUST first be encoded
   as a [UTF-8] string and then (if necessary) transformed to conform to
   the "iquerycomp" rule specified above

The iquerycomp rule ends up talking about iunreserved, from the IRI spec.  However, iunreserved talks about Unicode code points, not UTF-8 encoded strings.  Taking this literally it sounds like the query component "a⪋a" (where ⪋ is, of course, less-than above double-line equal above greater-than) would first be turned into "a<e2><aa><8b>a" (using the notation from [IRI]) and then made part of the IRI.  I would have thought that the IRI would contain three unicode characters, "a", "⪋", and "a", but this implies that it would have 5 characters, 3 representing characters that are not in the original.

This problem applies to the fragment identifier as well, since the same phrasing is used.

I *think* that what's meant is simply that the sequence of Unicode characters that make up the query or fragment identifier is included in the IRI in as characters, and then the IRI is encoded to whatever character encoding is appropriate.

(Brian Carpenter; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Sam Hartman; former steering group member) No Objection

No Objection ( for -)
No email
send info