Subject: [xmpp] #68: handling of message to full JID when no resource matches

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

#68: handling of message to full JID when no resource matches
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 10.2.3.3 (Full JID) states:

 > If the JID contained in the 'to' attribute is of the form
 > <localpart@domain/resource> and there is no connected resource
 > that exactly matches the full JID, the stanza is processed as
 > if the JID were of the form <localpart@domain>.

 Philipp Hancke commented: "Regarding handling of stanzas to full JIDs when
 that resource is offline: For message stanzas, this would usually mean
 that they are stored in offline storage. But in that case I expect them to
 be stored with the full JID and only to be delivered a connecting client
 that requests the resource "resource". This might be a problem if the
 resource identifier is not a constant string. Is the message ever get
 delivered? Similar argument for iq stanzas, and MUC messages/presence
 (which 3921bis says should be bounced)."

 Matthew Wild replied: "this ties in closely with 3921's rules. Perhaps
 3920 is specifying too much here?"

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 20:37:34 -0600

On 6/21/10 8:15 PM, xmpp issue tracker wrote:
>  that requests the resource "resource". 

That is not the traditional behavior, but your server implementation is
free to do that.

>  This might be a problem if the
>  resource identifier is not a constant string. 

Which they typically are not. Certainly such strings are not reserved (I
could have multiple clients binding the resource "foo" over time).

> Is the message ever get
>  delivered? 

Not under your interpretation, which is why I think it is misguided.

> Similar argument for iq stanzas, and MUC messages/presence

We haven't started discussing 3921bis yet. All in good time. :)

>  3920 is specifying too much here?"

The routing and delivery "rules" provided in 3920bis are meant to be
very general guidelines, which are supplemented or even superseded by
rules from specifications that define particular XMPP applications.
Given that most of the 3920bis rules are SHOULD-level guidelines, I
don't see harm in leaving the text as-is.

BTW I have changed "is processed" in the quoted text to "SHOULD be
processed", making it clear that this behavior is recommended but can be
overridden by particular XMPP application types (such as IM/presence
applications as described in 3921bis). See also the note at the very
beginning of Section 10 in 3920bis:

      Implementation Note: Particular XMPP applications MAY specify
      delivery rules that modify or supplement the following rules; for
      example, a set of delivery rules for instant messaging and
      presence applications is defined in [XMPP-IM].

/psa

---

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 28 Jun 2010 02:38:02 -0000

#68: handling of message to full JID when no resource matches
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  wontfix           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

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

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