[Jabber-IETF] Agenda items

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Oct 9 12:37:28 CDT 2002

On 10/9/02 1:40 AM, "Pete Chown" <1 at 234.cx> 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 see what you're saying. I'm a bit concerned about the flexibility of XML
in a wire protocol. As in this example, there are multiple XML compliant
ways of doing the same thing. The KISS principle makes me a bit
uncomfortable with this. I think I'd really prefer to see one particular
XMPP valid format for the packets and namespaces unless someone can show a
concrete benefit for allowing this flexibility.

I know I keep harping on the same issue like a broken record... *sigh* I
just have a bad feeling about the number of possible valid variants coming
back to bite us. Part of the simplicity of the current Jabber
implementations is that jabberd is essentially the rosetta stone for
clients. Practically speaking, there is only one form of tag names,
prefixes, and namespaces in the wild. I'm really worried about a player that
likes to "embrace and extend" coming along (if we allow full XML
extensibility in the core) and exploiting XMPP flexibility to lock everyone
out while claiming compatibility and spreading FUD...

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

I think I'd prefer a version attribute in the opening stream tag.


More information about the xmppwg mailing list