Subject: [xmpp] #65: handling of a message whose only child element is not understood by the recipient

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 02:05:47 -0000

#65: handling of a message whose only child element is not understood by the
recipient
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 8.4 (Extended Content) states:

 > *  If an entity receives a message stanza whose only child
 > element is qualified by a namespace it does not understand,
 > it MUST silently ignore the entire stanza.

 Matthew Wild commented: "In the case of an unhandled message stanza sent
 to the bare domain of the server we bounce an error (service-unavailable)
 instead of silently dropping, as seems required by section 10.2.1. This
 seems preferable to silently dropping it to me."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/65>
xmpp <http://tools.ietf.org/xmpp/>

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 04:27:25 -0000

#65: handling of a message whose only child element is not understood by the
recipient
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Provisionally resolved by changing MUST to SHOULD.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/65#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Matthew Wild <[email-masked]>
Date: Fri, 25 Jun 2010 12:22:17 +0100

> #65: handling of a message whose only child element is not understood by the

Any reason for not saying "SHOULD return a 'service-unavailable' error"?

I'm open to persuasion, but it seems that if someone sends a message
somewhere, they expect it to do something, or go somewhere. If the
stanza isn't routed, and isn't handled (what's a server to do with a
message it doesn't understand?) then an error reply still seems
appropriate to me.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 16:05:12 -0600

> Any reason for not saying "SHOULD return a 'service-unavailable' error"?

Yes. If some unknown entity sends me a message whose only child element
is qualified by a namespace I don't understand, why am I obligated to
return an error? Messages are not IQs.

That said, if I am communicating with a known entity then returning an
error stanza with a condition of <feature-not-implemented/> makes the
most sense to me.

> somewhere, they expect it to do something, or go somewhere. 

I think it makes a difference if the sender is known to / trusted by the
recipient, vs. the case when the sender is unknown / untrusted.

> If the

IMHO it depends.

I propose the text embedded in this following excerpt (I've pasted the
entire thing for context):

###

   Support for any given extended namespace is OPTIONAL on the part of
   any implementation.  If an entity does not understand such a
   namespace, the entity's expected behavior depends on whether the
   entity is (1) the recipient or (2) a server that is routing or
   delivering the stanza to the recipient.

   If a recipient receives a stanza that contains an element or
   attribute it does not understand, it MUST NOT attempt to process that
   XML data and instead MUST proceed as follows.

   o  If an entity receives a message or presence stanza that contains
      XML data qualified by a namespace it does not understand, then it
      MUST ignore the portion of the stanza qualified by the unknown
      namespace.

   o  If an entity receives a message stanza whose only child element is
      qualified by a namespace it does not understand, then if the
      sender is known to or trusted by the recipient then the entity
      SHOULD return a message stanza of type "error" with an error
      condition of <feature-not-implemented/>; however, if the sender is
      unknown to or untrusted by the receipient then the entity SHOULD
      ignore the entire stanza.

   o  If an entity receives an IQ stanza of type "get" or "set"
      containing a child element qualified by a namespace it does not
      understand, then the entity MUST return an IQ stanza of type
      "error" with an error condition of <service-unavailable/>.

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

###

/psa

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 07:34:44 +0100

> error stanza with a condition of <feature-not-implemented/> makes the

I think you may be right.

> entire thing for context):

+1 to the text, thanks for figuring this out :)

Matthew

---

From: Kevin Smith <[email-masked]>
Date: Mon, 28 Jun 2010 07:49:44 +0100

> return an error? Messages are not IQs.

Right. You just shouldn't be sending message stanzas that the target
won't understand - that's why we've got disco and caps and etc. etc.
etc.

> error stanza with a condition of <feature-not-implemented/> makes the

It might, but it might not - what about sending a stanza just an the
entity goes offline, so it gets stored in offline storage, and an
error delivered a week later when the user logs in with a different
client?

>      ignore the entire stanza.

It's not clear to me what 'known' means - if the sender is in a
block-list, is that a known JID?

Although I'm not sold on the merit of this at all yet, I'd suggest
that if we keep this we change 'is known to or trusted by' to 'is
currently receiving presence from' to avoid ambiguity - at least in
the case of clients.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 07:49:37 -0600

> block-list, is that a known JID?

Yes, "know thy enemies" and all that.

> currently receiving presence from' to avoid ambiguity - at least in

It's not only presence -- I could have you in my roster or in an allow
list but perhaps you are not subscribed to my presence ("trusted" to
some degree) or I am not receiving presence from you.

I'd say just strike "known to" and "unknown to" and make it a matter of
trust (where the definition of "trusted" is outside the scope of this or
perhaps any specification).

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Mon, 28 Jun 2010 15:10:26 +0100

> perhaps any specification).

OK.
That just leaves the question of why it's useful in the first place :)

Perhaps simply
MAY either silently drop the message or return service-unavailable.

I'm not seeing any value in even SHOULDing service-unavailable here.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:29:09 -0600

> I'm not seeing any value in even SHOULDing service-unavailable here.

Because if we say "SHOULD drop or return service-unavailable" then it's
less likely that implementers will get creative about returning errors
we think would result in information leaks.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Mon, 28 Jun 2010 15:30:52 +0100

> we think would result in information leaks.

"MUST either silently drop the message or return service-unavailable"?

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:33:07 -0600

> That just leaves the question of why it's useful in the first place :)

I suppose one argue that this rule about the only child element being
unknown is handled by the foregoing rule about ignoring such XML data,
except in this case the unknown data is the only data, so ignoring that
data means ignoring the entire stanza. Matthew said that in some
circumstances it would be better to return an error in that case, but
I'm not particularly convinced by his argument. If we say "SHOULD ignore
the entire stanza" then that leaves wiggle room for returning an error,
but I see no good reason to return an error in that case.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:35:10 -0600

> "MUST either silently drop the message or return service-unavailable"?

That would be fine with me. It's a small point, but it would be nice to
get it close to right.

Matthew?

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Jun 2010 16:02:35 +0100

> but I see no good reason to return an error in that case.

Let me ask an alternate question. What should I do with:

<message from=[email-masked]' to=[email-masked]/foo'  
type='chat'/>

If there are sub-elements I ignore, and nothing left, then presumably  
this is what I end up with - so I'm assuming that the behaviour  
should be the same.

It's a genuine question, and my logic may be flawed - but I think the  
answer may have bearing on this.

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: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 10:34:55 -0600

On 6/28/10 9:02 AM, Dave Cridland wrote:
> this is what I end up with - so I'm assuming that the behaviour should
> be the same.
> 

I think "you sent me nothing" is different from "you sent me something
but I don't understand it". I'd say ignore the form. I still think that
<feature-not-implemented/> is the best error for the former, if you're
being polite to someone you trust -- but I'd be fine with ignoring it in
all cases, too, which is the rule in RFC 3921:

      *  If an entity receives a message stanza whose only child element
         is qualified by a namespace it does not understand, it MUST
         ignore the entire stanza.

/psa

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 18:20:39 +0100

> That would be fine with me. It's a small point, but it would be nice to

That would be fine to me too. I think whether a message warrants an
error bounce is best left up to the implementors, and no-one should
ever *rely* on getting an error reply to a message.

Normally I think it would be fine to ignore a message, but I noticed
we return an error for stanzas to the bare domain - partly because
there's nothing we really do with messages to the domain JID (except
forward them to the admin), unless it's part of a defined protocol.
Such a protocol would be incident reporting - where you would more
than likely want to know whether your report was received or you
should follow up via alternative channels.

If we were starting over I'd probably ensure we had a different 'type'
value for machine->machine message stanzas, which would help solve
much of this.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 11:59:40 -0600

> ever *rely* on getting an error reply to a message.

Agreed.

> should follow up via alternative channels.

True. "MUST either ignore the message or return a <service-unavailable/>
error" allows that flexibility. In the case of server-to-server
messaging, we don't have anyone's identity to protect so I'd still
prefer <feature-not-implemented/>, but I'm fine with
<service-unavailable/> as the default here. Or we could say:

  MUST either ignore the message or return a stanza error,
  which SHOULD be <service-unavailable/>.

> value for machine->machine message stanzas, which would help solve

Ah yes, the eternal dream of starting over. Rest assured that I have my
own list of things we'd change. :)

/psa

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 19:01:26 +0100

>  which SHOULD be <service-unavailable/>.

Ah yes, that's better still. +1.

Matthew

---

From: Kevin Smith <[email-masked]>
Date: Mon, 28 Jun 2010 19:02:15 +0100

>  which SHOULD be <service-unavailable/>.

That's fine by me.

/K