Subject: [xmpp] 3921bis section 3 (mostly tracking of presence subscriptions)

From: Philipp Hancke <[email-masked]>
Date: Wed, 21 Jul 2010 21:48:27 +0200

I think we agreed to include an id attribute in those requests for 
tracking purposes (see 
http://www.ietf.org/mail-archive/web/xmpp/current/msg00057.html ), which 
is also described in 3.1.1.
It is missing in the examples and if it is not in the examples...

2.5.2 should have id in the unsubscribe/unsubscribed examples.

3.1.2.:
- should a server add the id attribute if it is not present?
- who is responsible for error handling?

3.1.3:
- there is no way to IGNORE a subscription request since the server will 
resends it whenever the user logs in?
- if the server sends the unavailable ack it should copy the id attribute

3.1.4:
- id attribute in the examples?
Note: it is ok to send both the unavailable ack and the subscribed with 
the same id since the iq semantics don't apply

3.1.5: id attribute again

3.1.6: is the presence delivered if the check fails?

3.2.1 / 3.2.2 id attribute again

3.2.3: what if there is no interested resource?

3.3.1: id attribute
3.3.2: id attribute
3.3.3: id attribute (I think that is it)

4.5.4: the client might use the unavailable ack from 3.1.3 instead of 
ignoring it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 14:16:44 +0200

> 2.5.2 should have id in the unsubscribe/unsubscribed examples.

Sure, I'll add 'id' attributes to those examples, as well.

> - should a server add the id attribute if it is not present?

We don't say anything about that in 3920bis or 3921bis even for IQ
stanzas (where 'id' is required), so I'm not sure why we would do that here.

> - who is responsible for error handling?

Whoever discovers the error.

> resends it whenever the user logs in?

Accept or deny are your two options. At least, that's all we've had
since 1999.

> - if the server sends the unavailable ack it should copy the id attribute

Copy it from the subscribe? I don't think that's right. Remember, these
aren't *real* acks. If we were using IQs for subscriptions, we'd be able
to reliably use 'id' (plus, say, a payload in the IQ-result).

> - id attribute in the examples?

Fixed.

> the same id since the iq semantics don't apply

See above about not being completely comfortable with our use of 'id'.

> 3.1.5: id attribute again

Fixed.

> 3.1.6: is the presence delivered if the check fails?

I don't think there is any attack involved in delivering presence, so
IMHO a server would always deliver inbound presence notifications. It
seems that is not documented in the spec, however.

> 3.2.1 / 3.2.2 id attribute again

Fixed.

> 3.2.3: what if there is no interested resource?

Good question. Someone pinged me off-list recently about whether inbound
presence stanzas of type "subscribed", "unsubscribe", and "unsubscribed"
need to be cached for later delivery. We've never specified that
behavior, but some existing servers do that. It might make sense to add
a note about that.

> 3.3.3: id attribute (I think that is it)

Fixed.

> 4.5.4: the client might use the unavailable ack from 3.1.3 instead of

I think that the contact would be in the user's roster by then, so the
text in the first bullet point applies.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 28 Jul 2010 16:19:09 +0200

> stanzas (where 'id' is required), so I'm not sure why we would do that here.

To stop resending the subscribe (last paragraph of 3.1.2) when an ack is 
received. To track that, the server could use the id attribute.

> Whoever discovers the error.

humm... more specific: if the user's server returns an 
remote-server-not-found error (second example in 3.1.2), what is the 
subscription state? According to A.2.1 it was changed to None+pending 
out when the subscription request was sent. Is that changed by the 
server in any way when processing or delivering said error to the user?

That reminds me that I wanted to re-read the appendix :-/

> Accept or deny are your two options. At least, that's all we've had

Which explains why I never understood your preference for "polite 
blocking". Claiming that the subscribe never made it is much easier ;-)

> to reliably use 'id' (plus, say, a payload in the IQ-result).

See above, this can be used as an ack to stop resending the request. If 
the contacts server does not send that the users server will continue to 
resend the subscribe.

> seems that is not documented in the spec, however.

It might not do that if the user is using a "only communicate with 
people on my roster" policy.

> behavior, but some existing servers do that. It might make sense to add

+1.

> text in the first bullet point applies.

Indeed.

thanks!

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 17:09:08 +0200

> received. To track that, the server could use the id attribute.

Ah. That's not adding an 'id' to what the client generated, that's
including an 'id' in the server-generated re-send. That seems like a
good idea.

> server in any way when processing or delivering said error to the user?

Good question. Undefined. It would be good to specify that.

> That reminds me that I wanted to re-read the appendix :-/

That is an excellent idea. :)

> blocking". Claiming that the subscribe never made it is much easier ;-)

Adding a new feature for polite blocking is something the WG could
consider. Do feel free to start a thread about that.

> the contacts server does not send that the users server will continue to

I see, yes.

I'm not sure if it makes sense for the server to add an 'id' to the
client-generated subscribe, but it does make sense to include one in the
server-generated re-sends. So we'll need to add some text about that.

> people on my roster" policy.

That's XEP-0016, not rfc3921bis. :)

>> text in the first bullet point applies.

No, thank you! :)

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 29 Jul 2010 10:18:36 +0200

> including an 'id' in the server-generated re-send. That seems like a

Mh... I would like to avoid the re-send at all by tracking the response
(if any) to the first subscribe on the server, too.
That is probably possible even if the client does not include an 'id'
attribute. (?)

> That is an excellent idea. :)

Appendix A looks good. What about more references to it in section 3?

> consider. Do feel free to start a thread about that.

No, "polite blocking" is what is currently done.

> server-generated re-sends. So we'll need to add some text about that.

+1