Extensible Messaging and Presence Protocol
charter-ietf-xmpp-03

[Ballot comment]


"Finally, the group needs to define a
sustainable solution to internationalization of XMPP addresses, since
the approach taken in RFC 3920 (based on stringprep profiles) is limited
to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so
far regarding these modifications, ...3

I searched all over for these drafts, but could not find them:
http://www.arkko.com/tools/allstats/petersaint-andre.html It's probably some
text referring to RFC 6120 and RFC 6120

[Ballot block]
Easy to be fixed BLOCK.

"Finally, the group needs to define a
sustainable solution to internationalization of XMPP addresses, since
the approach taken in RFC 3920 (based on stringprep profiles) is limited
to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so
far regarding these modifications, ...3

I searched all over for these drafts, but could not find them: http://www.arkko.com/tools/allstats/petersaint-andre.html
It's probably some text referring to RFC 6120 and RFC 6120

[Ballot comment]

I have a question, I'll ask the list but put it here for the
record.

Q: loads of us use OTR, but there's no mention of that
in the charter - why don't we just spec that in an RFC?

Or two RFCs if need be, one for what's done now, one with
any changes the WG think are needed and will be deployed.

A quick web search leads me to believe that this [1]
might be how OTR works, but I could be wrong. Even having
an informational RFC as a stable reference would seem
to be an improvement.

[1] http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html