Subject: [xmpp] "re-scope" of xmpp stanza's

From: Mridul Muralidharan <[email-masked]>
Date: Thu, 11 Nov 2010 22:04:44 +0530 (IST)

Hi all,

  Are there are rules regarding re-scoping of xmpp stanza from jabber:client 
to jabber:server or vice versa ? I did not find much elaboration in 3920 or 
3920bis.
(Assuming I am not missing some general document !).

I am thinking of scenarios which include :

a) Explicit namespace prefix whose uri which matches the default stream 
namespace
Example:

   <stream:stream        from=[email-masked]'        to='im.example.com'        
version='1.0'        xml:lang='en'        xmlns='jabber:client'        
xmlns:stream='http://etherx.jabber.org/streams'>
...
      <iq myns:to="im.remote.net" xmlns:myns='jabber:client' type='get'>       
<myns:query><myns:my_tag>custom_data</myns:my_tag></myns:query>
     </iq>

If this is to be forwarded over from a C2S to an S2S, what rules apply - what 
'parts' of the xml stanza should be "re-scoped" and what cant be ?

b) Explicit namespace specified at each level in the xml stanza.

     <myns1:iq myns1:to="im.remote.net" xmlns:myns1='jabber:client' type='get'>       
<myns2:query xmlns:myns2='jabber:client'><myns3:my_tag xmlns:myns3='jabber:client'>custom_data</myns3:my_tag></myns2:query>

     </myns1:iq>

And possibly other variations of the two above I guess and more ...

Thanks,
Mridul

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 09:53:38 +0800

> (Assuming I am not missing some general document !).

Section 4.7.5 of 3920bis says:

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if the server to which
      the client is connected needs to route a client-generated stanza
      to another server then it MUST "re-scope" the stanza so that its
      content namespace is 'jabber:server' (i.e., it MUST NOT send a
      stanza qualified by the 'jabber:client' namespace over a stream
      whose content namespace is 'jabber:server').  Similarly, a routing
      server MUST "re-scope" a stanza received over a server-to-server
      stream (whose content namespace is 'jabber:server') so that the
      stanza is qualified by the 'jabber:client' namespace before
      sending it over a client-to-server stream (whose content namespace
      is 'jabber:client').

If you think more needs to be said, please propose text very soon
because the comment window is closed. I think the current text is fine
and everything else is a matter of implmentation, but you might disagree.

> a) Explicit namespace prefix whose uri which matches the default stream 

Disallowed. Section 4.7.4 of 3920bis states:

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

> <myns2:query xmlns:myns2='jabber:client'><myns3:my_tag xmlns:myns3='jabber:client'>custom_data</myns3:my_tag></myns2:query>

Such data is preserved, because Section 8.4 of 3920bis states:

   If a server handles a stanza that is intended for delivery to another
   entity and that contains a child element it does not understand, it
   MUST route the stanza unmodified to a remote server or deliver the
   stanza unmodified to a connected client associated with a local
   account.

Peter

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

---

From: Mridul Muralidharan <[email-masked]>
Date: Fri, 12 Nov 2010 11:05:47 +0530 (IST)

Hi Peter,

  Please see inline.

Regards,
Mridul

----- Original Message ----
> From: Peter Saint-Andre <[email-masked]>
> To: [email-masked]
> Sent: Fri, 12 November, 2010 7:23:38 AM
> Subject: Re: [xmpp] "re-scope" of xmpp stanza's
> 

> and everything else is a matter of implmentation, but you might  disagree.

In the common case of :

1) Only stream namespace defined through xmlns as jabber:client/jabber:server.
2) No explicit stanza and attribute namespace specified.
The rules above will work - which should actually cover most of the usecases 
thankfully !
It becomes a simple case of rescoping the stanza from jabber:client to 
jabber:server (and vice versa) and everything else will work as-is.

But for a general case.

a) We need not have default namespace defined for the stream (<client:stream 
xmlns:client="jabber:client"> ... )

b) Explicitly specifying attribute namespace is not disallowed - so how is it 
supposed to be handled when they have a different ns-name compared to stanza.
(<client:iq  c:to="server.net" xmlns:c="jabber:client"> ... )

[read in conjugation with http://www.w3.org/TR/REC-xml-names/#defaulting ].

In these cases (or combinations thereof), how is re-scoping to be handled.
For a jabber:client to jabber:server rescoping case, should we :

1) Completely replace all occurance of 'jabber:client' namespace in the stanza 
and all its children (down to the leaves) to 'jabber:server' ?
2) Only replace at the (top level) stanza for only the element nsname ?
3) Replace all jabber:client nsname's at the (top level) stanza but not for the 
children ?

>    'jabber:client' or 'jabber:server'.

Does this apply only to stream namespace or also to stanza namespace ?
If both, then it answers this part of my query I guess.

As in:

<client:stream xmlns:client="jabber:client" ...>
...
<iq xmlns="jabber:client" to="server.net">
  <query />
</iq>

> >  <myns2:query xmlns:myns2='jabber:client'><myns3:my_tag  
>xmlns:myns3='jabber:client'>custom_data</myns3:my_tag></myns2:query>
> > 
> >      </myns1:iq>
> 

Please note that there are two cases here:

1) iq has to be rescoped from jabber:client to jabber:server.
2) Child elements have explicit jabber:client namespace (for query tag for 
example).

To illustrate-
In a 'normal' case, the above would be :

<stream xmlns="jabber:client" ...>
...
<iq to="im.remote.net"  type='get'>
  <query >
    <my_tag>custom_data</my_tag>
  </query>
</iq>

Which entirely gets rescoped to jabber:server namespace as opposed to the 
example you responded to.

If the behavior in both cases is going to be different - then we have additional 
constraints on how xml is to be serialized and deserialized from an xml stream 
due to rescoping and how to interpret it ...
Hopefully I am not missing something.

Thanks for clarifying.
Regards,
Mridul

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 14:13:07 +0800

> 3) Replace all jabber:client nsname's at the (top level) stanza but not for the 

Please read this text from 3920bis:

###

4.7.3.  Other Namespaces

   Either party to a stream MAY send data qualified by namespaces other
   than the content namespace and the streams namespace.  For example,
   this is how data related to TLS negotiation and SASL negotiation are
   exchanged, as well as XMPP extensions such as Stream Management
   [XEP-0198] and Server Dialback [XEP-0220].  (For historical reasons,
   some server implementations expect a declaration of the 'jabber:
   server:dialback' namespace on server-to-server streams, as explained
   in [XEP-0220].)

   However, an XMPP server MUST NOT route or deliver data received over
   an input stream if that data is (a) qualified by another namespace
   and (b) addressed to an entity other than the server, unless the
   other party to the output stream over which the server would send the
   data has explicitly negotiated or advertised support for receiving
   arbitrary data from the server.  This rule is included because XMPP
   is designed for the exchange of XML stanzas (not arbitrary XML data),
   and because allowing an entity to send arbitrary data to other
   entities could significantly increase the potential for exchanging
   malicious information.  As an example of this rule, the server
   hosting the example.net domain would not route the following first-
   level XML element from <[email-masked]> to <[email-masked]>:

     <ns1:foo xmlns:ns1='http://example.org/ns1'
              from=[email-masked]/resource1'
              to=[email-masked]'>
       <ns1:bar/>
     </ns1:foo>

   This rule also applies to first-level elements that look like stanzas
   but that are improperly namespaced and therefore really are not
   stanzas at all (see also Section 4.7.4), for example:

     <ns2:message xmlns:pre='http://example.org/ns2'
                  from=[email-masked]/resource1'
                  to=[email-masked]'>
       <body>hi</body>
     </ns2:message>

   Upon receiving arbitrary first-level XML elements over an input
   stream, a server MUST either ignore the data or return a stream
   error, which SHOULD be <unsupported-stanza-type/>.

###

Does that address your questions?

> <iq xmlns="jabber:client" to="server.net">

See this:

###

4.7.2.  Content Namespace

   An entity MAY declare a "content namespace" as the default namespace
   for data sent over the stream (i.e., data other than elements
   qualified by the streams namespace).  If so, (1) the content
   namespace MUST be other than the streams namespace, and (2) the
   content namespace MUST be the same for the initial stream and the
   response stream so that both streams are qualified consistently.  The
   content namespace applies to all first-level child elements sent over
   the stream unless explicitly qualified by another namespace (i.e.,
   the content namespace is the default namespace).

###

> 1) iq has to be rescoped from jabber:client to jabber:server.

Sure.

> 2) Child elements have explicit jabber:client namespace (for query tag for 

Why would you do that? Doesn't namespace inheritance handle that?

> example you responded to.

Correct.

> Hopefully I am not missing something.

Inheritance?

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 12 Nov 2010 08:52:33 +0100

>                                     from=[email-masked]/resource1'
Somehow I would've expexted xmlns:ns2='http://example.org/ns2' here.

> > 2) Child elements have explicit jabber:client namespace (for query tag
> > for   example).
> 
I guess the point is it's possible. In fact prosody used to put xmlns='jabber:client' pretty much everywhere until we discovered it breaks esessions (IIRC).

> > Which entirely gets rescoped to jabber:server namespace as opposed to
> > the   example you responded to.
> 
> Correct.
> 
> > If the behavior in both cases is going to be different - then we have
> > additional   constraints on how xml is to be serialized and
> > deserialized from an xml stream   due to rescoping and how to interpret
> > it ... Hopefully I am not missing something.
> 
> Inheritance?
> 
Personally I think it ought to be as easy as replacing all occurences of jabber:client in an xmlns attribute (at all levels) with jabber:server and vice versa. This will however fail if one tried to tunnel jabber:server over jabber:client.
E.g.:
C2S: <message to=[email-masked]' xmlns='jabber:client>
       <presence to=[email-masked]' xmlns='jabber:server'/>
     </message>

S2S: <message to=[email-masked]' xmlns='jabber:server>
       <presence to=[email-masked]' xmlns='jabber:server'/>
     </message>

S2C: <message to=[email-masked]' xmlns='jabber:client>
       <presence to=[email-masked]' xmlns='jabber:client'/>
     </message>

Which clearly falls into "Why would you", but is entirely possible AFAICT.

--
Florian Zeitz

---

From: Dave Cridland <[email-masked]>
Date: Fri, 12 Nov 2010 11:23:30 +0000

> xmlns:myns3='jabber:client'>custom_data</myns3:my_tag></myns2:query>

Just as a side-note, that stanza has no to attribute, so won't get  
routed at all.

f:to='...' xmlns:f='...' is not the same as a simple to='...'

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: Mridul Muralidharan <[email-masked]>
Date: Fri, 12 Nov 2010 19:34:31 +0530 (IST)

I dont see what the difference between

1) <iq to="im.remote.net"  xmlns="jabber:client"> ...

and

2) <iq ns1:to="im.remote.net" xmlns="jabber:client"  ns1:xmlns="jabber:client"> ...

and 

3) <ns:iq ns1:to="im.remote.net" xmlns:ns="jabber:client"  ns1:xmlns="jabber:client"> ...

is.
Atleast from an xml point of view, there is no difference imo. 

If there are specific reasons why it does not work for xml streams, or due to implementation quirks, then we would need them to be elaborated. I think bis spec does try to address few, but probably there are cases where it does not.

Regards,
Mridul

--- On Fri, 12/11/10, Dave Cridland <[email-masked]> wrote:

> From: Dave Cridland <[email-masked]>
> To: "XMPP Working Group" <[email-masked]>
> Date: Friday, 12 November, 2010, 4:53 PM
> >      <myns1:iq
> myns1:to="im.remote.net" xmlns:myns1='jabber:client'
> type='get'>
> > <myns2:query
> xmlns:myns2='jabber:client'><myns3:my_tag
> Just as a side-note, that stanza has no to attribute, so
> won't get routed at all.
> 
> --Dave Cridland - mailto:[email-masked]
> - xmpp:[email-masked]
>  -
> acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Mridul Muralidharan <[email-masked]>
Date: Fri, 12 Nov 2010 20:10:48 +0530 (IST)

Missed the part about :

Per the Namespaces in XML Specification [XML Namespaces] an attribute does not inherit its namespace from the element it is attached to. If an attribute is not explicitly given a namespace, it simply has no namespace.

So yes, first is indeed not same as second or third.

Regards,
Mridul

--- On Fri, 12/11/10, Mridul Muralidharan <[email-masked]> wrote:

> From: Mridul Muralidharan <[email-masked]>
> To: "XMPP Working Group" <[email-masked]>, "Dave Cridland" <[email-masked]>
> Date: Friday, 12 November, 2010, 7:34 PM
> 
> 
> 2) <iq ns1:to="im.remote.net"
> xmlns="jabber:client"  ns1:xmlns="jabber:client">
> ...
> 
> and 
> 
> 3) <ns:iq ns1:to="im.remote.net"
> xmlns:ns="jabber:client"  ns1:xmlns="jabber:client">
> ...
> 
> 
> is.
> If there are specific reasons why it does not work for xml
> streams, or due to implementation quirks, then we would need
> them to be elaborated. I think bis spec does try to address
> few, but probably there are cases where it does not.
> 
> 
> 
> 
> Regards,
> Mridul
> 
> 
> > > b) Explicit namespace specified at each level in
> the
> > xml stanza.
> > > 
> > >      <myns1:iq

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 15 Nov 2010 14:19:03 +0530 (IST)

I just ran a few experiments, and apparently there is incompatibility in terms of how re-scoping is handled in the current servers.
I have published the results here [1], [2]
Hopefully, the posts clarify what I was referring to more than my attempts at sending them over email here :-)

Essentially, interpretation of what re-scoping means is implementation dependent when you have explicit namespaces defined.
I am not sure if that is a very good thing for interoperability.

Regards,
Mridul

[1] http://xmpp-expt.blogspot.com/2010/11/re-scoping-experiments-1.html
[2] http://xmpp-expt.blogspot.com/2010/11/re-scoping-experiment-2-openfire-to.html

--- On Fri, 12/11/10, Peter Saint-Andre <[email-masked]> wrote:

> To: "Mridul Muralidharan" <[email-masked]>
> Cc: [email-masked]
> Date: Friday, 12 November, 2010, 11:43 AM
> >>>   Are there are rules regarding
> re-scoping of xmpp stanza  from jabber:client 
> >>
> >>        Implementation Note:
> Because a client sends stanzas over a  stream
> >>       whose content
> namespace is 'jabber:client', if  the server to which
> >>       the client is
> connected needs to  route a client-generated stanza
> >>       to another server
> then  it MUST "re-scope" the stanza so that its
> >>       content 
> namespace is 'jabber:server' (i.e., it MUST NOT send a
> >>        stanza qualified by the
> >>        whose content namespace
> is 'jabber:server').  Similarly, a  routing
> >>       server MUST
> "re-scope" a stanza received over a  server-to-server
> >>       stream (whose
> content namespace is  'jabber:server') so that the
> >>       stanza is qualified
> >>       sending it over
> a  client-to-server stream (whose content namespace
> >>       is 
> 'jabber:client').
> >>
> >>    MUST route the  stanza
> unmodified to a remote server or deliver the
> >>    stanza unmodified  to a

---

From: Kevin Smith <[email-masked]>
Date: Mon, 15 Nov 2010 09:00:31 +0000

> I am not sure if that is a very good thing for interoperability.

I confess that I only read the first of the two links, but given that
all the experiments were based on sending data that break a MUST NOT
in the spec, expecting interoperability here seems a bit steep.

/K

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 15 Nov 2010 15:48:08 +0530 (IST)

Other than two cases, imo the others were not violating MUST NOT : and there 
were differences in the way stanzas were treated by various servers.

In addition, I did mention that until I get my hands on a client which supports 
prefix-free canonicalization (or hack up one by myself), I cant test for those 
two valid cases too.

Regards,
Mridul

----- Original Message ----
> From: Kevin Smith <[email-masked]>
> To: Mridul Muralidharan <[email-masked]>
> Cc: Peter Saint-Andre <[email-masked]>; [email-masked]
> Sent: Mon, 15 November, 2010 2:30:31 PM
> > I  just ran a few experiments, and apparently there is incompatibility in 
>terms of  how re-scoping is handled in the current servers.
> >  Essentially, interpretation of what re-scoping means is implementation 
>dependent  when you have explicit namespaces defined.

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 15 Nov 2010 16:49:31 +0530 (IST)

I re-ran the same experiment with prefix-free canonicalization to avoid the issue Kevin mentioned for the cases where it was applicable.
Unfortunately, the results were the same, and the posts have been updated to indicate the same.

Hopefully that should clarify better. Thanks for pointing out the error.

To add, the reason for bringing this up is - I want to know what the 'right' way to do re-scoping is in case of ambiguity for the parser we are doing. Various servers seem to implement it depending in their own way which can lead to interoperability issues somewhere down the line.
It is not a mental exercise on how to break protocol, or get spec updated, etc :-)

Regards,
Mridul

--- On Mon, 15/11/10, Kevin Smith <[email-masked]> wrote:

> Cc: "Peter Saint-Andre" <[email-masked]>, [email-masked]
> Date: Monday, 15 November, 2010, 2:30 PM
> > I just ran a few experiments, and apparently there is
> incompatibility in terms of how re-scoping is handled in the
> current servers.
> > Hopefully, the posts clarify what I was referring to
> more than my attempts at sending them over email here :-)
> > Essentially, interpretation of what re-scoping means
> is implementation dependent when you have explicit
> namespaces defined.

---

From: Florian Zeitz <[email-masked]>
Date: Mon, 15 Nov 2010 14:45:36 +0100

> prefix-free canonicalization (or hack up one by myself), I cant test for those 

I think some of this stems from the fact that you seem to be reading
3920bis-13 and not the current 3920bis-18 that reads:
   "An implementation MUST NOT generate namespace prefixes for elements
   qualified by the content namespace if the content namespace is
   'jabber:client' or 'jabber:server'"
(Previously you could bind namespace prefixes if the default namespace
was not set...)
That means all of the examples but
<message  xml:lang="en" to="[email-masked]" >
<ns1:body xmlns:ns1="jabber:server" >Test 4</ns1:body>
</message>
are invalid. In that case ns1 is bound to jabber:server, but
jabber:server is not the content namespace of the C2S stream.
However this in turn causes the server to send invalid stanzas over the
S2S stream, and the receiving server to reconstruct a different stanza
and send that over the C2S stream.
I'm honestly not sure how to solve this (or if we really need to).
We could aways just forbid sending elements with a namespace name of
jabber:server over a C2S stream (or do we already?).

--
Florian Zeitz

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 15 Nov 2010 19:35:40 +0530 (IST)

--- On Mon, 15/11/10, Florian Zeitz <[email-masked]> wrote:

> From: Florian Zeitz <[email-masked]>
> Date: Monday, 15 November, 2010, 7:15 PM
> <message  xml:lang="en" to="[email-masked]"
> >

If you notice, the responses were the same even in case of a xmpp stream which is not bound to jabber:client or jabber:server as the default xmlns namespace (what is referred to as prefix-free canonicalization in the rfc).

That is, the xmpp stream was opened as :

<stream:stream xmlns:stream="http://etherx.jabber.org/streams" version="1.0" to="domain" xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace" >

- with no xmlns defined for the stream.

> jabber:server over a C2S stream (or do we already?).

I dont think we do.
But the same applies to component stream too btw (I just did not explicitly include it in the examples).

In general though, it would be nice if we had the restrictions on XML streams laid out - and where it deviates from XML : since XMPP defines what XML stream is supposed to look like - like usecases of XML stream within context of only 3920 (not necessarily with 3921).

For example: the note above which you referred to [1] looks like a attempt to prevent issues but perhaps does not deal with the underlying cause of it.

Thanks,
Mridul

[1] MUST NOT have prefix if same as content namespace which is jabber:client or jabber:server.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Nov 2010 15:18:27 -0700

On 11/15/10 7:05 AM, Mridul Muralidharan wrote:

> In general though, it would be nice if we had the restrictions on XML
> streams laid out 

Well, one solution would be to forbid prefix-free canonicalization at
the stream level. Be careful what you wish for... ;-)

Peter

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

---

From: Mridul Muralidharan <[email-masked]>
Date: Tue, 16 Nov 2010 08:06:55 +0530 (IST)

As long as we can ensure that what gets sent by user1 on server1 will get received by user2 on server2 without semantic changes, that would be fine.
As of now, there are cases where this does not happen due to different interpretations of what re-scoping implies.

That being said, the prefix restriction (as specified in the spec) is a pretty strict restriction on clients - not sure how many clients/api's actually impose it actively ! (as opposed to having it work simply because of limited extensibility).

Regards,
Mridul

--- On Tue, 16/11/10, Peter Saint-Andre <[email-masked]> wrote:

> Date: Tuesday, 16 November, 2010, 3:48 AM
> -----Inline Attachment Follows-----
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Nov 2010 22:23:46 -0700

Mridul, it's still not clear to me what you are worried about. Could you
propose some small textual changes that could be incorporated into the
spec? (I emphasize "small" because I freely admit that I don't want to
make further changes at this point for fear of introducing bugs.)

On 11/15/10 7:36 PM, Mridul Muralidharan wrote:
> 
> As long as we can ensure that what gets sent by user1 on server1 will
> get received by user2 on server2 without semantic changes, that would
> be fine. As of now, there are cases where this does not happen due to
> different interpretations of what re-scoping implies.
> 
> That being said, the prefix restriction (as specified in the spec) is
> a pretty strict restriction on clients - not sure how many
> clients/api's actually impose it actively ! (as opposed to having it
> work simply because of limited extensibility).
> 
> 
> Regards, Mridul
> 
>> From: Peter Saint-Andre <[email-masked]> Subject: Re: [xmpp]
>> "re-scope" of xmpp stanza's To: [email-masked] Date: Tuesday, 16
>> November, 2010, 3:48 AM On 11/15/10 7:05 AM, Mridul Muralidharan
>> wrote:
>> 
>> Well, one solution would be to forbid prefix-free canonicalization
>> at the stream level. Be careful what you wish for... ;-)
>> 
>> Peter
>> 
>> -- Peter Saint-Andre https://stpeter.im/
>>

---

From: Waqas Hussain <[email-masked]>
Date: Tue, 16 Nov 2010 12:18:47 +0500

> make further changes at this point for fear of introducing bugs.)

I can explain, because MattJ and I have had this discussion a number of times.

Consider a [email-masked] sends this:

<message to='contact'>
  <custom xmlns='custom'>
    <message xmlns='jabber:client'/>
    <message xmlns='jabber:server'/>
  </custom>
  <message xmlns='jabber:client'/>
  <message xmlns='jabber:server'/>
</message>

i.e., it has some custom tag which can contain an arbitrary XML
payload, and that payload in this example happens to use our two
stream namespaces.

Now, if contact is [email-masked], that payload may arrive as-is.

But if the contact is on another server, that payload would be
modified in transit in many (most? all?) servers.

Mridul's point is, the modification to the payload is different for
different servers, and isn't defined in the spec. The same stanza
getting sent to e.g., a local MUC room is going to appear different to
a remote user than a local user. The difference is dependent on the
server software, and undefined in the spec.

Here's how it might look like when recieved by a remote client:

1. Server's stanza handling omits the stream namespace at all levels:

<message to='contact'>
  <custom xmlns='custom'>
    <message/>
    <message/>
  </custom>
  <message/>
  <message/>
</message>

(the top-level children inherit the jabber:client namespace, while the
inner messages inherit the custom namespace)

2. Server's stanza handling only omits stream namespace at the top level:

<message to='contact'>
  <custom xmlns='custom'>
    <message xmlns='jabber:server'/>
    <message xmlns='jabber:client'/>
  </custom>
  <message/>
  <message/>
</message>

(the top-level children inherit the jabber:client namespace, while the
inner messages preserve their original namespace)

3. Server's stanza handling attempts to preserve everything: the
original stanza is recieved with all child namespaces preserved, same
as the original stanza.

And so on.

Now, the spec isn't clear on which case is valid. I'll repeat the
problem again: The same stanza when sent to a local contact and to a
remote contact would appear different to both contacts. The same
stanza sent to a MUC room would appear different to remote occupants,
and the difference would be different depending on the server software
involved. The spec mentions "re-scope", but doesn't actually define
it. Must child elements be affected? Must child elements not be
affected?

I did some tests. The local host was ejabberd, and I tried sending the
above message to remote chatrooms.
1. Sending to a remote ejabberd chatroom, I got it back as-is
(ejabberd being namespace unaware didn't touch the xmlns attributes at
all).
2. Sending to M-Link caused connections to drop silently (tested using
both c2s and s2s). It doesn't seem to like messages inside a message.
Even if the inner message has a custom namespace. It did preserve
namespaces when I changed the element names from 'message' to 't'.
3. Sending to Openfire removed the top child namespaces (making them
both jabber:client), while set the inner child namespaces to the empty
string (xmlns="").
4. Prosody removes the current stream namespace from all elements
received on that stream, top level or not.

Clearly, sending stanzas as payload in another stanza doesn't work
very well in current XMPP servers.

P.S. And Mridul, the reason you see different behavior from openfire
and ejabberd when using namespace prefixes is likely because
openfire's parser parses in namespace aware mode, while ejabberd's
doesn't.

--
Waqas Hussain

---

From: Mridul Muralidharan <[email-masked]>
Date: Tue, 16 Nov 2010 13:07:46 +0530 (IST)

I wont have been able to put it better Waqas Hussain, thanks !

Peter, I am sorry that I cant really propose good alternate text because I am 
not as good an xml expert. I am not even sure what are the various ways in which 
this can fail : my examples were based on my off-late limited exposure to xmpp 
stanzas.

Since we have an extensible jabber:client, jabber:server, etc schema - we can 
have users extending it in proprietary custom ways, and be surprised at the 
unexpected stanza transformation. I am only aware of the problem due to my 
attempts to write a streaming xml parser [1].

I was hoping that someone from the group might either have a solution, have best 
practices doc for these corner cases, or be able to propose the required 
changes.

Thanks !
Mridul

[1] Actually, while trying to do a slightly "shady" optimization to minimize 
cost of c2s -> s2s stanza transformation

----- Original Message ----
> From: Waqas Hussain <[email-masked]>
> To: Peter Saint-Andre <[email-masked]>
> Cc: Mridul Muralidharan <[email-masked]>; [email-masked]
> Sent: Tue, 16 November, 2010 12:48:47 PM

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 11:55:32 -0700

> I can explain, because MattJ and I have had this discussion a number of times.

Thanks, Waqas.

> payload, and that payload in this example happens to use our two

I have a clarifying question: does this problem apply only to "nested"
stanzas as shown in your example (i.e., child elements qualified by
'jabber:client' or 'jabber:server')?

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 12:18:24 -0700

> it. Must child elements be affected? Must child elements not be

I think this is clear in the spec as long as you understand the
definition of "XML stanza", which is: a first-level child element (at
depth=1 of the stream) whose element name is "message", "presence", or
"iq" and whose qualifying namespace is 'jabber:client' or 'jabber:server'.

So in your example, the <message/> elements that are children of the
<message/> stanza or of the <custom/> element are *not* stanzas.

Could this be a bit clearer in the spec to prevent all possible
confusion? Yes, it could. So I propose the following small fixes:

In Section 4.1:

   Definition of XML Stanza:  An XML stanza is the basic unit of meaning
      in XMPP.  A stanza is only a first-level element (at depth=1 of
      the stream) whose element name is "message", "presence", or "iq"
      and whose qualifying namespace is 'jabber:client' or 'jabber:
      server'.  By contrast, a first-level element qualified by any
      other namespace is not an XML stanza (stream errors, stream
      features, TLS-related elements, SASL-related elements, etc.), nor
      is a <message/>, <presence/>, or <iq/> element that is qualified
      by the 'jabber:client' or 'jabber:server' namespace but that
      occurs at a depth other than one (e.g., a stanza that is included
      as the child element of a stanza for reporting purposes), nor is a
      <message/>, <presence/>, or <iq/> element that is qualified by a
      namespace other than 'jabber:client' or 'jabber:server'.  An XML
      stanza typically contains one or more child elements (with
      accompanying attributes, elements, and XML character data) as
      necessary in order to convey the desired information, which MAY be
      qualified by any XML namespace (see [XML-NAMES] as well as
      Section 8.4 in this specification).

In Section 4.7.5:

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if the server to which
      the client is connected needs to route a client-generated stanza
      to another server then it MUST "re-scope" the stanza (i.e., the
      first-level <message/>, <presence/>, or <iq/> element qualified by
      the 'jabber:client' namespace) so that its content namespace is
      'jabber:server' (i.e., it MUST NOT send a stanza qualified by the
      'jabber:client' namespace over a stream whose content namespace is
      'jabber:server').  Similarly, a routing server MUST "re-scope" a
      stanza received over a server-to-server stream (whose content
      namespace is 'jabber:server') so that the stanza is qualified by
      the 'jabber:client' namespace before sending it over a client-to-
      server stream (whose content namespace is 'jabber:client').  This
      rule applies only to XML stanzas as defined under Section 4.1.

And I think those small clarifications put this issue to rest.

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Nov 2010 23:00:03 +0000

> And I think those small clarifications put this issue to rest.

<!-- C2S -->

<message xmlns='jabber:client' to=[email-masked]' type='chat'>
  <body>You think?</body>
</message>

<!-- S2S -->

<message xmlns='jabber:server' from=[email-masked]/IETF'  
to=[email-masked]' type='chat'>
  <body xmlns='jabber:client'>You think?</body>
</message>

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 17:23:37 -0700

>  <body xmlns='jabber:client'>You think?</body>

You forgot the end game:

<!-- C2S -->

<message xmlns='jabber:client' to=[email-masked]' type='chat'>
 <body>I think so!</body>
</message>

<!-- S2S -->

<message xmlns='jabber:server' from=[email-masked]/squire'
to=[email-masked]' type='chat'>
 <body xmlns='jabber:client'>I think so!</body>
</message>

<!-- C2S -->

<message xmlns='jabber:client' from=[email-masked]/squire'
to=[email-masked]' type='chat'>
 <body>I think so!</body>
</message>

/psa

---

From: Matthew Wild <[email-masked]>
Date: Wed, 17 Nov 2010 00:24:44 +0000

>  <body xmlns='jabber:client'>You think?</body>

Translation (also based on an extensive discussion this evening in the
Prosody room):

The proposed text doesn't cover what to do about the namespaces of
children. Currently most servers change the xmlns on the top tag,
meaning that any descendents with the stream's default namespace (such
as <body> in the C2S example of Dave's) suddenly change from
jabber:client to jabber:server too.

>From an XML cleanliness point of view, <body> and other such tags are
really only meant to be in jabber:client (right?). This means that
after "re-scoping" they should retain the jabber:client namespace,
even if this means the server has to manually inject xmlns
declarations on them. The downside is, this does not at all reflect
what is currently done in practice today.

The real solution, of course, is to do away with re-scoping
altogether. There is and never was any need for a different namespace
on s2s streams, and any solution we try to come up with to work around
it is going to be less than perfect.

I suggest that for the sake of the document we seek documenting the
best *current* practice, with some restrictive text to ensure interop,
and avoid trying to fix something that really can't be fixed now.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 17:40:57 -0700

> jabber:client to jabber:server too.

That is the traditional behavior, yes.

> really only meant to be in jabber:client (right?). 

Not right. :) The schemas for both namespaces are identical except for
requiring 'to' and 'from' in the server namespace.

> This means that
> declarations on them. 

If your premise were correct, I'd agree with your conclusion. But your
premise is false.

> The downside is, this does not at all reflect

Because there's no necessity to change the child elements.

> altogether. 

And break all interoperability? Baby, say goodbye to bathwater.

> There is and never was any need for a different namespace
> on s2s streams, 

Talk to Jer about that. :P

> and any solution we try to come up with to work around

On that we can agree.

> and avoid trying to fix something that really can't be fixed now.

IMHO the preferred text would say that you touch only the root element
of the stanza and you don't add a namespace to child elements that are
unqualified. Thus:

<!-- C2S -->

<!-- S2S -->

<!-- S2C -->

You also do not change any child elements that are qualified:

<!-- C2S -->

<message xmlns='jabber:client' to=[email-masked]'>
  <report xmlns='urn:xmpp:example'>
    <message xmlns='jabber:client' from=[email-masked]/squire'
             to=[email-masked]' type='chat'>
      <body>I think so!</body>
    </message>
  </report>
</message>

<!-- S2S -->

<message xmlns='jabber:server' to=[email-masked]'>
  <report xmlns='urn:xmpp:example'>
    <message xmlns='jabber:client' from=[email-masked]/squire'
             to=[email-masked]' type='chat'>
      <body>I think so!</body>
    </message>
  </report>
</message>

<!-- S2C -->

<message xmlns='jabber:client' to=[email-masked]'>
  <report xmlns='urn:xmpp:example'>
    <message xmlns='jabber:client' from=[email-masked]/squire'
             to=[email-masked]' type='chat'>
      <body>I think so!</body>
    </message>
  </report>
</message>

C'mon folks, is this really so hard?

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Wed, 17 Nov 2010 01:01:05 +0000

> requiring 'to' and 'from' in the server namespace.

Sigh :)

> And break all interoperability? Baby, say goodbye to bathwater.

The s2s protocol is hairy in a number of places. I wonder if... oh
well, that's another document :)

> Talk to Jer about that. :P

Even Jer makes mistakes :)

> You also do not change any child elements that are qualified:

[snip]

> C'mon folks, is this really so hard?

Yes and no. The problem is the number of corner-cases.

--
<message>
   <foo xmlns="jabber:server"/>
</message>

<foo> would end up in jabber:client at the receiving side. Forbid
jabber:server elements *anywhere* in c2s streams?
--
<message>
   <body xmlns="jabber:client"/>
</message>

Here, should <body> be re-scoped to jabber:server? or should the
explicit xmlns declaration override that? I'd argue the former.
Correct?
--

As I said, I'm sure we can get something together even if it's not
pretty given what we have to work with. Hard, no - but not trivial
either.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 18:09:36 -0700

> Yes and no. The problem is the number of corner-cases.

A proposal:

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if the server to which
      the client is connected needs to route a client-generated stanza
      to another server then it MUST "re-scope" the stanza (i.e., the
      first-level <message/>, <presence/>, or <iq/> element qualified by
      the 'jabber:client' namespace) so that its content namespace is
      'jabber:server' (i.e., it MUST NOT route a stanza qualified by the
      'jabber:client' namespace over a stream whose content namespace is
      'jabber:server').  Similarly, a routing server MUST "re-scope" a
      stanza received over a server-to-server stream so that the stanza
      is qualified by the 'jabber:client' namespace before delivering it
      over a client-to-server stream.  This rule applies only to XML
      stanzas as defined under Section 4.1; when re-scoping a stanza for
      routing over a server-to-server stream, a server (i) MUST NOT
      modify the namespaces of explicitly qualified child elements even
      if the qualifying namespace is 'jabber:client', such as <body
      xmlns='jabber:client'/> (since such qualifying namespaces might be
      significant), and (ii) MUST NOT add a 'jabber:client' namespace to
      unqualified child elements defined by the 'jabber:client' schema,
      such as <body/> (since the 'jabber:client' and 'jabber:server'
      namespaces are semantically equivalent below the "root"
      <message/>, <presence/>, and <iq/> elements).

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 18:16:59 -0700

>       <message/>, <presence/>, and <iq/> elements).

Now with 15% more pedantry to cover your wacky cases like this:

<message>

###

      if the qualifying namespace is 'jabber:client' or 'jabber:server',
      such as <body xmlns='jabber:client'/> (since such qualifying
      namespaces might be significant), and (ii) MUST NOT add an
      explicit 'jabber:client' or 'jabber:server' namespace to

###

Sheesh.

---

From: Matthew Wild <[email-masked]>
Date: Wed, 17 Nov 2010 01:31:42 +0000

[snip]

>      when re-scoping a stanza for
>      namespaces might be significant)
>

Easier said than done. In many parser APIs, including expat in
namespace-aware mode, it wouldn't be possible to tell if an element
originally had an explicit xmlns declaration. You receive every
element along with its attributes and the namespace it is in. Because
of the various rules about xmlns handling and inheritance, it's quite
right that the parser should take care of this - and they are
semantically the exact same stanza after all, where the xmlns is
declared and where it isn't should have no bearing on processing.

In other words, I don't see that we can avoid:

<m xmlns="jabber:client">
   <b xmlns="jabber:client"/>
</m>

becoming

<m xmlns="jabber:server">
    <b xmlns="jabber:server"/> <!-- or omitted xmlns -->
</m>

over s2s streams.

What /could/ be said, however, is that (sigh, I don't want to be you
having to word this):

<!-- every xmlns declared explicitly for clarity -->
<stanza xmlns="jabber:client">
    <does-change xmlns="jabber:client">
        <still-does-change xmlns="jabber:client"/>
     </does-change>
     <other-element xmlns="someothernamespace">
         <does-not-change xmlns="jabber:client"/>
      </other-element>
</stanza>

becomes:

<stanza xmlns="jabber:server">
    <does-change xmlns="jabber:server">
        <still-does-change xmlns="jabber:server"/>
     </does-change>
     <other-element xmlns="someothernamespace">
         <does-not-change xmlns="jabber:client"/>
      </other-element>
</stanza>

In other words, re-scoping for stanzas and all their descendants, but
not re-scoping anything inside non-default-namespace elements.

> Sheesh.

+10. You know where Jer lives ;)

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 18:56:50 -0700

> declared and where it isn't should have no bearing on processing.

You make an excellent point.

> not re-scoping anything inside non-default-namespace elements.

Right. Further wordsmithing in progress.

> +10. You know where Jer lives ;)

Yeah, but it's a 13-hour drive from here. ;-)

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Tue, 16 Nov 2010 18:05:17 -0800

> not re-scoping anything inside non-default-namespace elements.

I agree on Matthew's points about how XML parsers generally work and how 
tracking declarations is discouraged/hard/impossible.

The suggestion that all elements in the hierarchy flip between "jabber:client" 
and "jabber:server", unless they are protected by a parent element that isn't 
in those namespaces, regardless of how any of these namespaces are declared, 
manages to document current practice while staying very clean.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 19:57:25 -0700

> manages to document current practice while staying very clean.

Agreed.

An updated proposal:

###

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if the server to which
      the client is connected needs to route a client-generated stanza
      to another server then it MUST "re-scope" the stanza so that its
      content namespace is 'jabber:server' (i.e., it MUST NOT route a
      stanza qualified by the 'jabber:client' namespace over a stream
      whose content namespace is 'jabber:server').  Similarly, a routing
      server MUST "re-scope" a stanza received over a server-to-server
      stream so that the stanza is qualified by the 'jabber:client'
      namespace before delivering it over a client-to-server stream.
      This rule applies to XML stanzas as defined under Section 4.1
      (i.e., a first-level <message/>, <presence/>, or <iq/> element
      qualified by the 'jabber:client' or 'jabber:server' namespace),
      along with any direct child elements of a stanza that are defined
      by the schemas for the 'jabber:client' and 'jabber:server'
      namespaces (e.g., <body/> or <status/>); however the rule does not
      apply to such elements located anywhere else within the data sent
      by a client or server (e.g., a <message/> element contained within
      an extension element for reporting purposes), or to elements
      qualified by other namespaces.

###

---

From: Justin Karneges <[email-masked]>
Date: Tue, 16 Nov 2010 23:41:55 -0800

On Tuesday 16 November 2010 18:57:25 Peter Saint-Andre wrote:
> > The suggestion that all elements in the hierarchy flip between
> > "jabber:client" and "jabber:server", unless they are protected by a
> > parent element that isn't in those namespaces, regardless of how any of
> > these namespaces are declared, manages to document current practice
> > while staying very clean.
> 
> Agreed.
> 
> An updated proposal:
> 
> ###
> 

Hmm, sorry to nitpick here but I think instead of only rescoping direct 
children it ought to be all children except when shielded by an element 
qualified by a non-default namespace, which is how Matthew originally described 
it.

How about changing:

"along with any direct child elements of a stanza that are defined by the 
schemas for the 'jabber:client' and 'jabber:server' namespaces (e.g., <body/> 
or <status/>); however the rule does not apply to such elements located 
anywhere else within the data sent by a client or server (e.g., a <message/> 
element contained within an extension element for reporting purposes), or to 
elements qualified by other namespaces"

to:

"along with all child elements of a stanza; however the rule does not apply to 
elements qualified by namespaces other than 'jabber:client' and 'jabber:server' 
nor to all children of such elements (e.g., a <message/> element contained 
within an extension element for reporting purposes)."

-Justin

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 17 Nov 2010 11:48:36 +0100

>       qualified by other namespaces.
With that text we still have (if I'm not overlooking something)

<!-- C2S -->
<stanza xmlns="jabber:client">
	<first-level-child xmlns="jabber:server"/>
</stanza>

<!-- S2S -->
<stanza xmlns="jabber:server">
	<first-level-child xmlns="jabber:server"/>
</stanza>

<!-- C2S -->
<stanza xmlns="jabber:client">
	<first-level-child xmlns="jabber:client"/>
</stanza>

i.e. the sent stanza differs from the received stanza.

I'm not sure we should actually care about this edge case, but AFAICT
that is one of the cases the thread starter complained about and it
doesn't look solved to me...

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 10:49:57 +0000

> doesn't look solved to me...

Easily solved with the following text:
"Clients MUST NOT send any data that are in the jabber:server namespace"

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 07:16:30 -0700

> qualified by a non-default namespace, which is how Matthew originally described 

The schemas for 'jabber:client' and 'jabber:server' contain only child
elements (subject, body, and thread for the message stanza, show,
status, and priority for the presence stanza), so in practice I don't
think it makes a difference.

> within an extension element for reporting purposes)."

Yes, that is better.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 07:20:04 -0700

> "Clients MUST NOT send any data that are in the jabber:server namespace"

+1 to that. I've modified the following paragraph:

   Client implementations MUST support the 'jabber:client' content
   namespace as a default namespace.  The 'jabber:server' content
   namespace is out of scope for an XMPP client, and a client MUST NOT
   send any data qualified by the 'jabber:server' namespace.

/psa

---

From: Matthew Wild <[email-masked]>
Date: Wed, 17 Nov 2010 14:31:48 +0000

>   send any data qualified by the 'jabber:server' namespace.

A big +1 from me to all the latest text.

Thanks for bearing with us! :)
Matthew

---

From: Mridul Muralidharan <[email-masked]>
Date: Wed, 17 Nov 2010 20:11:00 +0530 (IST)

So to summarize, if I am not wrong, the final set of recommendations seem to be 
:

1) clients/servers should not extend the jabber:client and jabber:server 
namespace if they can help it.
This should be interesting from forward & migration compatibility point of view 
:-)

2) clients MUST NOT use jabber:server namespace at all.
This might be problematic - resulting in hacks like sending snippets of xml 
encoded as text, etc ... not very 'xml-ly'.

3) servers MUST only change xmlns of stanza root element from jabber:client to 
jabber:server (and vice-versa on reception) - by inheritance, if namespace 
changes, fine : else it remains same.

4) Clients and servers MUST NOT use namespace prefix for the content namespace.
This is pretty restrictive on client libraries and implementations : thankfully, 
most are already conforming to this (by convention ?).

Hopefully I am not missing anything.
This should, unless I am overlooking something, address the cornercases I 
observed.

Thanks !
Mridul

----- Original Message ----
> Sent: Wed, 17 November, 2010 7:50:04 PM

---

From: Matthew Wild <[email-masked]>
Date: Wed, 17 Nov 2010 14:56:54 +0000

> This should be interesting from forward & migration compatibility point of view

I think that was already a given. I think everyone is pretty good at
using their own namespaces for stuff, that's just the way things are
done in XMPP. You can't introduce your own elements ad-hoc into an
existing and well-defined schema.

> encoded as text, etc ... not very 'xml-ly'.

I doubt it. If it's transmitted as XML then it should use the correct
namespace for the tags. Since there is absolutely no reason to use
tags from jabber:server in a c2s stream (because they have exact
equivalents in jabber:client) then there is no need to allow this.

If it's random unvetted XML then it'll likely be text already, e.g.
transmitted inside the <body> of a message. It's no longer XML as far
as XMPP is concerned and namespaces don't matter.

Perfectly "xml-ly" if you ask me.

Correct.

Correct.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 08:19:09 -0700

> existing and well-defined schema.

A big +1 to that. If you want new features, define new namespaces.

Agreed.

>> most are already conforming to this (by convention ?).

Yep, that all looks correct.

Peter

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

---

From: Mridul Muralidharan <[email-masked]>
Date: Thu, 18 Nov 2010 00:34:33 +0530 (IST)

----- Original Message ----
> From: Matthew Wild <[email-masked]>
> Sent: Wed, 17 November, 2010 8:26:54 PM

The xmpp schema, as defined in rfc, allows for it.
So from an xml correctness point of view, it is to be supported (for example: 
for streaming xml parsers).
Whether these changes are mandated by a change in spec, or by custom 
implementation : as long as schema allows for it, implementations (parsers, etc) 
must support it. Hence the need for clarification.

> Perfectly  "xml-ly" if you ask me.

I really dont want to get into actual usecases of why this would be required : 
suffice to say, there are usecases which would need transmitting stanza's :  to 
tunnel one connection over another for example. Changes specified implies that 
xml snippets "wrapped" in message, etc wont work anymore : and we will need to 
essentially transmit the snippets as text or other encoded format.

If the spec clearly mandates that this is not supported - then it is fine, we 
will need to look at other encoding : as long as it was not clear, we were not 
sure where it could/would work, where it would fail - and or what the expected 
behavior was !

Thanks for clarification !
Regards,
Mridul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:01:02 -0700

> must support it. Hence the need for clarification.

The schema defines the namespace! If you send <presence type='mridul'/>
you are in violation of the schema. I don't see how you can construe
things differently.

> sure where it could/would work, where it would fail - and or what the expected 

The current wording would allow you to do something like this:

<iq type='set' xmlns='jabber:client'>
  <tunnel xmlns='urn:xmpp:example'>
    <message xmlns='jabber:server'>
      <foo xmlns='http://example.com/ns'/>
    </message>
  </tunnel>
</iq>

But not this (over a client-to-server stream):

<presence xmlns='jabber:server'/>

However, to make that clearer, I think we could change this:

   a client MUST NOT send any data qualified by the
   'jabber:server' namespace

to:

   a client MUST NOT send any stanzas qualified by the
   'jabber:server' namespace

or even:

   a client MUST NOT send any first-level elements qualified
   by the 'jabber:server' namespace

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 22:04:06 +0000

>      <foo xmlns='http://example.com/ns'/>

The text I sent was intended to disallow this. A client shouldn't be
sending anything in jabber:server, at all. In my /very/ humble
opinion..

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:06:23 -0700

> sending anything in jabber:server, at all. In my /very/ humble

Given that the <message/> element above is wrapped in some other
namespace and thus shielded from the re-scoping operation, is there harm
in allowing it? I don't have a strong opinion either way (I admit that I
see no good reason to send such data, but I can imagine some scenarios
in which it might be legitimate, such as abuse reporting).

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Wed, 17 Nov 2010 15:10:56 -0700

> sending anything in jabber:server, at all. In my /very/ humble

It's not feasible to enforce a "no 'jabber:server' elements EVER" policy.  At the stanza (first-child) layer; definitely.  At the second (direct payload) layer; most likely.  At *any* layer; that's seems like a good chunk of wasted processing to me.

- m&m

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 22:12:11 +0000

> in which it might be legitimate, such as abuse reporting).

Well, if we can mandate that the default namespace is declared only
once, in the stream header, then this seems reasonable. Then a server
need only pass the stanzas straight through without mangling them and
everything's good. If we do that, I don't have a problem with saying
that servers pass through any explicitly namespaced stanza children,
irrespective of whether they're urn:xmpp:delay or jabber:server I
guess. What I don't like is the way we seem to be going with requiring
deep inspection with special rules about which children need
rescoping, which don't, etc.

But I don't  think this is an issue worth delaying over overly much, I
would have been happy with the text as it was before the start of this
thread, so as long as we don't take a big step backwards it seems
fine.

/K

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 22:12:53 +0000

> It's not feasible to enforce a "no 'jabber:server' elements EVER" policy.  At the stanza (first-child) layer; definitely.  At the second (direct payload) layer; most likely.  At *any* layer; that's…

The intention wasn't to require servers to validate this. It was to
tell clients not to do it, and if you do, well - a pox upon you, good
sir.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:29:03 -0700

/me glances at his deadline clock, which shows ~8 hours before submit

> rescoping, which don't, etc.

Yes, I don't like DPI, either.

IMHO the child elements would be re-scoped by inheritance from the
stanza level. Some parsers might do that by adding 'jabber:server' to
each unqualified child element, and some might do that by adding it only
to the stanza element itself (implementation detail). But I think it
would be odd for the server to perform deep packet inspection and then
re-scoping surgery on elements way down in the hierarchy.

> thread, so as long as we don't take a big step backwards it seems

Agreed. Here is what I now have in my working copy for the relevant part
of Section 4.7.5 (includes some small text fixes):

###

   Client implementations MUST support the 'jabber:client' content
   namespace as a default namespace.  The 'jabber:server' content
   namespace is out of scope for an XMPP client, and a client MUST NOT
   send stanzas qualified by the 'jabber:server' namespace.

   Server implementations MUST support as default content namespaces
   both the 'jabber:client' namespace (when the stream is used for
   communication between a client and a server) and the 'jabber:server'
   namespace (when the stream is used for communication between two
   servers).  When communicating with a connected client, a server MUST
   NOT send stanzas qualified by the 'jabber:server' namespace; when
   communicating with a peer server, a server MUST NOT send stanzas
   qualified by the 'jabber:client' namespace.

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if the server to which
      the client is connected needs to route a client-generated stanza
      to another server then it needs to "re-scope" the stanza so that
      its content namespace is 'jabber:server'.  Similarly, a routing
      server needs to "re-scope" a stanza received over a server-to-
      server stream so that the stanza is qualified by the 'jabber:
      client' namespace before delivering it over a client-to-server
      stream.  This rule applies to XML stanzas as defined under
      Section 4.1 (i.e., a first-level <message/>, <presence/>, or <iq/>
      element qualified by the 'jabber:client' or 'jabber:server'
      namespace), and by inheritance to all child elements of a stanza;
      however the rule does not apply to elements qualified by
      namespaces other than 'jabber:client' and 'jabber:server' nor to
      any children of such elements (e.g., a <message/> element
      contained within an extension element (Section 8.4) for reporting
      purposes).

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:40:59 -0700

>       contained within an extension element (Section 8.4) for reporting

That's confusingly worded in places. I think this is more readable:

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if a server routes to
      a peer server a stanza it has received from a connected client
      then it needs to "re-scope" the stanza so that its content
      namespace is 'jabber:server'.  Similarly, if a server delivers to
      a connected client a stanza it has received from a peer server
      then it needs to "re-scope" the stanza so that its content
      namespace is 'jabber:client'.  This rule applies to XML stanzas as
      defined under Section 4.1 (i.e., a first-level <message/>,
      <presence/>, or <iq/> element qualified by the 'jabber:client' or
      'jabber:server' namespace), and by namespace inheritance to all
      child elements of a stanza; however the rule does not apply to
      elements qualified by namespaces other than 'jabber:client' and
      'jabber:server' nor to any children of such elements (e.g., a
      <message/> element contained within an extension element
      (Section 8.4) for reporting purposes).

/psa

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 22:41:05 +0000

>      contained within an extension element (Section 8.4) for reporting

This seems to be internally consistent, and clearly specified,
addressing all the previously noted interop issues. Whether it's the
very best we could do I'm not sure, but it seems sufficient and
timely. I'd suggest simply appending the following text (or something
wordsmithed to your satisfaction), but won't cry foul if you disagree:
"""
While it is not forbidden for entities to generate stanzas whereby a
child element with an extension namespace has a child whose namespace
is 'jabber:client' or 'jabber:server', it is known that existing
implementations will handle this inconsistently, so an implementor
will need to weigh this against the possible utility of such a stanza.
"""

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:43:34 -0700

On 11/17/10 3:41 PM, Kevin Smith wrote:

> I'd suggest simply appending the following text (or something

That seems helpful, thanks. It *is* an implementation note, after all. ;-)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 15:51:03 -0700

> That seems helpful, thanks. It *is* an implementation note, after all. ;-)

Wordsmithed in my working copy to:

                                              Although it is not
      forbidden for an entity to generate stanzas in which an extension
      element contains a child element qualified by the 'jabber:client'
      or 'jabber:server' namespace, existing implementations handle such
      stanzas inconsistently; therefore implementers are advised to
      weigh the likely lack of interoperability against the possible
      utility of such stanzas.

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Nov 2010 23:04:29 +0000

>      weigh the likely lack of interoperability against the possible

Ta.

/K

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 18 Nov 2010 00:22:39 +0100

>       weigh the likely lack of interoperability against the possible

I start feeling bad about saying this, but my comment still holds true.
<message xmlns="jabber:client"><body xmlns="jabber:server"/></message>
will ultimately end up as
<message xmlns="jabber:client"><body/></message>
even when following the proposed text to the letter (assuming
namespace-awareness).
It's true we do additionally have a inconsistency, because servers that
don't use parsers in namespace-aware mode do actually re-re-scope the
stanzas as
<message xmlns="jabber:client"><body xmlns="jabber:server"/></message>
but technically, that is due to wrong handling of namespaces...

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 16:35:29 -0700

> even when following the proposed text to the letter (assuming

Yes, that's true, and I think it's intentional. I also think it doesn't
matter, because the two namespaces are semantically equivalent.

> but technically, that is due to wrong handling of namespaces...

Yeah, we can't design around such bugs. :)

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Wed, 17 Nov 2010 17:19:59 -0800

> matter, because the two namespaces are semantically equivalent.

Yup, my feeling too.  You pretty much only ever want one or the other 
namespace.  When mixing, don't be surprised if they merge along the way.  If 
there is ever an XMPP extension that suggests using an element in the 
"jabber:server" namspace as a direct child of a "jabber:client" stanza, it 
would do so while understanding the consequences.

In practice, it's simple enough to use a specially-namespaced wrapper element 
whenever one of "jabber:client" or "jabber:server" needs to be preserved.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 18:22:07 -0700

> whenever one of "jabber:client" or "jabber:server" needs to be preserved.

I very much agree.

Hopefully the text in -19 captures all that. :)

Peter

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

---

From: Mridul Muralidharan <[email-masked]>
Date: Thu, 18 Nov 2010 11:52:11 +0530 (IST)

So essentially, direct children under stanza MUST NOT be jabber:server - but any jabber:server xml snippet MUST be within a custom (neither jabber:client, jabber:server or component) namespace.

That looks reasonable, thanks for clarifying !

Regards,
Mridul

--- On Thu, 18/11/10, Peter Saint-Andre <[email-masked]> wrote:

> Date: Thursday, 18 November, 2010, 6:52 AM
> >>>>>> is 'jabber:client' or
> 'jabber:server', it is known that existing
> >>>>> That seems helpful, thanks. It *is* an
> implementation note, after all.
> >>>>> ;-)
> >>>>
> >>>>       forbidden
> for an entity to generate stanzas in which an extension
> >>>>       element
> contains a child element qualified by the 'jabber:client'
> >>>>       or
> 'jabber:server' namespace, existing implementations handle
> such
> >>>>       stanzas
> inconsistently; therefore implementers are advised to
> >>>>       weigh the
> likely lack of interoperability against the possible
> >>>>       utility of
> such stanzas.
> >>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Nov 2010 06:38:22 -0700

On 11/17/10 11:22 PM, Mridul Muralidharan wrote:
> 
> So essentially, direct children under stanza MUST NOT be
> jabber:server - but any jabber:server xml snippet MUST be within a
> custom (neither jabber:client, jabber:server or component)
> namespace.

Exactly!

/psa