[Jabber-IETF] Agenda items

Ryan Eatmon reatmon at jabber.org
Wed Oct 9 16:42:13 CDT 2002

Pete Chown wrote:
> Robert Norris wrote:
>> I don't think its a non-compliant use of namespaces, but its certainly
>> unorthodox.
> Right; the XML is well-formed.  Similarly it is not an error to write 
> "typedef int foo" in your C program, then not use foo.  However, IMHO it 
> is inelegant.
> The other problem is that namespaces can be declared on any tag.  This 
> means that (from an XML point of view) it would be legitimate to delay 
> declaring the SASL namespace until it is used.  For example:
> <stream xmlns:sasl=...>
> ...
> <sasl:sasl ...>
> versus
> <stream ...>
> ...
> <sasl:sasl xmlns:sasl=...>

I've spoken with Rob about this a few times before since I also prefer 
the xmlns inside the <sasl/> tag and not in the <stream:stream />. 
Although, my preference is for this:

<sasl xmlns='....' />  Just to make things even simpler.

>> I needed a way for the client to flag to the server that it
>> wanted to do a SASL auth, without breaking existing implementations.
> I agree that this is a problem.  Would adding an attribute to the 
> <stream> tag break existing applications?  For example, we could write:
> <stream version="1.0" ...>
> That would allow us to split off older software from software that 
> complies with the draft we're writing.  Another possibility would be 
> explicit declaration of the schema that the stream conforms too; see:
> http://www.w3.org/TR/xmlschema-1/#schema-loc
> If we went this way, we would have two options.  We could have a schema 
> declared as, for example, "http://jabber.org/xmpp-1.0".  The other 
> communicating party would then know that the features given in the XMPP 
> core draft are supported.  This might include some kind of EHLO mechanism.
> The other alternative would be to declare separate schemas for each 
> component of the protocol, one of which would be SASL.
> Just a few ideas, I'd be interested in hearing people's thoughts.

The other option is to use a negotiation scheme of some sort to find out 
what is supported by the other side.  A programmatic way of asking for a 
feature list, and then using that to start the conversation.  I'm in 
favor of that approach.

The JSF is currently working on consolidating various schemes of doing 
the feature browsing, but nothing is available at this moment in time. 
If it was deemed important to the IETF front though, we could shift more 
focus on finishing those specs up for the WG.


Ryan Eatmon
reatmon at jabber.org

More information about the xmppwg mailing list