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

From: Jehan Pagès <[email-masked]>
Date: Thu, 30 Sep 2010 07:21:20 +0900

Hi,

I am reviewing most of 3920 lately for a development, so I noticed a
few minor stuffs.

1/ Section "11.1 Restrictions":

In the html version of the draft, there are four links in the list of
restricted XML features which points to internal sections of the XMPP
draft, while they are supposed to point to sections in the [XML]
document. Bug to fix.

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 (I remember this was a remark I already done, and it
was taken into account for the main paragraph about XML declaration
but some instances have been forgotten elsewhere apparently ;-).
If you read the XMP spec, I remind that the XML declaration is at the
beginning of an XML document, whereas the text declarations are at the
beginning of external entities (not existent in XMPP).

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

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

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

Ok that's all for now. I might not be able to respond for 2 weeks
after saturday, or even just read emails, but then I should be made
more available from then. :-) And I might even find other stuffs (bugs
or observations) again after.
Bye all!

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 12:38:22 -0600

> I am reviewing most of 3920 lately for a development, so I noticed a

I'll consider these as instances of "IETF Last Call" feedback.

> draft, while they are supposed to point to sections in the [XML]

That's a tooling issue. The ASCII text is canonical anyway. :)

> right term to use

Correct.

> anything external), but I wonder if we would not gain in clarity by

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

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

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

> used technology, in particular related to XML. Though it might

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

> or observations) again after.

IETF Last Call (typically 4 weeks long) will begin soon. After that the
formal community comment period will be finished, although IETF Last
Call will be followed by IESG review and editorial review by the RFC
Editor team. Lots of reviews. :)

Peter

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

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 1 Oct 2010 01:28:50 +0500

> a stream error then <bad-format/> seems like the right condition.

Or to be more specific: <restricted-xml/>

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 14:35:40 -0600

> Or to be more specific: <restricted-xml/>

Yes I almost suggested that -- probably it's better to be more specific.

Peter

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