Subject: [xmpp] #63: handling of JIDs under jid-malformed error condition

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

#63: handling of JIDs under jid-malformed error condition
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 8.3.3.8 describes the jid-malformed stanza error as follows:

 > The sending entity has provided or communicated an XMPP address
 > (e.g., a value of the 'to' attribute) or aspect thereof (e.g., an
 > XMPP resourcepart) that does not adhere to the syntax defined in
 > [XMPP-ADDR]; the associated error type SHOULD be "modify".

 Waqas Hussain commented: "Is it really okay to send a stanza to an invalid
 JID (even if it's the jid-malformed error)?"

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 22:43:10 -0600

> #63: handling of JIDs under jid-malformed error condition

An error stanza is returned to the sender. Do you mean that the 'from'
address might be malformed? I agree that there's no way to return an
error stanza to a malformed JID, but by defining the jid-malformed error
condition we're not saying that an entity MUST return an error or MUST
return an error condition of jid-malformed.

Can you suggest text that would address your concern?

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Sun, 27 Jun 2010 22:18:45 -0000

#63: handling of JIDs under jid-malformed error condition
--------------------------------+-------------------------------------------
 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:

 Slightly clarified the definition, as follows:

    The sending entity has provided (e.g., during resource binding) or
    communicated (e.g., in the 'to' address of a stanza) an XMPP address
    or aspect thereof that does not adhere to the syntax defined in
    [XMPP-ADDR]; the associated error type SHOULD be "modify".

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

---

From: Waqas Hussain <[email-masked]>
Date: Tue, 29 Jun 2010 18:08:08 +0500

On Fri, Jun 25, 2010 at 9:43 AM, Peter Saint-Andre <[email-masked]> wrote:
>>  > The sending entity has provided or communicated an XMPP address
>>  > (e.g., a value of the 'to' attribute) or aspect thereof (e.g., an
>>  > XMPP resourcepart) that does not adhere to the syntax defined in
>>  > [XMPP-ADDR]; the associated error type SHOULD be "modify".
>>

Ah, okay.

> Can you suggest text that would address your concern?

Does the spec define behavior for invalid 'to' or 'from' attributes on
received stanzas? A quick search of the spec didn't find anything.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 08:07:51 -0600

> received stanzas? A quick search of the spec didn't find anything.

In RFC 3920 we never clearly defined which entities are responsible for
JID checking, and 3920bis still isn't clear about that (thanks for
reminding us!). I'll post a separate message about that.

Peter

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