Subject: [xmpp] RFC 3920 violates XML 1.0?

From: Matthew Miller <[email-masked]>
Date: Wed, 20 Oct 2010 11:06:52 -0600

I could be reading things wrong, but I believe RFC 3920 (specifically section 4.7.3) is violating XML 1.0[1].

In section 3[2], it states the following:

This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.

Given that, the stream error condition <xml-not-well-formed/> from 4.7.3 would be violating this rule.  Note that this also applies to 3920bis.

I'm not sure anyone's actually seen this, and I only discovered it as QA was filling in the corners of our latest work.  I'm also not sure what to do about this, either.  We could change this to "not-well-formed" or something like that in the bis drafts, but it could be a problem for implementations against the current spec.  Then again, this is a stream-level, non-recoverable error, so maybe it doesn't get encountered this way (-:

Thoughts?

- m&m

[1] Extensible Markup Language (XML) 1.0 (Fifth Edition) <http://www.w3.org/TR/2008/REC-xml-20081126/>

---

From: Ben Schumacher <[email-masked]>
Date: Wed, 20 Oct 2010 11:13:50 -0600

On 10/20/10 11:06 AM, Matthew Miller wrote:
> Given that, the stream error condition<xml-not-well-formed/>  from 4.7.3 would be violating this rule.  Note that this also applies to 3920bis.
>
> [1] Extensible Markup Language (XML) 1.0 (Fifth Edition)<http://www.w3.org/TR/2008/REC-xml-20081126/>

[2] Section 3 Logical Structures 
<http://www.w3.org/TR/2008/REC-xml-20081126/#sec-logical-struct>

Cheers,
Ben

---

From: Kevin Smith <[email-masked]>
Date: Wed, 20 Oct 2010 18:29:24 +0100

> I'm not sure anyone's actually seen this, and I only discovered it as QA was filling in the corners of our latest work.  I'm also not sure what to do about this, either.  We could change this to "n…

There's a train of thought that says that sending something the entity
won't understand in response to invalid XML is poetic justice :)

/K

---

From: Matthew Miller <[email-masked]>
Date: Wed, 20 Oct 2010 11:30:23 -0600

> won't understand in response to invalid XML is poetic justice :)

I was thinking exactly that myself, about 3 seconds after I sent this email (-:

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 11:46:50 -0600

On 10/20/10 11:29 AM, Kevin Smith wrote:
>> I could be reading things wrong, but I believe RFC 3920
>> (specifically section 4.7.3) is violating XML 1.0[1].
>> 
>> This specification does not constrain the application semantics,
>> use, or (beyond syntax) names of the element types and attributes,
>> except that names beginning with a match to
>> (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in
>> this or future versions of this specification.
>> 
>> Given that, the stream error condition <xml-not-well-formed/> from
>> 4.7.3 would be violating this rule.  Note that this also applies to
>> 3920bis.
>> 
>> I'm not sure anyone's actually seen this, and I only discovered it
>> as QA was filling in the corners of our latest work.  I'm also not
>> sure what to do about this, either.  We could change this to
>> "not-well-formed" or something like that in the bis drafts, but it
>> could be a problem for implementations against the current spec.
>> Then again, this is a stream-level, non-recoverable error, so maybe
>> it doesn't get encountered this way (-:
> 
> There's a train of thought that says that sending something the
> entity won't understand in response to invalid XML is poetic justice
> :)

That's classic. :)

But it seems bad for our profile of XML to violate the XML spec, no?

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 21 Oct 2010 02:48:40 +0900

Hi,

>From what I know, this would have been absolutely true only if we
didn't use the namespace RFC. But in our case, as we use namespace, it
is true and false depending on if we use this element with a default
namespace or prefixed.

See http://www.w3.org/TR/xml-names/#ns-decl ("Namespace constraint:
Reserved Prefixes and Namespace Names" part) where only the prefixes
"xml*" are forbidden, and there is no "constraint" on localparts, only
an advice not to make them "xml*" as well:

«
Though they are not themselves reserved, it is inadvisable to use
prefixed names whose LocalPart begins with the letters x, m, l, in any
case combination, as these names would be reserved if used without a
prefix.
»

So it means that the element xml-not-well-formed is authorized (though
unadvised) because it is under the namespace
'urn:ietf:params:xml:ns:xmpp-streams'.

But then it seems to mean that we must *always* write this error with a prefix.
Then the example in 4.8.3.25 is actually wrong because it falls into
reserved names:

«
<stream:error>
        <xml-not-well-formed
            xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
      </stream:error>
      </stream:stream>
»

This is the only case (unless there are other similarly named elements
in our RFC in "xml*"?) where we cannot use the default namespace
feature and where we MUST use declared namespace prefix. we have hence
to replace this example by something like this:

«
<stream:error>
        <xmpp-streams:xml-not-well-formed
            xmlns:xmpp-streams='urn:ietf:params:xml:ns:xmpp-streams'/>
      </stream:error>
      </stream:stream>
»

Or of course we can just change this localpart because it is annoying
for nothing that interesting.

> I'm not sure anyone's actually seen this, and I only discovered it as QA was filling in the corners of our latest work.  I'm also not sure what to do about this, either.  We could change this to "n…

Nice catch. :-)
> - m&m

Bye.

Jehan

---

From: Matthew Miller <[email-masked]>
Date: Wed, 20 Oct 2010 11:55:23 -0600

> for nothing that interesting.

Since there's other places in RFC 3920 (I can't recall them right now) that recommend against prefixes different from what's defined in these specs, it's a bit of a catch-22.

I did read and consider that section of namespaces in xml, but thought recommending a prefix for error conditions would create bigger problems than fixing this one name...

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 12:00:01 -0600

On 10/20/10 11:55 AM, Matthew Miller wrote:

> I did read and consider that section of namespaces in xml, but
> thought recommending a prefix for error conditions would create
> bigger problems than fixing this one name...

I'd be in favor of fixing this one name:

<not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>

/psa

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 21 Oct 2010 03:04:33 +0900

Hi,

> I did read and consider that section of namespaces in xml, but thought recommending a prefix for error conditions would create bigger problems than fixing this one name...

Probably. It is surely advisable to fix this name rather than using a
prefix. Moreover even if we were not fully violating the XML spec in
the end, it is still always better to follow the XML spec's advices,
and then stay further possible from actual probable violation.
Bye.

Jehan

---

From: Kevin Smith <[email-masked]>
Date: Wed, 20 Oct 2010 19:06:31 +0100

> But it seems bad for our profile of XML to violate the XML spec, no?

I mis-expressed myself. Changing this in bis to something legal that
legacy clients sending illegal protocols won't understand seems like a
fine option.

i.e. we should change to something like not-well-formed, and let
broken clients get a different error from the one they weren't
expecting.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 13:29:20 -0600

:)

I propose the following changes:

1. Change the name of the error condition to "not-well-formed".

2. Add the following interoperability note to Section 4.8.3.13 (the
section number changes because the stream error conditions are listed
alphabetically)...

      Interoperability Note: In RFC 3920, the name of this error
      condition was "xml-not-well-formed" instead of "not-well-formed".
      The name was changed because the element name <xml-not-well-
      formed/> violates the constraint from Section 3 of [XML] that
      "names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are
      reserved for standardization in this or future versions of this
      specification".

3. Add the following line to Appendix D ("Differences from RFC 3920")...

   o  Changed the name of the <xml-not-well-formed/> stream error
      condition to <not-well-formed/> for compliance with the XML
      specification.

/psa

---

From: Matthew Miller <[email-masked]>
Date: Wed, 20 Oct 2010 13:30:40 -0600

>      condition to <not-well-formed/> for compliance with the XML

+1

- m&m

---

From: Kevin Smith <[email-masked]>
Date: Wed, 20 Oct 2010 20:34:13 +0100

+1

/K

---

From: Ben Schumacher <[email-masked]>
Date: Wed, 20 Oct 2010 13:53:19 -0600

On 10/20/10 1:29 PM, Peter Saint-Andre wrote:
>        The name was changed because the element name<xml-not-well-
>     o  Changed the name of the<xml-not-well-formed/>  stream error
>        condition to<not-well-formed/>  for compliance with the XML
>        specification.
>
I like it.
-Ben

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 14:22:47 -0600

> I like it.

I can't say I like it -- I wish we'd found this bug in 2003 :) -- but
this fix will at least plug the hole...

---

From: Ben Schumacher <[email-masked]>
Date: Wed, 20 Oct 2010 14:30:01 -0600

> this fix will at least plug the hole...

Well you can at least like that it's getting fixed.

The advantage of having a larger following for XMPP is that we end up 
with more eyes and that ought to increase the chances of catching these 
sorts of things. The scope of this problem is extremely narrow -- just 
be glad that we didn't end up with something like encouraging prefixing 
of XMPP streams with "xmlstream". ;)

Ben

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Oct 2010 17:06:45 -0500

On Oct 20, 2010, at 2:29 PM, Peter Saint-Andre wrote:

[...]

>      condition to <not-well-formed/> for compliance with the XML

Are we talking about making this change in 3920bis?

Given that this draft is almost through IETF LC, do we really want to add scope by finding new things in 3920 to fix?

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 16:13:42 -0600

On 10/20/10 4:06 PM, Ben Campbell wrote:
>> 2. Add the following interoperability note to Section 4.8.3.13
>> (the section number changes because the stream error conditions are
>> listed alphabetically)...
>> 
> Given that this draft is almost through IETF LC, do we really want to
> add scope by finding new things in 3920 to fix?

We don't *want* to, but continuing to allow nonconformance with the XML
spec when we're defining an application of XML seems like a bad idea.

Peter

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

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 27 Oct 2010 15:21:01 +0200

In draft-ietf-xmpp-3920bis-18, is it correct to assume that Server 2 can 
not send empty <features> in:

9.2.2.  SASL

   Step 8: Server2 sends a response stream header to Server1 along with
   available stream features (including a preference for the SASL
   EXTERNAL mechanism):

tnx
Avshalom

---

From: Dave Cridland <[email-masked]>
Date: Wed, 27 Oct 2010 15:57:48 +0100

>    available stream features (including a preference for the SASL

I don't think so, no.

To clarify, I think that if there are no available features, a  
responder MUST include an empty features element to indicate this.

However, I'm also aware that an empty features can confuse clients -  
luckily this should never occur except in the case of odd server  
behaviour.

In the case of C2S, I'd expect there to be resource binding or SASL  
at any given point.

In the case of S2S, I'd expect that a server would respond with an  
empty stream features list only if SASL had already been negotiated,  
or wasn't supported, and dialback was also disabled.

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: Jehan Pagès <[email-masked]>
Date: Thu, 28 Oct 2010 03:14:58 +0900

Hi,

On Wed, Oct 27, 2010 at 11:57 PM, Dave Cridland <[email-masked]> wrote:
> To clarify, I think that if there are no available features, a responder
> MUST include an empty features element to indicate this.
>
> However, I'm also aware that an empty features can confuse clients - luckily
> this should never occur except in the case of odd server behaviour.
>
> In the case of C2S, I'd expect there to be resource binding or SASL at any
> given point.
>
> In the case of S2S, I'd expect that a server would respond with an empty
> stream features list only if SASL had already been negotiated, or wasn't
> supported, and dialback was also disabled.
>
> Dave.

Actually sending an empty stream <features> (along with sending only
voluntary features) is the way to indicate that the stream has been
negotiated and that both entity are now allowed to transmit stanzas.
So yes, you can send empty stream features, and in some cases (no
features are anymore negotiable), you must.
Cf.

«
4.2.5.  Completion of Stream Negotiation

The receiving entity indicates completion of the stream negotiation
   process by sending to the initiating entity either an empty
   <features/> element or a <features/> element that contains only
   voluntary features
»

Bye.

Jehan