Subject: Re: [xmpp] A few fixes to draft-ietf-xmpp-3920bis-16

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 08:05:02 -0600

On 9/30/10 12:38 PM, Peter Saint-Andre wrote:
> On 9/29/10 4:21 PM, Jehan Pagès wrote:

<snip/>

>> 2/ section "4.1 Streams overview":
>>
>> «
>> The
>>    client initiates an XML stream by sending a stream header to the
>>    server, optionally preceded by a *text declaration* specifying the XML
>>    version and the character encoding supported (see Section 11.5 and
>>    Section 11.6).  Subject to local policies and service provisioning,
>>    the server then replies with a second XML stream back to the client,
>>    again optionally preceded by a *text declaration*.
>> »
>>
>> two times are used "text declaration" while "XML declaration" is the
>> right term to use
> 
> Correct.

Fixed in my working copy.

>> 3/ 11.5. Inclusion of XML Declaration:
>>
>> We just say to follow the rules of XML. I was wondering about the
>> SDDecl (Standalone Document Declaration). Shouldn't we precise that it
>> should not be included or always to "yes".
>> 
>> This seems obvious to me (because a XMPP stream does not include
>> anything external), but I wonder if we would not gain in clarity by
>> precising it.
> 
> (I like your new English verb "to precise"! :)
> 
> Section 11.1 of 3920bis-16 forbids external markup declarations and
> parameter entities in XMPP, so XMPP streams are always standalone='yes'.
> 
> The XML spec says:
> 
>    If there are no external markup declarations, the standalone
>    document declaration has no meaning.
> 
> Now, because there will never be external markup declarations in an XMPP
> stream, the standalone document declaration will never have any meaning.
> 
>> And especially: how do we react if someone send a SDDecl to "no" at
>> the beginning of a stream? Should we just ignore it or send a stream
>> error (which seems better to me, because if the entity really hopes us
>> to reach external declarations, it is obviously non compliant XMPP).
>> This should be added, I think.
> 
> Do we want to return an error in response to data that has no meaning?
> It seems fine to ignore such data. However, if a server wants to return
> a stream error then <bad-format/> seems like the right condition.

In my working copy, I've added the following paragraph to Section 11.5:

   Because external markup declarations are prohibited in XMPP (as
   described under Section 11.1), the standalone document declaration
   (matching production [32] content of [XML]) would have no meaning and
   therefore SHOULD NOT be included in an XML declaration sent over an
   XML stream.  If an XMPP entity receives an XML declaration containing
   a standalone document declaration set to a value of "no", the entity
   MUST either ignore the standalone document declaration or return a
   stream error (which SHOULD be <restricted-xml/>).

>> 4/ 4.7.2. Default Namespace:
>>
>> the definition and example of "prefix-free canonicalization" shows
>> that basically in such logics, the streams namespace is used as
>> default, which contradicts the rule (1) edicted just before:
>> « (1) the default namespace MUST be other than the
>>    streams namespace »
>>
>> I guess this should should be removed (or made clearer that this is
>> only one of the two possible namespace logics we use).
> 
> Hmm yes. I will look at that more closely, but I agree that we need to
> "precise" the description.

I'll post separately about this issue.

>> 5/ 4.7.4. Namespace Declarations and Prefixes:
>>
>> «
>>    By definition, the namespace declaration for the default namespace
>>    will not include a namespace prefix (e.g., "xmlns='jabber:client'").
>> »
>>
>> As this is indeed by definition, do we need to precise that? Actually
>> I think there are a lot of places we maybe over-precise stuffs which
>> are actually unneeded because they are already defined in the specs of
>> used technology, in particular related to XML. Though it might
>> contradict my point 3/.
> 
> The example is wrong there anyway, so I think it's fine to delete that text.

Done in my working copy.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 09:47:31 -0600

> only one of the two possible namespace logics we use).

This is a bit sticky but it is mostly a matter of nomenclature, because
we were inadvertently conflating the meaning of "default namespace" from
the "Namespaces in XML" specification with the 'jabber:client' and
'jabber:server' namespaces used in XMPP to define the data we typically
send in XMPP.

You are right that if "prefix-free canonicalization" is used at the
stream level (i.e., no <stream:stream/> or <stream:error/> prefixing),
the default namespace (as defined by the "Namespaces in XML" spec) is in
fact the streams namespace.

By contrast, if "prefix-free canonicalization" is *not* used at the
stream level then the default namespace is a namespace other than the
streams namespace. I propose that we call that other namespace the
"content namespace", and that we change most instances of "default
namespace" to "content namespace".

The impact of this change is mostly limited to Section 4.7, although it
also results in small changes to other sections.

Here is a revised Section 4.7 so you can see what I propose.

###

4.7.  Namespaces

   Readers are referred to the specification of XML namespaces
   [XML-NAMES] for a full understanding of the concepts used in this
   section, especially the concept of a "default namespace" as provided
   in Section 3 and Section 6.2 of that specification.

4.7.1.  Streams Namespace

   The root <stream/> element ("stream header") MUST be qualified by the
   namespace 'http://etherx.jabber.org/streams' (the "streams
   namespace").  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/> (although some existing
   implementations send <bad-format/> instead).

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

   Alternatively (i.e., instead of declaring the content namespace as
   the default namespace), an entity MAY explicitly qualify the
   namespace for each first-level child element of the stream, using so-
   called "prefix-free canonicalization".  These two styles are shown in
   the following examples.

   When a content namespace is declared as the default namespace, in
   rough outline a stream will look something like the following.

   <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'>
     <message>
       <body>foo</body>
     </message>
   </stream:stream>

   When a content namespace is not declared as the default namespace and
   so-called "prefix-free canonicalization" is used instead, in rough
   outline a stream will look something like the following.

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

   Historically, most XMPP implementations have used the content-
   namespace-as-default-namespace style rather than the prefix-free
   canonicalization style for stream headers; however, both styles are
   acceptable since they are semantically equivalent.

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 Server Dialback
   [XEP-0220] and Stream Management [XEP-0198].

      Interoperability Note: For historical reasons, some server
      implementations expect a declaration of the 'jabber:server:
      dialback' namespace on server-to-server streams; for details, see
      [XEP-0220].

4.7.4.  Namespace Declarations and Prefixes

   Because the content namespace is other than the streams namespace, if
   a content namespace is declared as the default namepsace then the
   following statements are true:

   1.  The stream header needs to contain a namespace declaration for
       both the content namespace and the streams namespace.

   2.  The streams namespace declaration needs to include a namespace
       prefix for the streams namespace.

      Interoperability Note: For historical reasons, an implementation
      MAY accept only the prefix 'stream' for the streams namespace
      (resulting in prefixed names such as <stream:stream> and <stream:
      features>).  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/>
      (although some existing implementations send <bad-format/>
      instead).

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

   Namespaces declared in a stream header MUST apply only to that stream
   (e.g., the 'jabber:server:dialback' namespace used in Server Dialback
   [XEP-0220]).  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 ensure that such namespaces
   are properly declared (according to this section) when routing or
   delivering stanzas originating from such a stream over streams with
   other entities.

4.7.5.  Mandatory-to-Implement Content Namespaces

   XMPP as defined in this specification uses two content namespaces:
   'jabber:client' and 'jabber:server'.  These 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.  Support for these content namespaces implies
   support for the common attributes (Section 8.1) and basic semantics
   (Section 8.2) of all three core stanza types (message, presence, and
   IQ).

   An implementation MAY support content 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.

   An implementation MAY refuse to support any other content namespaces
   as default namespaces.  If an entity receives a first-level child
   element qualified by a content namespace it does not support, it MUST
   return an <invalid-namespace/> stream error.

   Client implementations MUST support the 'jabber:client' content
   namespace as a default namespace.

   Server implementations MUST support as default namespaces both the
   'jabber:client' content namespace (when the stream is used for
   communication between a client and a server) and the 'jabber:server'
   content namespace (when the stream is used for communication between
   two servers).

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

###

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 5 Oct 2010 02:15:46 +0900

Hi,

finally I did not resist to check and read my emails, then make an
answer. :-D I am in Shanghai, China, at the Universal Exposition, and
let me tell you: it sucks like Hell (actually Hell is surely less
annoying and more ecological). I don't know how people comes here
willingly to be stuck their head all day with "country-publicity" and
"corporate/Coca-Cola-publicity" (not even talking about paying for
this...), all this happily waiting and pushed all day in various
waiting queues; not to take into account it takes place into
extraordinary expensive and eccentric buildings built only for a few
monthes (after they expelled thousands of people from their previous
homes that they destroyed "for the greater good") and made to be
destroyed as well after in the most unecological logics that could
ever be (all this by displaying great speeches about how ecological
they are).

No really some human logics will always escape me...

Anyway, below my answers:

>>> 2/ section "4.1 Streams overview":
[...]
> Fixed in my working copy.

Cool.

>> (I like your new English verb "to precise"! :)

Sorry I thought it was actual English. So apparently it is not. :-D

[...]

>   stream error (which SHOULD be <restricted-xml/>).

Suits me well.

>>> 4/ 4.7.2. Default Namespace:
[...]
> I'll post separately about this issue.

So I will look at this answer separately. ;-)

>> The example is wrong there anyway, so I think it's fine to delete that text.

Nice.

Thanks for all.

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 5 Oct 2010 02:38:24 +0900

Hi,

I read fast for now, so I might have corrections later. But the first
impression is good. Some notes below though:

> namespace" to "content namespace".

I really like adding this new concept of "content namespace". I think
it clarify pretty much a lot of the descriptions.

>   in Section 3 and Section 6.2 of that specification.

Why do you call this "streamS namespace" (with a 'S') and not just
"stream namespace"?

>   following statements are true:

Small typo: s/namepsace/namespace/

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

No other remark for now. Look globally good, but as I said, I read
this all very fast.
Thanks for this awesome work, as always.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 11:49:24 -0600

> it clarify pretty much a lot of the descriptions.

Super.

> Why do you call this "streamS namespace" (with a 'S') and not just

Probably because the namespace is 'http://etherx.jabber.org/streams'
with an "s" on the end -- we called it the "streams namespace" in RFC
3920 and I didn't think to change it.

> Small typo: s/namepsace/namespace/

Fixed.

> Thanks for this awesome work, as always.

Sure thing. You'll have another chance to read over the text during IETF
Last Call.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 20 Oct 2010 06:48:20 +0900

Hi,

I'd like to come back on the definition of prefix-free
canonicalization and its example:

[...]
>   called "prefix-free canonicalization".  These two styles are shown in

Here what I would understand is that there is no default namespace at
all. In particular we write that we would explicity qualify the
namespace for "each first-level chilf element of the stream". We
didn't write "each stanza", so I would say we apply this also for
instance to stream elements (stream errors or features for instance).
So basically no ' xmlns="whatever" ' at all in the stream start tag.

But the example says otherwise as our default namespace is the streams

>     <message xmlns='jabber:client'>

So for this example to correspond, the text should rather read something like:

«
   Alternatively (i.e., instead of declaring the content namespace as
   the default namespace), an entity MAY declare the streams
   namespace as the default namespace, thus explicitly qualify the
   namespace for each other first-level child element of the stream,
   using so-called "prefix-free canonicalization".  These two styles are
   shown in the following examples.
»

What do you think?
Thanks.

Jehan

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Oct 2010 23:24:13 +0100

> So basically no ' xmlns="whatever" ' at all in the stream start tag.
That's not what it says. It says no "content namespace" - by which I  
understand it to mean "jabber:client" or "jabber:server", for example.

So the example is exactly as I'd expect.

FWIW, I'm not a fan of such usage, as it prevents use of a single  
port to handle clients and servers (and XEP-0114 components), but I'm  
doing the work to handle this in M-Link, so I'm not going to object.

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: Wed, 20 Oct 2010 07:45:54 +0900

Hi,

On Wed, Oct 20, 2010 at 7:24 AM, Dave Cridland <[email-masked]> wrote:
> On Tue Oct 19 22:48:20 2010, Jehan Pagčs wrote:
>>
>> Hi,
>>

Hum... Ok. I still think it to be a little unclear, but if I might
consider the example to clarify this, so why not...

> FWIW, I'm not a fan of such usage, as it prevents use of a single port to
> handle clients and servers (and XEP-0114 components), but I'm doing the work
> to handle this in M-Link, so I'm not going to object.

So what is your solution to this for information? If someone sets the
streams namespace as the default one, how do you detect it is a
server, a component or a client in M-Link?
Do you use the "from" information (mandatory for a server in
particular), checking if there is a localpart (but is that all that
relevant, in particular for the components entities?)?
Your workaround to such usage would be interesting.

Thanks.

Jehan