Subject: [xmpp] 3921bis: subscription pre-approvals

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Aug 2010 10:52:41 -0600

During an offlist discussion today, I realized that the concept of
subscription pre-approvals is underspecified. Currently the only text
about it is hidden away in a note within Appendix A.2.3 of 3921bis.
Sometime today or tomorrow I'll propose a paragraph or two for inclusion
as a new subsection of Section 3 ("Managing Presence Subscriptions") so
that server developers don't need to make so many guesses about how to
implement this feature. This text can then be reviewed during the second
WGLC.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Aug 2010 13:34:12 -0600

> implement this feature. This text can then be reviewed during the second

Here is proposed text. I've also added links to this section from a few
places in the specification (Section 3.1.3 on "Server Processing of
Inbound Subscription Request" and Appendix A.2.3).

###

3.4.  Pre-Approving a Subscription Request

   If a user has not received a subscription request from a contact, the
   user can "pre-approve" such a request so that it will be
   automatically approved by the user's server.

3.4.1.  Client Generation of Subscription Pre-Approval

   A client generates a subscription pre-approval by sending a presence
   stanza of type "subscribed" to the contact.

   UC: <presence id='pg81vx64'
                 to=[email-masked]'
                 type='subscribed'/>

3.4.2.  Server Processing of Subscription Pre-Approval

   Upon receiving the presence stanza of type "subscribed", the user's
   server MUST proceed as follows.

   1.  If the contact is already in the user's roster with a state of
       "Both", "From", or "From + Pending Out", the user's server MUST
       silently ignore the stanza.

   2.  If the contact is already in the user's roster with a state of
       "To + Pending In", "None + Pending In", or "None + Pending
       Out+In", the user's server MUST handle the stanza as a
       subscription approval by updating the existing roster item to a
       state of "Both", "From", or "From + Pending Out" (respectively),
       pushing the modified roster item to all of the user's interested
       resources, and routing the presence stanza of type "subscribed"
       to the contact.

   3.  If the contact is in the user's roster with a state of "To",
       "None", or "None + Pending Out", the user's server MUST note the
       subscription pre-approval by setting the 'ask' flag to a value of
       "subscribed" and then push the modified roster item to all of the
       user's interested resources.  However, the user's server MUST NOT
       route the presence stanza of type "subscribed" to the contact.

   4.  If the contact is not already in the user's roster, the user's
       server MUST create a roster item for the contact with a state of
       "None" and set the 'ask' flag to a value of "subscribed", then
       push the roster item to all of the user's interested resources.
       However, the user's server MUST NOT route the presence stanza of
       type "subscribed" to the contact.

   When the 'ask' flag is set to "subscribed", the user's server MUST
   NOT deliver a presence stanza of type "subscribe" from the contact to
   the user, but instead MUST automatically respond to such a stanza on
   behalf of the user by returning a presence stanza of type
   "subscribed" from the bare JID of the user to the bare JID of the
   contact.

      Implementation Note: Support for this functionality is OPTIONAL on
      the part of an XMPP presence server.

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Aug 2010 15:52:10 -0600

On 8/11/10 3:30 PM, tpatnoe wrote:
> Do we need a note/use case that sending a presence of type 'unsubscribed' is
> how a pre-authorization is removed?

Good catch.

> I would also note that it will result in a roster push of ask='subscribed'
> being removed too.

Right. I think we'll need to add some text about that to Section 3.2 or
to this new section. Let me figure out where that belongs...

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Aug 2010 16:51:30 -0600

> to this new section. Let me figure out where that belongs...

Hmm, this is messier than I had hoped...

1. Support for subscription pre-approvals complicates server processing
of outbound "unsubscribed" (Section 3.2, Appendix A.2.4), but that's not
too ugly, just a matter of writing more specific text to cover all of
the cases.

2. The really gnarly issue is that now the 'ask' attribute can have two
values: "subscribe" and "subscribed". What happens if the user has a
pending outbound subscription to the contact *and* the user has
pre-approved a subscription request from the contact? Do we follow the
HTML convention of a space-separated list, as shown below?

   US: <iq id='b89c5r7ib574'
           to=[email-masked]/foo'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item ask='subscribe subscribed'
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
                 jid=[email-masked]'
                 subscription='none'/>
         </query>
       </iq>

That's possible, but ask='subscribe subscribed' does not match the
datatype currently defined in the schema for the 'jabber:iq:roster'
namespace:

         <xs:attribute name='ask' use='optional'>
           <xs:simpleType>
             <xs:restriction base='xs:NCName'>
               <xs:enumeration value='subscribe'/>
               <xs:enumeration value='subscribed'/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

Furthermore, it seems that NCName is not a valid datatype for an
attribute in XML!

###

3.3.1 Attribute Types

XML attribute types are of three kinds: a string type, a set of
tokenized types, and enumerated types. The string type may take any
literal string as a value; the tokenized types are more constrained. The
validity constraints noted in the grammar are applied after the
attribute value has been normalized as described in 3.3.3
Attribute-Value Normalization.

[54]   	AttType	       ::=  StringType | TokenizedType | EnumeratedType
[55]   	StringType     ::=  'CDATA'
[56]   	TokenizedType  ::=  'ID' | 'IDREF' | 'IDREFS' | 'ENTITY' |
                            'ENTITIES' | 'NMTOKEN' | 'NMTOKENS'

###

And it appears that an EnumeratedType needs to use NMTOKEN (although
there are examples from W3 XML Schema of xs:nonNegativeInteger and
xs:token):

###

Validity constraint: Enumeration

Values of this type MUST match one of the Nmtoken tokens in the declaration.

###

We could define the datatype of the 'ask' attribute to be NMTOKENS
(similar to, say, the 'class' attribute in XHTML) and remove the
enumeration. That might be the least-worst solution to the specification
challenge here.

Well, it's either that or remove pre-approvals entirely. :)

/psa

---

From: tpatnoe <[email-masked]>
Date: Wed, 11 Aug 2010 15:30:14 -0600

-- Tory

On 8/11/10 1:34 PM, "Peter Saint-Andre" <[email-masked]> wrote:

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

---

From: "Peter Saint Andre" <[email-masked]>
Date: Thu, 12 Aug 2010 12:34:27 -0700

Yes, I have text about those matters in the spec now.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Peter Saint-Andre <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Aug 11 14:30:14 2010
Subject: Re: [xmpp] 3921bis: subscription pre-approvals

-- Tory

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Aug 2010 14:30:54 -0600

Weird, Tory's note showed up as a new message on my phone, which is why
I answered it twice. Sorry about the noise. :)

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Aug 2010 16:09:28 -0600

> too ugly, just a matter of writing more specific text to cover all of

Done in my working copy.

>            <item ask='subscribe subscribed'

I've made that change in my working copy.

> Well, it's either that or remove pre-approvals entirely. :)

That's still an option if folks raise concerns on this list.

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 13 Aug 2010 03:30:25 +0200

> I've made that change in my working copy.
Maybe I'm just overlooking something, but doesn't this break parsing
that current clients are doing? And if so is this enough of an edge
case/unimportant enough that we are willing to accept that?
I tend to say yes to both, but mostly hope I'm just wrong ;)

--
Florian Zeitz

---

From: Kevin Smith <[email-masked]>
Date: Fri, 13 Aug 2010 13:53:53 +0100

> I tend to say yes to both, but mostly hope I'm just wrong ;)

Ah, ok, so the point was raised here, thanks Florian for getting there
long before me :)

So, yes, this could be breaking the parsing of clients against 3921,
which I *think* means we need to bump up to XMPP-1.1 (or 2.0 or
whatever) for bis if we make the change in this way. I'm opposed to
increasing the version number at the moment.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Aug 2010 16:22:19 -0600

> increasing the version number at the moment.

By "parsing", do you folks mean "validation"?

In 3921, the only defined value was ask='subscribe', as we can see in
Appendix B.5:

If in 3921bis we define an additional value ask='subscribed', does that
break existing clients? If so, why? It seems to me that a client would
simply ignore a value of 'subscribed' if it did not understand that
value. I ask because we've had 'subscribed' in 3921bis since -00 on June
1, 2009 (in fact since draft-saintandre-rfc3921bis-04 on October 29, 2007):

So, now that we've discovered the possibility of needing to communicate
both values simultaneously, we need to change the datatype from NCName
to NMTOKENS and thus allow at least the following three values:

   ask='subscribe' (3921-safe)
   ask='subscribed' (in 3921bis since -00, see above)
   ask='subscribe subscribed' (new)

What apsect of XML parsing breaks now that didn't break in 3921bis-00?
Please choose:

1. Values not defined in 3921 ("subscribed" was OK, it seems, but
"subscribe subscribed" breaks things)

or:

2. Datatype checking (NCName => NMTOKENS)

If you say that #1 breaks parsing then we've had a problem for almost 3
years, but it went undetected. If you say that #2 breaks parsing then
you are essentially claiming that clients are doing datatype validation
and I'd be curious to hear which clients are doing that.

Furthermore, if we claim that a new value for an attribute breaks
backward-compatibility then we can either:

1. Rip out subscription pre-approvals

2. Add a stream feature that enables the server to indicate support

The second approach would be fine with me, and is consistent with how we
handled roster versioning. And just as with roster versioning, I
disagree that this would require a version change from XMPP 1.0 to XMPP
1.1, especially because the change is to an XMPP extension (iq:roster)
and not to core streaming semantics. If we'd had namespace versioning
since 1999 we might change from roster1 to roster2 at this point, but
that's water under the bridge. Handling this via stream features is the
best we can do, I think.

In any case this is not a hill for me to die on -- we added subscription
pre-approvals for feature-parity with other presence technologies (in
particular SIP) and I think it's nice-to-have, but it's not nearly as
important as roster versioning, which saves a lot of bandwidth in common
scenarios.

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 17 Aug 2010 12:05:24 +0200

> and I'd be curious to hear which clients are doing that.
I think we (at least me) are indeed claiming #1 breaks parsing. And yes
that has probably been a problem with "subscribed" since forever (My
personal excuse is that, as mentioned before, I have never read 3921).
I'd be surprised if datatype validation was happening too.

> important as roster versioning, which saves a lot of bandwidth in common
2nded. I think introducing a stream feature seems like a quite balanced
way to do this.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Aug 2010 15:15:08 -0600

> 2nded. I think introducing a stream feature seems like a quite balanced

That's the best I can think of. If no one has other suggestions, I'll
write some text for this approach and post it to the list in the next 24
hours or so. I think it will be quite similar to the text for roster
versioning.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Aug 2010 22:06:05 -0600

> hours or so. I think it will be quite similar to the text for roster

I propose the following.

###

   Support for subscription pre-approvals is OPTIONAL on the part of
   clients and servers.  If a server supports subscription pre-
   approvals, then it MUST advertise the following stream feature during
   stream negotiation.

   <sub xmlns='urn:xmpp:features:pre-approval'/>

   The subscription pre-approval stream feature is merely informative
   and therefore is never mandatory.

   If the server to which a client connects has advertised support for
   subscription pre-approvals, the client MAY generate a subscription
   pre-approval by sending a presence stanza of type "subscribed" to the
   contact.

   If the server does not advertise support for subscription pre-
   approvals, the client MUST NOT attempt to pre-approve subscription
   requests from potential or actual contacts.

###

/psa

---

From: tpatnoe <[email-masked]>
Date: Wed, 18 Aug 2010 09:16:15 -0600

>    requests from potential or actual contacts.

With this new stream feature, are we also planning on using the new ask
states?

-- Tory