Subject: [xmpp] Use of namespace in RFC 3920

From: Jehan Pagès <[email-masked]>
Date: Thu, 24 Sep 2009 01:01:40 +0900

Hi,

yesterday I was discussing with Peter about how namespace requirements
were presented in RFC 3920bis, and we both agreed that it is wrong.
The RFC is clearly trying to make an excuse for badly programmed XML
parsers, not able to expand prefixes into namespaces (or keep track of
declared prefix in parent elements). So you MUST absolutely have a
default namespace in the root <stream>, and this one MUST be the one
for the stanza ("jabber:client" or "jabber:server", most typically) +
you MUST have a prefix declared, for the stream related first level
elements, and this prefix MUST be "stream".
So for instance, the current RFC asks me to reject and consider this
stream start as an error, though it is perfectly valid XML and
conforming to XMPP:

<toto:stream
          from=[email-masked]'
          to='im.example.com'
          version='1.0'
          xml:lang='en'
          xmlns='jabber:client'
          xmlns:toto='http://etherx.jabber.org/streams'>

And many other examples: for instance, if I prefer to use a declared
namespace for "jabber:client" instead of a default namespace, why
couldn't I? This is good XML, and what only matters is the final
expanded name (however we got to it). This is all for historical
reasons, for backward compatibility with jabberd 1.0 in "old" times,
as Peter explained me, but we agreed that nowayday, such a stuff
should not be in an RFC, presented as "the good way to do". Probably
it should just become a note of "For historical reasons, some
implementations may require...", so that we still aknowledge this old
issue, but without asking softwares to refuse the other good ways.

There are several parts to change about this. In particular in 12.2

-------------------
12.2.1. Streams Namespace

   A streams namespace declaration is REQUIRED in all XML stream headers
   and the name of the streams namespace MUST be
   'http://etherx.jabber.org/streams'.  If this rule is violated, the
   entity that receives the offending stream header MUST return a stream
   error to the sending entity, which SHOULD be <invalid-namespace/> but
   MAY be <bad-format/>.

   The element names of the <stream/> element and its <features/> and
   <error/> children MUST be qualified by the streams namespace prefix
   in all instances.  If this rule is violated, the entity that receives
   the offending element MUST return a stream error to the sending
   entity, which SHOULD be <bad-format/>.

   An implementation SHOULD generate only the 'stream:' prefix for these
   elements, and for historical reasons MAY accept only the 'stream:'
   prefix.  If an entity receives a stream header with a streams
   namespace prefix it does not accept, it MUST return a stream error to
   the sending entity, which SHOULD be <bad-namespace-prefix/> but MAY
   be <bad-format/>.

-------------------

should probably become something like:

-----------------
12.2.1. Streams Namespace

   The element names of the <stream/> element and its <features/> and
   <error/> children MUST be qualified in all instances by the streams
namespace,
   whose value is "http://etherx.jabber.org/streams".  If this rule is
violated, the entity that receives
   the offending element MUST return a stream error to the sending
   entity, which SHOULD be <bad-format/>.

For historical reasons, some older implementations may accept only a
stream element qualification through a prefix named "stream" (and not
for instance through a default namespace, nor a prefix named other
than "stream"), declared in the initial <stream/> element. For
backwards compatibility, it may therefore be a good idea, though not
mandatory, to declare a prefix named "stream" and with value
"http://etherx.jabber.org/streams" in the <stream/> header. However an
implementation MUST NOT send any error, hence reject a stream doing
differently, as long as the qualified names for the <stream/>,
<features/> and <error/> element are correct with this alternative
method.
-----------------------------

Then I would change the next section:

-----------------------------
12.2.2. Default Namespace

   A default namespace declaration is REQUIRED and defines the allowable
   first-level children of the root stream element.  This namespace
   declaration MUST be the same for the initial stream and the response
   stream so that both streams are qualified consistently.  The default
   namespace declaration applies to the stream and all first-level child
   element sent within a stream unless explicitly qualified by the
   streams namespace or another namespace.

   A server implementation MUST support the following two default
   namespaces:

   o  jabber:client -- this default namespace is declared when the
      stream is used for communication between a client and a server
   o  jabber:server -- this default namespace is declared when the
      stream is used for communication between two servers

   A client implementation MUST support the 'jabber:client' default
   namespace.

   If an implementation accepts a stream that is qualified by the
   'jabber:client' or 'jabber:server' namespace, it MUST support the
   common attributes (Section 9.1) and basic semantics (Section 9.2) of
   all three core stanza types (message, presence, and IQ).

   For historical reasons, an implementation MAY refuse to support any
   other default namespaces.  If an entity receives a stream header with
   a default namespace it does not support, it MUST return an <invalid-
   namespace/> stream error.

   An implementation MUST NOT generate namespace prefixes for elements
   qualified by the default namespace if the default namespace is
   'jabber:client' or 'jabber:server'.

      Note: The 'jabber:client' and 'jabber:server' namespaces are
      nearly identical but are used in different contexts (client-to-
      server communication for 'jabber:client' and server-to-server
      communication for 'jabber:server').  The only difference between
      the two is that the 'to' and 'from' attributes are OPTIONAL on
      stanzas sent over XML streams qualified by the 'jabber:client'
      namespace, whereas they are REQUIRED on stanzas sent over XML
      streams qualified by the 'jabber:server' namespace.

   An implementation MAY support a default namespace other than "jabber:
   client" or "jabber:server".  However, because such namespaces would
   define applications other than XMPP, they are to be defined in
   separate specifications.
-------------------

As follow:

------------
12.2.2. First Level Namespaces

On first level, an implementation MUST understand the children element
<features/> and <error/>, qualified by the stream namespace
"http://etherx.jabber.org/streams" (see previous section) as well as
other first-level children defined by implementation choice.
These allowable first level children, other than the ones qualified by
the stream namespace, must be qualified by specific namespaces
grouping them into a common semantic applications. Such first level
children are called the stanzas.

   A server implementation MUST support the following two default
   namespaces:

   o  jabber:client -- this namespace qualifies core stanzas when the
      stream is used for communication between a client and a server
   o  jabber:server -- this namespace qualifies core stanzas when the
      stream is used for communication between two servers

   A client implementation MUST support the 'jabber:client' default
   namespace.

   If an implementation accepts a stream that is qualified by the
   'jabber:client' or 'jabber:server' namespace, it MUST support the
   common attributes (Section 9.1) and basic semantics (Section 9.2) of
   all three core stanza types (message, presence, and IQ).

   For historical reasons, an implementation MAY refuse to support any
   other stanza namespace.  If an entity receives a first level
element qualified
by a namespace it does not support, it MUST return an <invalid-
   namespace/> stream error. In an entity receives a first level
element qualified by
a namespace it supports, but whose local name is not defined in this namespace,
it MUST return an <unsupported-stanza-type/> stream error.

      Note: The 'jabber:client' and 'jabber:server' namespaces are
      nearly identical but are used in different contexts (client-to-
      server communication for 'jabber:client' and server-to-server
      communication for 'jabber:server').  The only difference between
      the two is that the 'to' and 'from' attributes are OPTIONAL on
      stanzas sent over XML streams qualified by the 'jabber:client'
      namespace, whereas they are REQUIRED on stanzas sent over XML
      streams qualified by the 'jabber:server' namespace.

   An implementation MAY support stanzas qualified by namespaces other
than "jabber:
   client" or "jabber:server".  However, because such namespaces would
   define applications other than XMPP, they are to be defined in
   separate specifications.

--------------

There are other stuffs to change in the RFC related to this
problematic. But for now let's launch the discussion from this point.
:-)
Bye.

Jehan

---

From: Jack Moffitt <[email-masked]>
Date: Wed, 23 Sep 2009 10:22:36 -0600

> stream start as an error, though it is perfectly valid XML and

I am +1 on fixing this stuff.

This might also be a good time to bring up the XML-NAMES
well-formedness issues and address those as well.  I'd have to go back
and look at what the consensus (if any) was for that.  But I seem to
recall a proposal that suggested we disallow other prefixes in the
top-level stream element and not throw XML parse errors on namespace
well-formedness issues.

jack.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Sep 2009 10:59:00 -0600

> top-level stream element and not throw XML parse errors on namespace

I posted about that on August 14:

http://www.ietf.org/mail-archive/web/xmpp/current/msg00155.html

I think that the text I posted incorporates the list consensus, so I'd
be curious to see if others agree.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Wed, 23 Sep 2009 18:11:31 +0100

On Wed Sep 23 17:01:40 2009, Jehan Pagès wrote:
> declared prefix in parent elements).

It's also opening the door for heavily optimized pathways which elide  
reserialization and all sorts.

>  So you MUST absolutely have a
> for the stanza ("jabber:client" or "jabber:server", most typically)

Right, this allows us to detirmine whether it's a client, server, or  
component. We actually do this - so if you want to, you can point  
clients, components, and servers alike at a single port and it'll all  
just work.

If we didn't do this, we'd need some additional signalling to  
distinguish, or else we'd have to use distinct TCP ports for all  
three, which seems suboptimal, especially when we're already using  
this quite happily.

>  +
> elements,

Well if you've already got a default namespace, it stands to reason  
you can't have the stream top-level elements in it.

>  and this prefix MUST be "stream".

I don't care about this, and FWIW, we do not rely on it. Also, it's a  
SHOULD not a MUST, and a MAY rely on. The latter, I think, needs  
changing - this should be SHOULD (because of legacy systems) and MUST  
NOT rely on.

>           xmlns:toto='http://etherx.jabber.org/streams'>
No, the RFC says you MAY reject it. Section 11.2.1 says so.

> couldn't I?

See above. Various other things, like XEP-0220, get triggered by the  
default namespace choice of the initiator of the stream.

> <features/> and <error/> element are correct with this alternative

"it may therefore be a good idea, though not mandatory" = SHOULD.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Remko Tronçon <[email-masked]>
Date: Wed, 23 Sep 2009 19:28:05 +0200

> If we didn't do this, we'd need some additional signalling to distinguish,
> or else we'd have to use distinct TCP ports for all three, which seems
> suboptimal, especially when we're already using this quite happily.

The 'correct' way is probably to use doctypes on the XML stream, but
let's not go there. I'm in favor of keeping default namespaces on the
toplevel element of the stream, as a way to distinguish the type of
stream.

I also agree that the namespace prefix shouldn't be mandatory.

cheers,
Remko

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 24 Sep 2009 02:47:00 +0900

Oups sorry, this message went only to Dave, not the whole list. :-)

Jehan

---------- Forwarded message ----------
From: Jehan Pagès <[email-masked]>
Date: 2009/9/24
Subject: Re: [xmpp] Use of namespace in RFC 3920
To: Dave Cridland <[email-masked]>

Hi,

On Thu, Sep 24, 2009 at 2:11 AM, Dave Cridland <[email-masked]> wrote:

> component. We actually do this - so if you want to, you can point clients,
> components, and servers alike at a single port and it'll all just work.
>

I don't really see the problem. This can be seen also on the received
stanza, which is the same thing. I don't tell we stop using namespace, but
that telling they MUST (or SHOULD) be done on such specific way does not
seem right to me. What matters, in my logic, is just the finale qualified
name of stanza, which means the tuple (namespace, local name). So you can
still redirect clients, components and servers to the same port. And you
will still distinguish them with the finale qualified name (however it has
been qualified: default ns, prefix, etc.).

> Well if you've already got a default namespace, it stands to reason you
> can't have the stream top-level elements in it.
>

No, I don't say that it is not a logical way to do. I just say that there
are others and that the RFC should not force to do a specific way. For
instance, you could imagine that you set the stream ns as the default ns and
declare a prefix for "jabber:client" (or "jabber:server", or whatever) and
use this prefix in the stanzas, instead of doing the opposite. I just say it
should not matter, as at the end, what matters is the qualified name.

> SHOULD not a MUST, and a MAY rely on. The latter, I think, needs changing -
> this should be SHOULD (because of legacy systems) and MUST NOT rely on.
>

Ok right this is a "SHOULD", not a "MUST". But "SHOULD" is still a strong
"recommandation". This is for me different than saying that legacy systems
were doing a check on this, so it is a good idea tocontinue to use the name
"stream"

>>  No, the RFC says you MAY reject it. Section 11.2.1 says so.

Yes. We MAY, you are right. I am not forced. Still, the RFC tells me it is
perfectly good (yet not mandatory, I agree) to refuse a perfectly well
formed (and valid) XML, which conforms to the XMPP DTD, namespace choices,
and so on. I personally don't think this is really nice.

> default namespace choice of the initiator of the stream.

Yes. And I agree, but my answer is the same: I don't see the difference of
getting namespace on the stanzas themselves.

> "it may therefore be a good idea, though not mandatory" = SHOULD.
Yes. I agree globally. But I still think this "SHOULD" is too strong, so not
exactly the same. Note also that what I added is that I removed the
possibility of the error. That's for me the main point. So yes we can keep
it a "SHOULD", but it must not prevent from doing another way, perfectly
XML-compliant.

Bye.

Jehan

---

From: Matthew Wild <[email-masked]>
Date: Wed, 23 Sep 2009 21:38:57 +0100

> I also agree that the namespace prefix shouldn't be mandatory.

Simple +1 from me, since every implementation seems to be handling
these issues differently right now (either disallowing, or trying to
work around) it would be good to have official clarification.

Matthew

---

From: Curtis King <[email-masked]>
Date: Wed, 23 Sep 2009 21:42:47 -0700

On 2009-09-23, at 9:01 AM, Jehan Pagès wrote:

> :

What does this all gain us? I think there needs to-be a real benefit  
to making such a change and I don't see one. Only a lot of potential  
pain. IMHO, we should be tightening the scope of XML which can be sent  
not loosening it.

ck

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 24 Sep 2009 17:06:36 +0900

Aaargh, sorry! Once again not to the list. I am really not used to
mailing list, sorry for this.

---------- Forwarded message ----------
From: Jehan Pagès <[email-masked]>
Date: 2009/9/24
Subject: Re: [xmpp] Use of namespace in RFC 3920
To: Curtis King <[email-masked]>

Hi,

On Thu, Sep 24, 2009 at 1:42 PM, Curtis King <[email-masked]> wrote:
>
> What does this all gain us? I think there needs to-be a real benefit to
> making such a change and I don't see one. Only a lot of potential pain.
> IMHO, we should be tightening the scope of XML which can be sent not
> loosening it.
>

That's indeed what I am doing. Right now XMPP is not really following
XML rules. It made new ones, and make it more difficult.
Let's make the example from my experience. I am writing currently an
XMPP library, and I wrote also an XML library. My XML library, like
most of the others I have tried (the one which deals well with XML and
XML namespace RFC, at least), does expand the name of XML elements
into qualified names. So honestly it doesn't care how it has been
expanded, not does XML by definition. The problem is that the XMPP RFC
does. And this is problematic and a lot of pain for me.

If I want to really do like the XMPP RFC proposes, I should modify my
XML parser with surcharge about where a namespace has been declared or
set as default. This is what is lot of pain, according to me.
This is the current XMPP RFC which tightens XML and make its use
painful, not the opposite.
Bye.

Jehan

---

From: Remko Tronçon <[email-masked]>
Date: Thu, 24 Sep 2009 10:38:25 +0200

> XML rules. It made new ones, and make it more difficult.

As far as i remember, XMPP is following XML rules, but only made them
stricter, such that the parsers were simpler (i.e. didn't have to deal
with full XML spec). This implies that the serializers have to play by
some rules (which isn't so bad, since serializing doesn't necessarily
need an XML library).

I don't really see why you would need to modify your XML parser to
handle XMPP if it can handle XML, but maybe I'm missing something.

cheers,
Remko

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Sep 2009 09:45:40 +0100

> handle XMPP if it can handle XML, but maybe I'm missing something.

You need to find out what the default namespace is bound to.

You can do this by concatenating a dummy element early on, if needs  
be - so you insert a "<tracer/>", then look to see what namespace it  
ended up with.

The serializer need to be able to explicitly set the default  
namespace, instead of shoving everything under ugly machine generated  
namespace prefices.

But this assumes that your XML library doesn't simply allow you to  
lookup, and set, the default namespace prefix anyway - I can't really  
believe that this would be unusual, given that it's useful for  
producing compact serialized output in many cases.

Dave.

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 24 Sep 2009 20:10:37 +0900

Third message, third same reply mistake. I know: I am stupid.

---------- Forwarded message ----------
From: Jehan Pagès <[email-masked]>
Date: Thu, Sep 24, 2009 at 8:01 PM
Subject: Re: [xmpp] Fwd: Use of namespace in RFC 3920
To: Remko Tronçon <[email-masked]>

Hi,

> some rules (which isn't so bad, since serializing doesn't necessarily

you are right. But I think this may have been considered simpler some
time ago, maybe depending on the state of the art of XML parsers and
serializers at that time. But nowaydays, it does not look to me that
these XMPP particularities make parsing/serialization really simpler
or better than the basic XML way. Or maybe I don't see the point. I am
not an expert of all what has been done on XML and on all the kind of
optimizations that can be done. Just as of for now, I don't see how
easier/faster/better these particularities make XML parsing, nor
serialization, compared to the more general way of XML.

f you have any link about how some of your implementations may use
such namespace particularities of XMPP to optimize parsing or
serialization, I would be happy to read on. Maybe there can be
something that I don't get, and then I may understand better your
reticence to change.

For my own, the XML I send still follow these rules anyway. But what
bothers me the most is that we are asked (some MUSTs), or encouraged
(some SHOULDs), to reject some well-formed (in the meaning of XML
namespace) and valid XML, even though it corresponds to XMPP DTD. This
is why it does seem more like a patch on the RFC (instead of on codes)
to make developper's life easier (or not: for me, not even). That's
does not look like the best way.

> handle XMPP if it can handle XML, but maybe I'm missing something.

In fact when I parse the XML stream, I just keep the namespace
context, but I remove the namespace prefix declarations and default
namespaces after having used the information for expansion. At the
time I was writing the XML parser, it was looking the cleaner way
because the (default and prefix) ns declarations are not meaningful
attributes outside of name qualification. So they become just useless
(if not attribute pollution) once the namespace expansion has been
done.

Then I wrote the XMPP parser based upon my XML parser, hence the XMPP
parser gets the qualified name directly. I could change it of course
and let the ns declarations into the attributes. It is not as though
it was particularly difficult. But then I add an additional, though
useless, complexity (check not only the qualified names, but also how
they have been qualified) to my XMPP parser + the fact that I still
don't see any reason for this + the fact that I will be refusing
well-formed and valid XML (so by principle, it is also annoying: XMPP
namespace usage are not following the W3C recommandations).
Bye.

Jehan

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Sep 2009 16:03:57 +0100

> namespace usage are not following the W3C recommandations).

<foo/> is also well-formed XML. You - hopefully - reject that too,  
because it's not valid XMPP.

The spec says very little - intentionally - about the validity of the  
XML involved.

Dave.

---

From: "jehan.marmottard" <[email-masked]>
Date: Fri, 25 Sep 2009 00:35:48 +0900

Hi,

On Fri, Sep 25, 2009 at 12:03 AM, Dave Cridland <[email-masked]> wrote:
>
> <foo/> is also well-formed XML. You - hopefully - reject that too, because
> it's not valid XMPP.
>

I do. But what bothers me is more that I am asked to refuse such
opening stream for instance:

 <stream:stream
          from=[email-masked]'
          to='im.example.com'
          version='1.0'
          xml:lang='en'
          xmlns:client='jabber:client'
          xmlns:stream='http://etherx.jabber.org/streams'>

If the sender expects to send prefixed stanzas is an example:
"<client:message ..." Why a program would do that? I don't know and I
don't care because I expand the namespace, as required by the XML
namespace recommandation. So this is transparent for my
implementation. But for some strange reason XMPP wants me to make some
kind of exception:

---

   A default namespace declaration is REQUIRED [...]
---

Another example is this:

 <stream
          from=[email-masked]'
          to='im.example.com'
          version='1.0'
          xml:lang='en'
          xmlns:client='jabber:client'
          xmlns='http://etherx.jabber.org/streams'>

----

----

This is perfectly valid as for namespace qualification, but the RFC
"REQUIRES" a stream namespace declaration (why is a default ns for
stream not good? Once again this should be transparent).
Etc.

> The spec says very little - intentionally - about the validity of the XML
> involved.

Yes but it says these stuffs about how the namespaces MUST or SHOULD
be declared or set default, which I don't understand.

By the way, to come back to the example of the use of the default ns
as a "signal" for knowing if it is a client/server/component, I
already answered that you get this information anyway immediately
after (through a stanza).
But in fact I thought afterwards: you also get it in the stream
header, even without the default ns to "jabber:client/server". You get
this information from the "from" attributes:
- if there is no "from" attribute, then it is definitely a client, as
a server must set a "from".
- if there is a "from", then you know anyway your users, so you can
see if it is a client or a server.

But even without this, we still get all the necessary information on
the stanza qualified name anyway.
Bye.

Jehan

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 24 Sep 2009 09:41:50 -0600

> But for some strange reason XMPP wants me to make some
> kind of exception:

The reason is not strange at all.

If you have a namespace prefix in one stream header, it must be in
another where it is used.  So if you allow arbitrary XML like you have
proposed there, then every server will have to translate from one
representation to another.  This means a complete parse and
reserialization cycle at each point.

If we all agree on a default namespace, this is not required, and is a
huge gain in efficiency.  Now XMPP servers don't even have to parse
stanzas.  They can simply regex out the to/from attributes and pass
the stanza on as a bag of bytes.

The <stream:stream> prefixes aren't really that big of a deal because
they are only between two endpoints and don't leak out to other
places, which is why I think it's ok to relax those.

jack.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Sep 2009 16:49:31 +0100

> the stanza on as a bag of bytes.

Not that you can actually do quite that, but it's certainly true you  
can get a lot closer to lexing than parsing, and remove potentially  
all the reserialization.

Dave.

---

From: Pedro Melo <[email-masked]>
Date: Thu, 24 Sep 2009 17:00:32 +0100

> reserialization cycle at each point.

+1.

> the stanza on as a bag of bytes.

-1 :)

You still need to at least lex it to make sure that it is well-formed  
XML.

But yes, after that you should be able to pass along the entire string  
buffer.

> places, which is why I think it's ok to relax those.

Also, by placing the stanzas that do cross XML streams (presence,  
message, and iq) in the default namespace, you can transport the  
string buffer without further processing.

That another reason not to declare extra namespaces in the <stream>  
opening node that would be used inside stanzas.

Best

---

From: Kevin Smith <[email-masked]>
Date: Thu, 24 Sep 2009 17:49:26 +0100

I don't have anything to add to this discussion, I'd just like to
plant my flag in the "Show me some benefit to this before we consider
breaking a large proportion of running server code" camp.

/K

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 24 Sep 2009 11:18:10 -0600

(in my role as individual, not as chair)

On 9/23/09 11:47 AM, "Jehan Pagès" <[email-masked]> wrote:

> are others and that the RFC should not force to do a specific way.

The RFC should promote interoperability, and backwards-compatibility is a
goal from the charter.

> For

As long as your server has not been coded to check the first byte of the
element name for fast routing decisions.  I know of at least two servers
that do this.

-- 
Joe Hildebrand

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 24 Sep 2009 11:29:26 -0600

> element name for fast routing decisions.  I know of at least two servers

Surely it's not that much less efficient to check the first byte
following the ':' instead?  This does at least provide a good reason
why it was set in stone to begin with.

jack.

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 24 Sep 2009 12:39:46 -0600

> why it was set in stone to begin with.

A) it's a backward-compatibility issue
B) the ':' is not at a fixed offset, so you have to scan up to it.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Sep 2009 12:42:46 -0600

> B) the ':' is not at a fixed offset, so you have to scan up to it.

The original jabberd server code looks to see if the element begins with
"<m" for message, "<p" for presence, and "<i" for IQ...

Not that that's the right thing to do, mind you.

/psa

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 26 Sep 2009 03:07:40 +0900

Hi all,

> breaking a large proportion of running server code" camp.

Ok I don't really know what to answer now. The fact is that I
understand your answers and your reasons. There appears to be some
kind of "heavy" optimizations on some current usage which requires
apparently to be very liberal with XML (the example of just checking
first letter for instance). After this I still wonder, first, of much
these optimizations are that efficient compared to a more common
parsing method. But this is not that easy to say, so let's not make a
point of it...

Furthermore I wonder how much they can be considered "good" (but
"good" is often a pretty subjective word, even on technical topics).
On a strict "good design" point of view, the first-letter-check for
instance seems to me far too liberal on the strictness of XML. As
Peter said on his last email "Not that that's the right thing to do,
mind you.".

But still it exists. And apparently on at least 2 implementations, as
Joe said. So we don't want to break this. It is clear. Then I would
say 2 things:

1/ Still I know there are still a lot of softwares doing normal
parsing/reserialization. For them the modification would not be that
hard (remove the additional tests). Moreover it looks to me that these
restrictions are helpful to implementations wishing to make such kind
of very big shortcuts/optimizations (like checking a single byte
instead of a whole name) but are at the opposite a burden for the ones
which don't (making additional tests. That's not like very big burden,
but still it is useless).

2/ It is not as though it would suddenly break all implementations.
The RFC should still recommend (with SHOULD) to have a prefix named
"stream", to define it in the opening stream tag, and to have a
default namespace in this same tag. And people will most probably
follow these recommendations anyway, at least because they don't want
to be broken against some big servers using old implementations.
But at least the RFC is clean (I like clean designs) and this kind of
checks can be slowly removed from code bases in time (and never made
on new codes). No need to hurry. No need any "code camp". That's not
going to change our lives or make all implementation suddenly
obsolete. It will be just a "minor bug" which probably will never be
noticed by users.

But if that's not enough, I don't know what to say more.
Bye.

Jehan

---

From: Justin Karneges <[email-masked]>
Date: Fri, 25 Sep 2009 11:27:37 -0700

> obsolete. It will be just a "minor bug" which probably will never be

Agree.

At this point, I figure a good number of us are using off-the-shelf, compliant 
XML parsers, and so I would like to see the XML generation rules relaxed.  We 
can keep all of the backwards compatibility stuff marked with SHOULDs.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Sep 2009 16:56:35 -0600

> were presented in RFC 3920bis, and we both agreed that it is wrong.

I think that some points need to be clarified, but I do not agree with
all of your conclusions.

> for the stanza ("jabber:client" or "jabber:server", most typically) +

I see no reason to relax this restriction. Among other things, it would
break most XMPP implementations, which seems like a bad idea.

> you MUST have a prefix declared, for the stream related first level

As Dave pointed out, that falls out from having a default namespace.

> and this prefix MUST be "stream".

This is SHOULD in the spec. However, I think we can relax it to say only
that an implementation MAY accept only "stream:" as the prefix. You can
draw your own conclusions about whether you ought to set the prefix to
"stream:" in your implementation (e.g., to avoid interoperability problems).

Peter

- --
Peter Saint-Andre
https://stpeter.im/