Subject: [xmpp] 6122bis: resourcepart

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Mar 2012 09:45:29 -0700

Discussion about a possible PRECIS profile for nicknames spilled over
from the SIMPLE WG to the [email-masked] list the other day. One
issue that came up was possibly treating resourceparts in general as
"absolute identifiers" (see draft-iab-identifier-comparison) and thus as
subject merely to byte-for-byte comparison, not a full-blown PRECIS
profile. This might simplify matters quite a bit. However, we would then
define a PRECIS profile for nicknames, so that resourceparts as used in
multi-user chat (XEP-0045) could be handled more intelligently. This
approach makes quite a bit of sense to me, so I might collaborate with
our friends in the SIMPLE WG on a PRECIS profile for nicknames (the
decision about resourceparts is separate from that, but related).

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Mon, 05 Mar 2012 20:05:44 +0100

> decision about resourceparts is separate from that, but related).

Hello Peter,

could you elaborate a bit on the "not a full-blown PRECIS profile" part.
I'd certainly hope we would still specify valid/disallowed code points.

My rational for this is that clients currently tend to display
resources. As such assuming all bytes are created equal might severely
break some client's interface and create a security threat for terminal
based clients (control characters).

Regards,
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 16:09:09 -0700

> I'd certainly hope we would still specify valid/disallowed code points.

I think we can prohibit code points without defining a PRECIS profile
(which requires that we specify a Unicode normalization form etc.).
Whether we want to do that is another question.

> based clients (control characters).

Yes, control characters are always a bad idea here.

The fact that resourceparts are entered by some humans and displayed to
other humans makes me think we probably want to use a PRECIS profile.

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 07 Mar 2012 02:07:17 +0100

> Whether we want to do that is another question.
I was assuming "None" would be a valid choice for a normalization form.
But then again that might just be me trying to squeeze this into a
PRECIS profile.

> other humans makes me think we probably want to use a PRECIS profile.
Assuming you're implying we should specify some normalization, case
mapping, etc. I think I agree.
However, it might also be possible to get away without any of those and
just let specific extensions/users further restrict the resource, as
suggested for MUC nicknames.

Florian

---

From: Kevin Smith <[email-masked]>
Date: Wed, 7 Mar 2012 07:59:15 +0000

> other humans makes me think we probably want to use a PRECIS profile.

I think that (apart from specific instances like MUCs), treating
resources as a string of bytes seems sensible, with disallowed ranges.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 06:22:00 -0700

> I was assuming "None" would be a valid choice for a normalization form.

Not an option. :)

> suggested for MUC nicknames.

Yes, that's what Dave Cridland suggested. IMHO it makes sense, but we
need to think through the implications.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 7 Mar 2012 06:40:34 -0800

> resources as a string of bytes seems sensible, with disallowed ranges.

I think it might be wise to consider various odd cases that might be negatively impacted by the inability of an entity from re-creating a resource through user input that matches that previously provided by a client.

Given there are cases where it desirable for a user to establish a specific resource for a particular client, it somewhat follows that a user might want to setup a different client to use that same resource at some point in time.  For instance, when switching clients used on their desktop, they might want their new client to have the same (equivalent) resource name to their old client.   If there are inadequate rules in the preparation of user input to the resource for comparison, the user might not be able to create an equivalent resource name on their new client.

Now, we might decide this is not a big deal, and hence go with a very simple set of rules for the resource part.  But I think before we do so, we should think through it.

Off hand, I would think that comparing of resource parts should not be done octet-wise (in the UTF-8 encoding), but that we should minimally require Unicode normalization (on input to the wire or at time of comparison).

-- Kurt

---

From: Matthew Wild <[email-masked]>
Date: Wed, 7 Mar 2012 16:42:15 +0000

> Given there are cases where it desirable for a user to establish a specific resource for a particular client, it somewhat follows that a user might want to setup a different client to use that same…

I'm much less convinced nowadays that resources should be anywhere
near users than I used to be. I think a user entering a resource
string (of a contact) is rather rare. We did have a discussion about
this in the Prosody room the other day. The main use-case that came up
was a server admin dealing with connected users via their full JID
(whether communicating with them or disconnecting them, etc.).

Also note that servers are able to enforce their own policies about
resources. Interop mainly becomes a problem at the s2s level then,
where one server may be more relaxed than another about accepting
"unusual" resource strings.

> Off hand, I would think that comparing of resource parts should not be done octet-wise (in the UTF-8 encoding), but that we should minimally require Unicode normalization (on input to the wire or a…

That does seem sensible.

Regards,
Matthew