Subject: [xmpp] #30: namespace declarations for other namespaces

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 21:25:58 -0000

#30: namespace declarations for other namespaces
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  major               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 4.5.3 states:

 > Because an XML stanza is the primary unit of meaning in XMPP and
 > because an XML stanza can be routed outside the context of the
 > stream in which it originated, a stream header MUST NOT include
 > namespace declarations for namespaces that are different from the
 > streams namespace and the default namespace.

 Waqas Hussain commented: "Dialback support can be advertised by this (as
 described in XEP-0220), and some servers require this for dialback (this
 was previously the only way to advertise dialback). "

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/30>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jun 2010 22:08:46 -0600

> #30: namespace declarations for other namespaces

You are right -- that is not phrased carefully enough. This is better:

   A stream header MUST NOT include namespace declarations for
   data that will be routed outside the stream in which the data
   originated.

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Thu, 24 Jun 2010 04:09:25 -0000

#30: namespace declarations for other namespaces
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  major               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Provisionally fixed with this text:

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/xmpp/trac/ticket/30#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Jun 2010 09:16:02 +0100

> > #30: namespace declarations for other namespaces

What about making the rationale a little more explicit, to aid in  
understanding this:

	<t>A stream header MUST only include namespace declarations used for  
properties
	of that stream itself; namespaces used for routable data such as  
stanza child 	elements MUST NOT be declared in the stream header.</t>

The other related issue is what servers should be doing when they  
receive such data - I believe our implementation will actually handle  
the case without error.
-- 
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: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 15:02:32 -0600

> stanza child     elements MUST NOT be declared in the stream header.</t>

I've tweaked the text further:

###

4.5.3.  Declaration of Other Namespaces

   Namespaces declared in a stream header MUST apply only to the stream
   itself.  In particular, because XML stanzas intended for delivery to
   entities located on remote servers will lose the namespace context
   declared in the header of the stream in which those stanzas
   originated, namespaces for extended content within such stanzas MUST
   NOT be declared in that stream header.  See also Section 8.4.

###

Section 8.4 contains the following paragraph:

   It is conventional in the XMPP community for implementations to not
   generate namespace prefixes for elements that are qualified by
   extended namespaces (outside the XMPP community, this convention is
   sometimes called "prefix-free canonicalization").  However, if an
   implementation generates such namespace prefixes then it MUST include
   the namespace declaration in the stanza itself or a child element of
   the stanza, not in the stream header (see Section 4.5.3).

> receive such data - I believe our implementation will actually handle

Because the spec does not specify how to handle a violation of the rules
in Sections 4.5.3 and 8.4, your implementation is compliant. :)

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 10:25:27 +0100

> in Sections 4.5.3 and 8.4, your implementation is compliant. :)

Good point, they probably should.

Do we want:

a) MUST reject
b) SHOULD reject
c) SHOULD accept
d) MUST accept

I'd be inclined to go for (c), leaving, as it does, the possibility  
that it won't.

Dave.

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 10:43:19 +0100

On 28 June 2010 10:25, Dave Cridland <[email-masked]> wrote:
> I'd be inclined to go for (c), leaving, as it does, the possibility that it
> won't.
>

The potential consequences of a server routing stanzas with unbound
prefixes are not good. They can cause DoS of streams in many
implementations existing today.

Prosody iirc solves this by accepting, but bringing declarations down
into the stanza, which isn't ideal (which is why I'm happy that
declarations in the stream tag be forbidden), but any entity which
accepts and routes such data without this rewriting is asking for
trouble and we certainly shouldn't recommend it in the spec.

Matthew

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 11:39:00 +0100

> trouble and we certainly shouldn't recommend it in the spec.

Oh, indeed. Blind forwarding of data in this case would be bad.

The trouble is that copying buffers is *much* faster than  
reserializing XML, so we'd like to preserve that (potential)  
behaviour if possible.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:14:56 -0600

> trouble and we certainly shouldn't recommend it in the spec.

Agreed. I'd prefer (b) "SHOULD reject" because as Matthew points out the
consequences can be quite dire. I'd further propose that we use the
<invalid-namespace/> stream error for this case.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:23:30 -0600

On 6/28/10 4:39 AM, Dave Cridland wrote:
>> that it
> The trouble is that copying buffers is *much* faster than reserializing
> XML, so we'd like to preserve that (potential) behaviour if possible.

How is this for Section 4.5.3 (Declaration of Other Namespaces)?

   Namespaces declared in a stream header MUST apply only to the stream
   itself.  In particular, because XML stanzas intended for routing or
   delivery over streams with other entities will lose the namespace
   context declared in the header of the stream in which those stanzas
   originated, namespaces for extended content within such stanzas MUST
   NOT be declared in that stream header (see also Section 8.4).  If
   either party to a stream declares such namespaces, the other party to
   the stream SHOULD close the stream with a stream error of <invalid-
   namespace/>.  In any case, an entity MUST NOT blindly route or
   deliver over streams with other entities any stanzas containing
   extended content prefixed by namespaces declared in the header of the
   stream in which those stanzas originated.

/psa

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 15:38:04 +0100

On Mon Jun 28 15:23:30 2010, Peter Saint-Andre wrote:
> >> >> Because the spec does not specify how to handle a violation  
> of the
> >> rules
> reserializing

The MUST NOT send, SHOULD reject, is fine.

The last sentence feels wrong to me - it argues that if you choose  
not to do the SHOULD, then you mustn't route any stanzas containing  
elements which are, themselves, in a namespace declared by the  
originating entity in a stream header - does it mean reject them,  
drop them, or what?

I do, of course, know what this is driving at, but I think you mean:

	In any case, an entity MUST ensure that any namespace declarations  
in the stream header are repeated as required when routing or  
delivering stanzas received over that stream.

Which isn't much better - what about:

	In any case, an entity MUST ensure that such namespaces are properly  
declared (according to this section) when routing or forwarding  
stanzas originating from such a stream.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:43:12 -0600

On 6/28/10 8:38 AM, Dave Cridland wrote:
> The last sentence feels wrong to me - it argues that if you choose not
> to do the SHOULD, then you mustn't route any stanzas containing elements
> which are, themselves, in a namespace declared by the originating entity
> in a stream header - does it mean reject them, drop them, or what?
> 
> in the stream header are repeated as required when routing or delivering
> stanzas received over that stream.
> 
> declared (according to this section) when routing or forwarding stanzas
> originating from such a stream.

Yes, that is much better, thanks.

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 18:35:39 +0100

> Yes, that is much better, thanks.

+1 to this text, thanks both.

Matthew