[Jabber-IETF] Agenda items
JHildebrand at jabber.com
Wed Oct 9 17:57:59 CDT 2002
One compromise way, which doesn't require the <stream:stream> to have a
xmlns:sasl, and doesn't break existing implementations, is for the result of
the iq/get/auth to include a flag to tell the client that it can use sasl.
<iq id='jcl_1' type='result'>
Yes, this has the downside of your still having to send the username in the
iq/get/auth, but that's a price we pay for backward-compatibility.
> -----Original Message-----
> From: Ryan Eatmon [mailto:reatmon at jabber.org]
> Sent: Wednesday, October 09, 2002 3:42 PM
> To: jabber-ietf at jabber.org
> Subject: Re: [Jabber-IETF] Agenda items
> 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
> > 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
> Jabber-IETF mailing list
> Jabber-IETF at jabber.org
More information about the xmppwg