[Jabber-IETF] Summary

Pete Chown 1 at 234.cx
Sun Oct 13 12:20:32 CDT 2002


As we seem to be getting ready for a new revision of the documents,
here is a summary of some of the issues so far.  In all but one case I
have written some text that I think amends the document in the way
agreed on the list.  Feel free to use it, or not, as you choose.

1.  It would be useful to have clarification of the permitted
     character encodings.

"Software implementing XML streams MUST support the UTF-8 and UTF-16
encodings for received data.  Software MUST NOT attempt to use any
other encoding for transmitted data.  The encodings of the transmit
and receive streams are independent.  Software may select either UTF-8
or UTF-16 for the transmitted stream, and should deduce the encoding
of the received stream as described in [8]."

2.  The purpose of dialback authentication should be clarified.

"Dialback authentication is designed to make message forgery more
difficult, while still allowing flexible routing strategies.  An
organisation may want to have one server which handles inbound XMPP
traffic, while another handles outbound.  When the outbound server
connects to a third party, there needs to be a way to verify that it
is authorised to issue messages on behalf of its organisation.

"This need is satisfied by dialback authentication.  The third party
can connect to the inbound server, which it will find using the DNS.
It can then ask whether a particular stream is coming from an
authorised server.

"Typically the group of servers authorised to represent a domain will
share a MAC key, and this will be used to calculate the dialback key,
described below."

3.  The status of the opening <?xml ... ?> tag should be clarified.

"Note that the prolog to an XML document -- <?xml ... ?> -- is not a
processing instruction.  Applications MAY send a prolog.  Applications
MUST follow the rules in [8] concerning the circumstances in which a
prolog is included in the document."

4.  The protocol should make proper use of the XML namespace
     mechanism.

I haven't written text for this one, because it's bound up with the
SASL issue, so much more complicated.  Let me know if you'd like me to
try, and I will do my best to summarise the issues.

I've just realised something else.  If the namespace issues are
resolved, the second paragraph of XMPP Core section 7.2 should be
deleted.  We probably need, instead, something that tells you what to
do in order to interoperate with current software.

-- 
Pete




More information about the xmppwg mailing list