Subject: [xmpp] 6122bis: enforcing the rules

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Mar 2012 14:49:36 -0600

One of the failings of RFC 3920, and of RFC 6122 too, is that we
didn't clearly specify which entities are responsible for enforcing
the i18n rules...

1. Are clients responsible for preparing JIDs and JID parts before
injecting them into the system?

2. Are servers responsible for verifying the correctness of any JID in
any JID-slot (or only to/from addresses plus certain other slots)?

2a. Only over client-to-server connections?

2b. Also over server-to-server connections?

Note that there are many places where JIDs can be injected (to/from
addresses, roster items, vCard entries, privacy lists, etc. -- see
http://tools.ietf.org/id/draft-saintandre-xmpp-i18n-03.txt for a
semi-complete listing).

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 20 Mar 2012 13:44:03 -0600

Hat: individual

On 3/19/12 2:49 PM, "Peter Saint-Andre" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Particularly if we move to NFD, this SHOULD happen, since servers can check
for NFD-validity without decomposing/recomposing if the client puts the JID
in NFD first.

> 2b. Also over server-to-server connections?

I'd be ok with MUST at all identified JID-slots.

-- 
Joe Hildebrand

---

From: Matthew Wild <[email-masked]>
Date: Tue, 20 Mar 2012 20:46:34 +0000

> injecting them into the system?

Currently - no. Simple clients, etc.

I'm not against changing this if we can still keep it simple for
clients (such as having available a standard library like libidn
supporting everything, most clients need this already for IDNA).

However if the server has to check validity anyway, I don't see much
harm in the current situation where it can simply inform the client
when a JID is wrong. I don't see validity checks in servers going away
- whatever those checks may be.

> any JID-slot (or only to/from addresses plus certain other slots)?

I'd say any within the core XMPP specs at least (and any XEPs that
deem it necessary). Most slots match to/from addresses at some point.

> 2b. Also over server-to-server connections?

I think the above two are pretty tied - the question is whether we
want to allow for site-specific policies, thereby skipping checks on
stanzas from clients destined for remote servers. I would suggest not
cater for this (we currently don't).

Regards,
Matthew

---

From: [email-masked]
Date: Tue, 20 Mar 2012 21:05:43 +0000 (GMT)

I'm wondering what is actually required for interoperability, here.

The minimum, it seems to me, is actually pretty low, but requiring that jids sent to clients be normalized seems a reasonable addition - it means a simple client could avoid knowing about normalization at all.

The minimum is that any jid comparisons MUST occur on normalized jids. I can't think of anything else.

Sent from my android device.

-----Original Message-----
From: Matthew Wild <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: XMPP <[email-masked]>
Sent: Tue, 20 Mar 2012 8:46 PM
Subject: Re: [xmpp] 6122bis: enforcing the rules

Regards,
Matthew
_______________________________________________
xmpp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2012 15:54:38 -0600

On 3/20/12 1:44 PM, Joe Hildebrand wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> didn't clearly specify which entities are responsible for
>> enforcing the i18n rules...
>> 
>> 1. Are clients responsible for preparing JIDs and JID parts
>> before injecting them into the system?
> 
> Particularly if we move to NFD, this SHOULD happen, since servers
> can check for NFD-validity without decomposing/recomposing if the
> client puts the JID in NFD first.
> 
> 
>> 2. Are servers responsible for verifying the correctness of any
>> JID in any JID-slot (or only to/from addresses plus certain other
>> slots)?
>> 

Just so we're all aware, there are a lot of JID-slots. :) Here is the
old text I had in draft-saintandre-xmpp-i18n...

###

7.  XMPP Protocol Slots

   IDNA2008 defined the concept of a "domain name slot", i.e., "a
   protocol element or a function argument or a return value (and so on)
   explicitly designated for carrying a domain name" (Section 2.3.2.6 of
   [RFC5890]).  Similarly, the XMPP community can define the concepts of
   a "JID slot", a "localpart slot", and a "resourcepart slot" (and
   might re-use the concepts of a "nameything slot", "wordything slot",
   and "stringything slot" from PRECIS specifications).  The community
   has yet to determine the full inventory of such slots.  However, the
   following subsections provide a start at such an inventory.

7.1.  JID Slot

   In XMPP systems, JabberIDs can appear in at least the following
   slots:

   o  Core [RFC6120]: the 'from' and 'to' stream attributes; the 'from'
      and 'to' stanza attributes.
   o  IM [RFC6121]: the 'jid' attribute of the roster <item/> element.
   o  Privacy Lists [RFC3921], [XEP-0016]: the 'value' attribute of the
      <item/> element when the value of the 'type' attribute is "jid".
   o  Data Forms [XEP-0004]: the <value/> element when the 'type'
      attribute is "jid-single" or "jid-multi".
   o  Flexible Offline Message Retrieval [XEP-0013]: the 'jid' attribute
      of the <x/> element.
   o  Service Discovery [XEP-0030]: the 'jid' attribute of the <item/>
      element.
   o  Extended Stanza Addressing [XEP-0033]: the 'jid' attribute of the
      <address/> element.
   o  Multi-User Chat [XEP-0045]: the 'actor' child of the <item/>
      element; the 'jid' attribute of the <item/> element; the 'from'
      and 'to' attributes of the <invite/> and <decline/> elements; the
      'jid' attribute of the <destroy/> element.
   o  Bookmarks [XEP-0048]: the 'jid' attribute of the <conference/>
      element.
   o  vCards [XEP-0054]: the <JABBERID/> of the <vCard/> element.
   o  Jabber Search [XEP-0055]: the 'jid' attribute of the <item/>
      element.
   o  Publish-Subscribe [XEP-0060]: the 'jid' attribute of the
      <affiliation/>, <options/>, <subscribe>, <subscription/>, and
      <unsubscribe/> elements; the 'publisher' attribute of the <item/>
      element.
   o  SOCKS5 Bytestreams [XEP-0065]: the 'jid' attribute of the
      <streamhost/> and <streamhost-used/> elements.
   o  Advanced Message Processing [XEP-0079]: the 'from' and 'to'
      attributes of the <amp/> element.
   o  Jabber Component Protocol [XEP-0114]: the 'from' and 'to'
      attributes of the <iq/>, <message/>, and <presence/> elements.
   o  Message Archiving [XEP-0136]: the 'with' attribute of the <chat/>,
      <from/>, and <item/> elements.
   o  Roster Item Exchange [XEP-0144]: the 'jid' attribute of the
      <item/> element.
   o  Jingle [XEP-0166]: the 'initiator' and 'responder' attributes of
      the <jingle/> element.
   o  Delayed Delivery [XEP-0203]: the 'from' attribute of the <delay/>
      element.
   o  Simple Communications Blocking [XEP-0191]: the 'jid' attribute of
      the <item/> element.
   o  Server Dialback [RFC3921], [XEP-0220]: the 'from' and 'to'
      attributes of the <result/> and <verify/> elements.
   o  Direct MUC Invitations [XEP-0249]: the 'jid' attribute of the <x/>
      element.

7.2.  Localpart Slot

   In XMPP systems, localparts can appear in at least the following
   slots:

   o  Multi-User Chat [XEP-0045]: the <unique/> element.
   o  In-Band Registration [XEP-0077]: the <username/> element.

7.3.  Resourcepart Slot

   In XMPP systems, resourceparts can appear in at least the following
   slots:

   o  Core [RFC6120]: the <resource/> child of the <bind/> element.
   o  Multi-User Chat [XEP-0045]: the 'nick' attribute of the <item/>
      element.
   o  Bookmarks [XEP-0048]: the 'nick' attribute of the <conference/>
      element.
   o  Jabber Search [XEP-0055]: the 'nick' attribute of the <item/> and
      <query/> elements.
   o  Publish-Subscribe [XEP-0060]: the 'node' attribute of the
      <address/> element (this might actually be a "stringything slot"
      but typically it is handled as a resourcepart).

###

Some of those are things that only clients will use (say, the
'initiator' and 'responder' attributes in Jingle). So even if the
server checks every JID-slot (and localpart-slot and
resourcepart-slot), the user experience could suffer if clients don't
enforce the rules.

Just a thought. :)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2012 16:05:35 -0600

On 3/20/12 2:46 PM, Matthew Wild wrote:
> However if the server has to check validity anyway, I don't see
> much harm in the current situation where it can simply inform the
> client when a JID is wrong. I don't see validity checks in servers
> going away - whatever those checks may be.

True. Do take note of all the JID-slots we've got -- servers might be
checking to/from and roster items and perhaps a few others, but not
the full range of JID-slots. So documenting that seems useful.

> want to allow for site-specific policies, thereby skipping checks
> on stanzas from clients destined for remote servers. I would
> suggest not cater for this (we currently don't).

Seems sensible.

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 20 Mar 2012 16:09:42 -0600

> resourcepart-slot), the user experience could suffer if clients don't

I'd also be ok with another approach, which is the server MUST convert to
canonical form if and only if it has to deal with the protocol (i.e.
rosters), but MAY pass through unmodified JID slots in protocols that it
otherwise wouldn't have to understand (such as Jingle initiator/responder).

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2012 16:11:04 -0600

On 3/20/12 4:09 PM, Joe Hildebrand wrote:
>> 'initiator' and 'responder' attributes in Jingle). So even if
>> the server checks every JID-slot (and localpart-slot and 
>> resourcepart-slot), the user experience could suffer if clients
>> don't enforce the rules.
> 
> I'd also be ok with another approach, which is the server MUST
> convert to canonical form if and only if it has to deal with the
> protocol (i.e. rosters), but MAY pass through unmodified JID slots
> in protocols that it otherwise wouldn't have to understand (such as
> Jingle initiator/responder).

Yes, I wouldn't want to say that servers would need to clean up JIDs
that are deep in Jingle stanzas or whatever! So that makes sense. Then
we need to make sure that server implementers are clear on the JID
slots that they need to care about.

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 20 Mar 2012 16:19:05 -0600

> slots that they need to care about.

Yes.  And provide language for future RFC or XEP editors to say what flavor
each new slot is.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Mar 2012 16:19:47 -0600

On 3/20/12 4:19 PM, Joe Hildebrand wrote:
>> Yes, I wouldn't want to say that servers would need to clean up
>> JIDs that are deep in Jingle stanzas or whatever! So that makes
>> sense. Then we need to make sure that server implementers are
>> clear on the JID slots that they need to care about.
> 
> Yes.  And provide language for future RFC or XEP editors to say
> what flavor each new slot is.

Exactly.

---

From: Matthew Wild <[email-masked]>
Date: Tue, 20 Mar 2012 23:18:30 +0000

>> what flavor each new slot is.

I like this approach.

Regards,
Matthew