Subject: [xmpp] RFC 6120: stream error when no stream id?

From: Jehan Pagès <[email-masked]>
Date: Mon, 11 Apr 2011 03:30:38 +0900

Hi,

as we always see things when it is too late (or at least for the
current RFC), but... in "4.7.3. id":

«
For response stream headers, the receiving entity MUST include the
   'id' attribute.
»

But the section does not detail any stream error which might be sent
if the receiving entity does not include a stream id, nor do I seem to
find any stream error in the list which might be usable in such a
case. Is that missing? What is supposed to be the reaction of a
compliant XMPP implementation here?
Thanks.

Jehan

---

From: Matthew Wild <[email-masked]>
Date: Sun, 10 Apr 2011 21:42:17 +0100

> compliant XMPP implementation here?

If it were the client that could omit the id and not the server, I'd
see more reason for a dedicated stream error. However as it is a
server that doesn't send the 'id' isn't an XMPP server. After you have
established that, what good is 1) continuing to pretend you're doing
XMPP 2) informing the server it is not an XMPP server?

More useful for a client would be to inform the user that the server
is broken, I think.

In summary, close the stream - that's a FIN, </stream:stream> or
<undefined-condition/> (perhaps with <text> or an application-defined
error) if you insist on sending an error. I don't think the rarity of
this error warrants any special handling or a dedicated error
condition though.

Regards,
Matthew

PS. On the other hand... RFC 3920 had <invalid-id/> and I just noticed
that it's still in the 6120 schema - "oops" :)

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 11 Apr 2011 06:23:23 +0900

Hi,

> XMPP 2) informing the server it is not an XMPP server?

I don't agree. That's a bug, that's all. So we must send an error to
inform the server, hence eventually letting the operators/implementers
know something is broken in their server and fix them (if they see a
lot of the same error about not sending an id in their logs, they
would begin to see there is an issue).

Of course, you could say that's a big bug so any server would have it.
But as the same section of RFC6120 states:
«
      Interoperability Note: In RFC 3920, the text regarding inclusion
      of the 'id' attribute was ambiguous, leading some implementations
      to leave the attribute off the response stream header.
»

And I guess that some clients may be letting the error pass because of
the fact that some server are not sending ids (because ambiguous in
RFC3920). So that would be useful to have more strict clients which
can send useful errors to the servers.

So I personally completely disagree with both your points:
1) this is a bug and that's all. It does not make the implementation
completely "not-XMPP" because there is a bug! Or if we go this way, as
soon as you have a bug (which makes the implementation not compliant
with the RFC), you can say you are not doing XMPP, so we can stop
right away then. Because if so, I think there exists actually no XMPP
implementation in this world (I doubt there is a single XMPP
implementation right now, client or server, which is perfectly without
a single bug).
A server which sends something not XML at all: that's not XMPP. Ok. It
sends me a stream header, but forgets the id: that's XMPP with a bug.
I really see a big difference.

2) It is always useful to inform others of their errors. If we go
further in your optic, we can as well stop sending any error (stream,
stanza or whatever) at all.

> More useful for a client would be to inform the user that the server

That's good to inform the user also. Maybe he will go make a bug
report... or not. But if the server is bugged, I think the first step
is to inform the server automatically. That's the whole point of
having stream errors.

> this error warrants any special handling or a dedicated error

I don't know how rare is the error. But the interoperability note in
the RFC that I quoted above let me think that it may not be that rare.
And in the end, I don't see why this stream error deserves less a
dedicated error than others (stream errors are *all* rares. They break
the stream, so they are the kind of errors any implementation really
look for and try to fix fast).

> that it's still in the 6120 schema - "oops" :)

And so why has this error been removed in FC6120? :-/

Regards,

Jehan

---

From: Matthew Wild <[email-masked]>
Date: Sun, 10 Apr 2011 23:06:12 +0100

>      to leave the attribute off the response stream header.

I don't know which implementations those are. The stream id has
historically been used for a number of things, e.g. component auth and
dialback spring to mind. I think any server omitting the 'id'
attribute would have a hard time on today's network.

> the RFC that I quoted above let me think that it may not be that rare.

As above, I think you'll find it's very rare. No popular
implementation is going to have this bug for long, given how many
things break without it.

> look for and try to fix fast).

The most common stream errors I see are not-well-formed (buggy
client), host-unknown (misconfigured server or DNS),
connection-timeout (network or config issues), system-shutdown (server
restart). I have seen invalid-id, but only in the context of failed
dialback (jabberd2 uses it).

I maintain that there is little point in clients sending errors to
servers. Maybe I'm biased, being a server dev, but I don't intend to
argue about it. If you are so passionate about reporting this error
then send <undefined-condition> with <text> instead. We can't have a
stream error for every MUST in the spec that an implementation might
break, and this case deserves one less than any I can think of.

>From Appendix D: "Removed the unnecessary and unused <invalid-id/>
stream error (see RFC 3920 for historical documentation)."

Regards,
Matthew

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 11 Apr 2011 14:49:49 +0900

Hi,

> implementation is going to have this bug for long, given how many

I don't know how rare it actually is either. I did not check but still
I quoted the above. Every piece of text which has ever been added to
the RFC (especially on such a specific topic) has normally been added
for a reason. So I guess it must exist somewhere.

> dialback (jabberd2 uses it).

Of course, we won't see many of such error to be sure how rare it is
if it isn't anymore in the spec. ;-)

> break, and this case deserves one less than any I can think of.

I don't see why it deserves less than an invalid-from or
invalid-namespace. As you said yourself, that's some feature pretty
important for an healthy network.

And it is not that I am passionate (or maybe, but that's because I am
passionate in everything I do and I care about details). That's just
that I am writing a client side of XMPP. And this case is something
which can theoritically happen so I just wanted to know how to handle
this. I could of course simply close the stream as you suggest, but
that's definitely not "clean". The right way to close a broken stream
is with an error first-hand (and I would agree that it does not matter
if that's in fact not a XMPP server on the other side, but really some
entity that sends me an XML opening tag, labelled as a jabber stream
and with a jabber:client default namespace, though no id... I tend to
think that's just a broken XMPP server).

For the undefined-condition, I looked at it when I was first searching
for a stream error before sending the email. The description said:
«
this error condition SHOULD NOT be used
   except in conjunction with an application-specific condition.
»

> stream error (see RFC 3920 for historical documentation)."

Yep sorry, I should have checked myself. Got lazy (as an excuse, it
was about 6:20 AM when I sent my last email :p)...
See you!

Jehan

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 11 Apr 2011 07:59:58 +0200

> attribute would have a hard time on today's network.

More importantly, the response stream id was used in the obsolete XEP 
0078 digest authentication scheme. I think you would have had more 
(user-visible) problems omitting it in 2004 than you would have today.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 11 Apr 2011 11:57:00 +0100

> think that's just a broken XMPP server).

There are several cases where the correct way to close the stream is  
not with an error.

For one thing, the - hopefully normal - case of shutting down a  
client session would not have an error.

Now, if the client has decided that a stream is sufficiently broken  
that it cannot continue with the session, there are also cases where  
the correct thing to do is to simply close the stream and inform the  
user - not the server - as to the reasons why. Sometimes, it's  
arguably better to drop the connection rather than even send a stream  
closing tag.

On the other hand, having lots of very much edge-case errors seems to  
lay an additional burden that's bound to be skipped by someone not  
even bothering to issue a stream id.

Consider - if a server implementation doesn't support a stream id,  
then why on earth would the implementor carefully catch the error  
issued by a client in that instance?

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: Mon, 11 Apr 2011 20:41:48 +0900

Hi,

On Mon, Apr 11, 2011 at 7:57 PM, Dave Cridland <[email-masked]> wrote:
> On Mon Apr 11 06:49:49 2011, Jehan Pagčs wrote:
>>
> There are several cases where the correct way to close the stream is not
> with an error.
>
> For one thing, the - hopefully normal - case of shutting down a client
> session would not have an error.
>
> Now, if the client has decided that a stream is sufficiently broken that it
> cannot continue with the session, there are also cases where the correct
> thing to do is to simply close the stream and inform the user - not the
> server - as to the reasons why. Sometimes, it's arguably better to drop the
> connection rather than even send a stream closing tag.
>
> On the other hand, having lots of very much edge-case errors seems to lay an
> additional burden that's bound to be skipped by someone not even bothering
> to issue a stream id.
>
> Consider - if a server implementation doesn't support a stream id, then why
> on earth would the implementor carefully catch the error issued by a client
> in that instance?

Here you are making assumptions that the implementation has a bug
because the implementer is just a lazy ass. Nearly it looks like he
did the bug on purpose (he "doesn't support a stream id")!
This kind of thinking could be applied to nearly any bug and looks
like the kind of complaints some users do about developers to show
they are not happy and that we MUST work better.
That's sad to read it from developers as well.

I don't know if any implementation has this bug, but if any, I would
definitely not assume anything else than the objective fact it is a
bug (which can be for so many reasons).

Plus, the RFC itself gives a good reason why it would be perfectly
plausible to find such a bug, even with a very picky and hard-worker
developer: "In RFC 3920, the text regarding inclusion of the 'id'
attribute was ambiguous".

Anyway I don't really agree with any of the reasons I read about why
this specific case deserves less an error than others :-/ (of course,
the best one I see right now is that the RFC has just been released,
but that does not prevent us from talking for the long-time future, or
some errata). Though it's definitely not such a big deal.

Jehan

---

From: Remko Tronçon <[email-masked]>
Date: Mon, 11 Apr 2011 13:57:36 +0200

> this specific case deserves less an error than others

>From a pragmatic client developer's point of view: because all this
has no impact whatsoever on user experience of XMPP.

But I agree that a futile detail like this has been discussed a bit
much already. Let's just write it down and process it when the next
RFC is being written.

cheers,
Remko

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Apr 2011 14:16:16 -0600

> much already. Let's just write it down and process it when the next

Duly noted. :)