[xmpp] namespace prefix violations (was: Re: Agenda for the Interim Meeting)

[Peter Saint-Andre <[e-mail]>]

On 2/1/11 8:22 AM, Peter Saint-Andre wrote:
> 
> On 2/1/11 8:11 AM, Ben Campbell wrote:
> 
>> -- Handling namespace prefix rule violations: 15 Minutes -- Matthew
>> and/or Peter
> 
> This is something that Matthew Wild and I discussed privately a few
> weeks ago. I'll send a message to the list summarizing our discussion
> and conclusions.

Matthew and I had a long off-list discussion about this several weeks
ago. At issue is this paragraph in Section 4.8.5 of 3920bis:

   An XMPP entity MUST NOT accept data that violates this rule (in
   particular, an XMPP server MUST NOT route or deliver such data to
   another entity); instead it MUST either ignore the data or close the
   stream with a stream error, which SHOULD be <bad-namespace-prefix/>
   (Section 4.9.3.2).

Matthew pointed out to me that some XMPP servers are able to accept such
data because they (or the XML parser they use) transform the prefixed
data into an unprefixed stanza based on the qualifying namespace. That
is, the server essentially corrects the violation, which means that the
paragraph as it stands probably violates Postel's Law ("be liberal in
what you accept and conservative in what you send").

After some back-and-forth with Matthew, I suggested the following paragraph:

   If an XMPP entity receives data that violates this rule, it MAY
   refuse to accept the data because the data is inconsistent with the
   prefixing context that the sending entity established when it sent
   the stream header for its outbound stream; i.e., the entity MAY
   either ignore the data or close the stream with a stream error,
   which SHOULD be <bad-namespace-prefix/>.  If an XMPP server accepts
   such data and routes or delivers the data over an output stream to
   another entity, then it MUST transform the data into a legitimate
   stanza whose prefixing context is the same as that of the output
   stream (e.g., an unprefixed stanza if a content namespace was
   declared as the default namespace for the output stream).

I know that Matthew still has concerns with that paragraph, so I will
let him post to the list in reply.

My major concern here is that the text about namespace prefixing is a
bit fragile and that I think we need more implementation and deployment
experience with prefix-free canonicalization at the stream level before
we can provide solid text here. That's why I suggested to Matthew that
we postpone dealing with this issue until we work on "3920ter" (i.e.,
the hopefully-small revisions to 3920bis). IMHO there are just too many
unknowns here, and we could have some very long mailing list threads (as
we have in the past) without coming to consensus at this time.

Furthermore, I remind you all of the obvious: 3920bis has been approved
for publication, so we need to make sure that any changes are,
preferably, editorial in nature or quite small in scope.

With that in mind, one small change we could make would be to change
MUST to SHOULD and MUST NOT to SHOULD NOT, plus add some clarifying
words to the parenthetical clause:

   An XMPP entity SHOULD NOT accept data that violates this rule (in
   particular, an XMPP server MUST NOT route or deliver such data to
   another entity without correcting the violation); instead it SHOULD
   either ignore the data or close the stream with a stream error,
   which SHOULD be <bad-namespace-prefix/> (Section 4.9.3.2).

This allows a server to be liberal in what it accepts, while mandating
that it needs to be conservative in what it sends to other entities even
if it accepts such data.

Personally, I think that's the best we're going to do right now, and
that we should revisit this topic when we revise 3920bis. But let's not
get into major surgery on 3920bis at this point, because the time for
that is past.

Peter

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