[Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

Peter Saint-Andre stpeter at stpeter.im
Sun Mar 4 16:02:07 UTC 2018


On 3/4/18 1:27 AM, Florian Schmaus wrote:
> On 04.03.2018 02:30, Peter Saint-Andre wrote:
>>> On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin <edhelas at movim.eu> wrote:
>>> Hi,
>>>
>>> Thanks for the answers. I'm fine for the 3071 limitation, so we can set it both for the Pubsub nodes id and Pubsub items it?
>>> If yes I'm ok to do a PR on the 0060 to specify that. I'm also wondering if there is a specific way of declaring such string
>>> limitations, are you aware of any other XEPs that specify such things?
>>
>> As mentioned, I think this belongs in XEP-0030 but I suppose it can be defined in XEP-0060.
> 
> Could you elaborate why you think that it belongs in xep30? Are xep30
> item node's related to xep60 nodes? How fit xep60 item IDs into this?

The concept of a node was originally defined in XEP-0030, and the usage
in XEP-0060 borrowed from XEP-0030. The former is more fundamental and
thus I think it would be good to specify this in XEP-0030 (so that
"node" means the same thing across all protocol extensions). Or we could
resurrect XEP-0271:

https://xmpp.org/extensions/xep-0271.html

> Related: I wonder if we should specify string preparation for xep60 node
> and item ID strings. Same goes for the strings used by xep30, e.g.
> <feature/>'s 'var' attribute value. Is any Unicode string a valid value
> for those? Or is this already specified somewhere and I just missed it?

If we want to specify this, I would recommend the UsernameCaseMapped
profile defined in RFC 8265.

However, there's a twist: if a node ID can be a full JID, then do we
want to apply the normal rules of RFC 7622 to all the JID parts, instead
of one uniform profile such as UsernameCaseMapped to the entire node ID?
For instance, the resourcepart of a JID is allowed to contain a much
wider range of Unicode characters than is allowed by the
UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
for the localpart).

Given that a node ID can be used for authorization decisions, I think
it's better to be conservative in what we accept (specifically, not
allow the wider range of characters in a resourcepart because
developers, and attackers, could get too "creative").

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180304/775b9f30/attachment.sig>


More information about the Standards mailing list