[Jabber-IETF] Agenda items

Joe Hildebrand 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.

Something like:

<iq id='jcl_1' type='result'>
  <query xmlns='jabber:iq:auth'>
    <username>hildjj</username>
    <digest/>
    <sasl xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
    <resource/>
  </query>
</iq>

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.

-- 
Joe Hildebrand

> -----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 
> 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
> 
> _______________________________________________
> Jabber-IETF mailing list
> Jabber-IETF at jabber.org
> http://jabber.org/cgi-bin/mailman/listinfo/jabber-ietf
> 



More information about the xmppwg mailing list