[Standards] rfc3921bis: subscribing to a full JID

[Peter Saint-Andre]

Should we allow subscriptions to a full JID instead of a bare JID?

For example:

<presence from='user (AT) server (DOT) tld'
to='contact (AT) domain (DOT) tld/resource'
type='subscribe'/>

I know people have said there are legitimate scenarios when you might
want to do that, but I've never found them compelling.

However, if we say that you MUST NOT subscribe to a full JID, then that
rule needs to be enforced somewhere. Here are the options:

1. Enforced by user's server. (See below.)

2. Enforced by contact's server.

In this case, the contact's server will return a presence error:

<presence from='contact (AT) domain (DOT) tld/resource'
to='user (AT) server (DOT) tld'
type='error'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>

(Or perhaps <jid-malformed/>?)

Because the error is sent to user (AT) server (DOT) tld (bare JID), would it be
handled by the user's server? I think so. Which means that...

Both (1) and (2) imply that the user's server needs to inform the client
that a problem occurred with the subscription request. But how? Would it
return a presence error to the user's client? Presence errors are rare
(perhaps even nonexistent) right now -- instead we use unsubscribe and
unsubscribed in rfc3921bis. So I don't know how existing clients will
handle presence errors.

I don't have a strong preference between enforcing this at the user's
server or the contact's server, although I lean toward user's server
(because the user's server is the one that would need to deal with all
the complexities of full-JID subscriptions -- but note that this has an
impact on the contact's server as well if the user's server starts to
send presence probes to full JIDs there, so I see no harm in enforcing
this in both places).

Peter

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

[Justin Karneges]

On Thursday 05 June 2008 2:39 pm, Peter Saint-Andre wrote:
> Should we allow subscriptions to a full JID instead of a bare JID?
>
> For example:
>
> <presence from='user (AT) server (DOT) tld'
> to='contact (AT) domain (DOT) tld/resource'
> type='subscribe'/>
>
> I know people have said there are legitimate scenarios when you might
> want to do that, but I've never found them compelling.

Historically this has always been allowed, and in fact there are some
situations where it has been required. For example, transports that
use "/registered" for subscriptions would depend on this, and they may even
still be deployed.

Like my other mail, "MUST NOT" is too strong then. We could go with "SHOULD
NOT" if we want to attempt to deprecate the feature.

I agree that in general this ability is mostly confusing as heck. It's kind
of an interesting geek feature, but it shouldn't be required by anyone to get
anything done.

-Justin

[anders conbere]

On Thu, Jun 5, 2008 at 2:39 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> Should we allow subscriptions to a full JID instead of a bare JID?
>
> For example:
>
> <presence from='user (AT) server (DOT) tld'
> to='contact (AT) domain (DOT) tld/resource'
> type='subscribe'/>

This would only be interesting to me if we had contextual rosters
based on resources

~ Anders

>
> I know people have said there are legitimate scenarios when you might
> want to do that, but I've never found them compelling.
>
> However, if we say that you MUST NOT subscribe to a full JID, then that
> rule needs to be enforced somewhere. Here are the options:
>
> 1. Enforced by user's server. (See below.)
>
> 2. Enforced by contact's server.
>
> In this case, the contact's server will return a presence error:
>
> <presence from='contact (AT) domain (DOT) tld/resource'
> to='user (AT) server (DOT) tld'
> type='error'>
> <error type='modify'>
> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> </error>
> </presence>
>
> (Or perhaps <jid-malformed/>?)
>
> Because the error is sent to user (AT) server (DOT) tld (bare JID), would it be
> handled by the user's server? I think so. Which means that...
>
> Both (1) and (2) imply that the user's server needs to inform the client
> that a problem occurred with the subscription request. But how? Would it
> return a presence error to the user's client? Presence errors are rare
> (perhaps even nonexistent) right now -- instead we use unsubscribe and
> unsubscribed in rfc3921bis. So I don't know how existing clients will
> handle presence errors.
>
> I don't have a strong preference between enforcing this at the user's
> server or the contact's server, although I lean toward user's server
> (because the user's server is the one that would need to deal with all
> the complexities of full-JID subscriptions -- but note that this has an
> impact on the contact's server as well if the user's server starts to
> send presence probes to full JIDs there, so I see no harm in enforcing
> this in both places).
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

[Peter Saint-Andre]

On 06/05/2008 6:06 PM, anders conbere wrote:
> On Thu, Jun 5, 2008 at 2:39 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>> Should we allow subscriptions to a full JID instead of a bare JID?
>>
>> For example:
>>
>> <presence from='user (AT) server (DOT) tld'
>> to='contact (AT) domain (DOT) tld/resource'
>> type='subscribe'/>
>
> This would only be interesting to me if we had contextual rosters
> based on resources

What are those?

[Peter Saint-Andre]

On 06/05/2008 4:08 PM, Justin Karneges wrote:
> On Thursday 05 June 2008 2:39 pm, Peter Saint-Andre wrote:
>> Should we allow subscriptions to a full JID instead of a bare JID?
>>
>> For example:
>>
>> <presence from='user (AT) server (DOT) tld'
>> to='contact (AT) domain (DOT) tld/resource'
>> type='subscribe'/>
>>
>> I know people have said there are legitimate scenarios when you might
>> want to do that, but I've never found them compelling.
>
> Historically this has always been allowed, and in fact there are some
> situations where it has been required. For example, transports that
> use "/registered" for subscriptions would depend on this, and they may even
> still be deployed.
>
> Like my other mail, "MUST NOT" is too strong then. We could go with "SHOULD
> NOT" if we want to attempt to deprecate the feature.

I think so too. I think it's probably enough to actively discourage this
in clients.

> I agree that in general this ability is mostly confusing as heck. It's kind
> of an interesting geek feature, but it shouldn't be required by anyone to get
> anything done.

Agreed.

Peter

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

[anders conbere]

On Thu, Jun 5, 2008 at 9:11 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> On 06/05/2008 6:06 PM, anders conbere wrote:
>> On Thu, Jun 5, 2008 at 2:39 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>>> Should we allow subscriptions to a full JID instead of a bare JID?
>>>
>>> For example:
>>>
>>> <presence from='user (AT) server (DOT) tld'
>>> to='contact (AT) domain (DOT) tld/resource'
>>> type='subscribe'/>
>>
>> This would only be interesting to me if we had contextual rosters
>> based on resources

I think you'll probably see talk about some of these kinds of ideas at
the summit. But there are a couple of problems that seem eminent with
the way people are talking about using xmpp. First is authorization to
get access to data, and a sentiment that there isn't enough being done
with resources to be used to define contexts both in terms of
privacy/authorization, but in terms of data shielding.

Second, when discussing the use of xmpp rosters as generic data
carries for relationships, there are issues involving the way that
people use social networks as different social contexts. (I'm friends
with these people in the context of flickr, but those people in the
context of facebook, and I want those two contexts to be distinct).
You can accomplish some basic data partitioning with groups that
allows to to think about how this could be accomplished. But I'm a big
fan of this idea that I should be able to authorize flickr to have
access to the data in aconbere (AT) conbere (DOT) org/flickr and that when I do
that flickr should be granted access to a roster of it's own, that
exists at that resource.

I think some of these ideas are being tackled by people doing PEP, and
talking about just getting around the limitations of rosters and
partitioned data by creating PubSub nodes on users that you can
individually authorize access to :)

~ Anders

>
> What are those?
>
>
>

[Tomasz Sterna]

Dnia 2008-06-05, czw o godzinie 15:39 -0600, Peter Saint-Andre pisze:
> Should we allow subscriptions to a full JID instead of a bare JID?

We should disallow full JID based subscriptions. This introduces many
inconsistencies and doubts in presence handling.


> I know people have said there are legitimate scenarios when you might
> want to do that, but I've never found them compelling.

There are legitimate scenarios to have full JIDs on roster, though. I.e.
'server.tld/echo' on default user roster, to hint user how to test the
connection (like Skype's echo service).
But even though, presence MUST be handled by bare JID of this roster
item.


--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
.._.(_.)_ im:smoku (AT) xiaoka (DOT) com

[Peter Saint-Andre]

On 06/08/2008 2:30 AM, Tomasz Sterna wrote:
> Dnia 2008-06-05, czw o godzinie 15:39 -0600, Peter Saint-Andre pisze:
>> Should we allow subscriptions to a full JID instead of a bare JID?
>
> We should disallow full JID based subscriptions. This introduces many
> inconsistencies and doubts in presence handling.
>
>
>> I know people have said there are legitimate scenarios when you might
>> want to do that, but I've never found them compelling.
>
> There are legitimate scenarios to have full JIDs on roster, though. I.e.
> 'server.tld/echo' on default user roster, to hint user how to test the
> connection (like Skype's echo service).

Yes I think that makes sense.

> But even though, presence MUST be handled by bare JID of this roster
> item.

So, if a user's client sends a subscription request to a full JID,
should the user's server ignore the resource and send the request to
<contact (AT) domain (DOT) tld> instead of <contact (AT) domain (DOT) tld/resource>? And if
the contact's server receives a subscription request for a full JID,
should it also ignore the resource? I have some text to that effect in
my working copy now (but I think it is MAY, not SHOULD or MUST).

Peter

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

[Tomasz Sterna]

Dnia 2008-06-09, pon o godzinie 08:57 -0600, Peter Saint-Andre pisze:
> > But even though, presence MUST be handled by bare JID of this roster
> > item.
>
> So, if a user's client sends a subscription request to a full JID,
> should the user's server ignore the resource and send the request to
> <contact (AT) domain (DOT) tld> instead of <contact (AT) domain (DOT) tld/resource>? And if
> the contact's server receives a subscription request for a full JID,
> should it also ignore the resource?

Exactly.


> I have some text to that effect in
> my working copy now (but I think it is MAY, not SHOULD or MUST).

I think it should be SHOULD. :-)


--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
.._.(_.)_ im:smoku (AT) xiaoka (DOT) com

[Peter Saint-Andre]

On 06/10/2008 2:56 PM, Tomasz Sterna wrote:
> Dnia 2008-06-09, pon o godzinie 08:57 -0600, Peter Saint-Andre pisze:
>>> But even though, presence MUST be handled by bare JID of this roster
>>> item.
>> So, if a user's client sends a subscription request to a full JID,
>> should the user's server ignore the resource and send the request to
>> <contact (AT) domain (DOT) tld> instead of <contact (AT) domain (DOT) tld/resource>? And if
>> the contact's server receives a subscription request for a full JID,
>> should it also ignore the resource?
>
> Exactly.
>
>
>> I have some text to that effect in
>> my working copy now (but I think it is MAY, not SHOULD or MUST).
>
> I think it should be SHOULD. :-)

It's SHOULD here:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-05.html#sub-request-outbound

And here:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-05.html#sub-request-inbound

It's possible that the version at ietf.org doesn't say that, because I
messed up my submission. It'll be correct in version -06.

Peter

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