Subject: Re: [Stox] Review on -presence

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 1 Aug 2013 09:42:43 +0200

> 
>> Also, the priority in PIDF is a
>> float between 0 and 1, is it the same for XMPP?
> 
> Hmm. We had text about that in RFC 3922, and I suggest we copy that to
> this draft (adjusting as necessary)...
> 
>   An XMPP presence stanza MAY contain a <priority/> child element whose
>   value is an integer between -128 and +127.  The value of this element
>   MAY be mapped to the 'priority' attribute of the <contact/> child of
>   the PIDF <tuple/> element.  If the value of the XMPP <priority/>
>   element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
>   range of allowable values for the PIDF 'priority' attribute is any
>   decimal number from zero to one inclusive, with a maximum of three
>   decimal places.  If an XMPP-CPIM gateway maps these values, it SHOULD
>   treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP
>   <priority>127</priority> as PIDF priority='1', mapping intermediate
>   values appropriately so that they are unique (e.g., XMPP priority 1
>   to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
>   so on up through mapping XMPP priority 126 to PIDF priority 0.992;
>   note that this is an example only, and that the exact mapping shall
>   be determined by the XMPP-CPIM gateway).
> 
> That's twice in one day I have looked at RFC 3922. ;-)
> 

Heh :-) I agree, that text would clarify this.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 03 Aug 2013 09:53:59 +0200

On 8/1/13 12:32 AM, Peter Saint-Andre wrote:
> On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote:
>> 
>> - Using ID-123kdklejd doesn't seem to work as a valid xs:ID, TID-1234
>> does work though, so we could use TID- as the prefix for tuple
>> identifiers in examples and such.
> 
> I will double-check that against the XML specification.

Hmm. Here is what I see in the XML schema datatype specification:

   The ·value space· of ID is the set of all strings that ·match· the
   NCName production in [Namespaces in XML].

Where the NCName production is defined as follows:

   NCName 	::= 	(Letter | '_') (NCNameChar)*

What software are you using for validation? I'm not seeing a constraint
that an xs:ID needs to begin with three letters.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 03 Aug 2013 10:48:00 +0200

On 8/1/13 12:32 AM, Peter Saint-Andre wrote:
>> Hi,
>> Here is my review of the -presence document:
>>
>> - Sec 3.3.2 suggests that if the subscription is maintained but we
>> have no presence state, a PIDF would be generated with a basic status
>> of closed, but what would be the tuple ID, if we don't know any
>> resource for this user anymore? 

Actually, in this scenario the gateway does know the status because the
XMPP user is still online -- it's just that the SIP user's subscription
to the XMPP user's status has expired.

>> We could also send an empty NOTIFY,
>> which would achieve the same goal.
> 
> The empty NOTIFY sounds more consistent with the spirit of SIP presence.

I've looked into this further. Here is what I find in RFC 3856 (Section
6.6.2):

   If the resource is not in a meaningful state, RFC 3265 [2] allows the
   body of the initial NOTIFY to be empty.  In the case of presence,
   that NOTIFY MAY contain a presence document.  This document would
   indicate whatever presence state the subscriber has been authorized
   to see; it is interpreted by the subscriber as the current presence
   state of the presentity.  For pending subscriptions, the state of the
   presentity SHOULD include some kind of textual note that indicates a
   pending status.

And in RFC 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.

Everything there is about an initial NOTIFY confirming a presence
subscription. However, Section 3.3.2 of the stox-presence spec discusses
what to do if the SIP user's subscription expires:

   It is the responsibility of the SIMPLE-XMPP gateway to properly
   handle the difference between short-lived SIP presence subscriptions
   and long-lived XMPP presence subscriptions.  The gateway has two
   options when the SIP user's subscription expires...

It seems to me that there's a false assumption here, because in general
doesn't the SIP user agent initiate a refresh to maintain the
subscription (as long as it's online)? So I think there are two cases here:

(1) SIP user agent is online and generates a refresh by re-subscribing.
In this case, the empty NOTIFY might make sense (although you could
argue that it's not truly an "initial NOTIFY").

(2) SIP user agent goes offline and the subscription truly expires. In
this case, the handling we currently describe seems generally correct to me.

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 7 Aug 2013 23:43:38 +0200

> that an xs:ID needs to begin with three letters.

I tested it with lxml, a Python wrapper for libxml2. I complained because 'ID-123' was too ambiguous for an xs:ID. Not sure if it's an implementation detail / issue though.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 7 Aug 2013 23:54:34 +0200

> subscription (as long as it's online)? So I think there are two cases here:

Yep, you would usually refresh the subscription.

> argue that it's not truly an "initial NOTIFY").

Yep, I think we could say that you MAY send an empty NOTIFY and compose and offline state tuple based on the previous state.

> this case, the handling we currently describe seems generally correct to me.

Yes.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Aug 2013 14:44:45 -0600

On 8/7/13 3:43 PM, Saúl Ibarra Corretgé wrote:
>>>> - Using ID-123kdklejd doesn't seem to work as a valid xs:ID,
>>>> TID-1234 does work though, so we could use TID- as the prefix
>>>> for tuple identifiers in examples and such.
>>> 
>> What software are you using for validation? I'm not seeing a
>> constraint that an xs:ID needs to begin with three letters.
>> 
> 
> I tested it with lxml, a Python wrapper for libxml2. I complained
> because 'ID-123' was too ambiguous for an xs:ID. Not sure if it's an
> implementation detail / issue though.

Sounds like it.

In RFC 6120, it's suggested to make the XMPP resourcepart a UUID.
Something like ID-2E855EFA-DA21-48F1-A6EB-18B5231893AC won't trigger
warnings about ambiguity. :-)

Would it help to change some of the examples?

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Aug 2013 14:58:31 -0600

On 8/7/13 3:54 PM, Saúl Ibarra Corretgé wrote:
>>>> - Sec 3.3.2 suggests that if the subscription is maintained but
>>>> we have no presence state, a PIDF would be generated with a
>>>> basic status of closed, but what would be the tuple ID, if we
>>>> don't know any resource for this user anymore?
>> 
>> Actually, in this scenario the gateway does know the status because
>> the XMPP user is still online -- it's just that the SIP user's
>> subscription to the XMPP user's status has expired.
>> 
>>>> We could also send an empty NOTIFY, which would achieve the
>>>> same goal.
>>> 
>> I've looked into this further. Here is what I find in RFC 3856
>> (Section 6.6.2):
>> 
>> If the resource is not in a meaningful state, RFC 3265 [2] allows
>> the body of the initial NOTIFY to be empty.  In the case of
>> presence, that NOTIFY MAY contain a presence document.  This
>> document would indicate whatever presence state the subscriber has
>> been authorized to see; it is interpreted by the subscriber as the
>> current presence state of the presentity.  For pending
>> subscriptions, the state of the presentity SHOULD include some kind
>> of textual note that indicates a pending status.
>> 
>> And in RFC 3265:
>> 
>> Upon successfully accepting or refreshing a subscription,
>> notifiers MUST send a NOTIFY message immediately to communicate the
>> current resource state to the subscriber.  This NOTIFY message is
>> sent on the same dialog as created by the SUBSCRIBE response.  If
>> the resource has no meaningful state at the time that the SUBSCRIBE
>> message is processed, this NOTIFY message MAY contain an empty or
>> neutral body.
>> 
>> subscription. However, Section 3.3.2 of the stox-presence spec
>> discusses what to do if the SIP user's subscription expires:
>> 
>> handle the difference between short-lived SIP presence
>> subscriptions and long-lived XMPP presence subscriptions.  The
>> gateway has two options when the SIP user's subscription
>> expires...
>> 
>> It seems to me that there's a false assumption here, because in
>> general doesn't the SIP user agent initiate a refresh to maintain
>> the subscription (as long as it's online)? So I think there are two
>> cases here:
>> 
> 

Agreed.

>> (1) SIP user agent is online and generates a refresh by
>> re-subscribing. In this case, the empty NOTIFY might make sense
>> (although you could argue that it's not truly an "initial
>> NOTIFY").
>> 
> 
> Yep, I think we could say that you MAY send an empty NOTIFY and
> compose and offline state tuple based on the previous state.

In draft-ietf-stox-presence-01 I added the following paragraph:

   For as long as a SIP user is online and interested in receiving
   presence notifications from the XMPP users, the user's SIP user agent
   is responsible for periodically refreshing the subscription by
   sending an updated SUBSCRIBE request with an appropriate value for
   the Expires header.

However, I did not add an example, so IMHO it would be good to do that
in -02.

>> (2) SIP user agent goes offline and the subscription truly expires.
>> In this case, the handling we currently describe seems generally
>> correct to me.
>> 
> 
> Yes.

Thanks for the validation. :-)

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 17:53:16 +0200

> argue that it's not truly an "initial NOTIFY").

An initial notify is the one directly in response to a SUBSCRIBE, even a 
re-SUBSCRIBE. So I don't think there should be any controversy.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Aug 2013 11:43:03 -0600

> re-SUBSCRIBE. So I don't think there should be any controversy.

Thanks for the verification.

So under this model, the SIP user agent would send a re-SUBSCRIBE and it
seems to me that the gateway then SHOULD (?) respond with a NOTIFY from
the SIP representation of the XMPP user/resource. There are two cases
for the NOTIFY:

1. If the XMPP user/resource is not in a "meaningful state" (cf. RFC
3856 and RFC 3265), the NOTIFY SHOULD (?) be empty.

2. If the XMPP user/resource is in a meaningful state, the NOTIFY SHOULD
(?) contain data about the user/resource.

Does that sound right?

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 19:47:12 +0200

> 3856 and RFC 3265), the NOTIFY SHOULD (?) be empty.

I think this is probably ok.

> (?) contain data about the user/resource.

Yeah.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Aug 2013 12:28:05 -0600

>> (?) contain data about the user/resource.

OK, good. Here is proposed text for Section 3.3.2:

   For as long as a SIP user is online and interested in receiving
   presence notifications from the XMPP users, the user's SIP user agent
   is responsible for periodically refreshing the subscription by
   sending an updated SUBSCRIBE request with an appropriate value for
   the Expires header.  In response, the SIMPLE-XMPP gateway SHOULD send
   a SIP NOTIFY to the user agent; if the gateway has meaningful
   information about the availability state of the XMPP user then the
   NOTIFY SHOULD communicate that information (e.g., by containing a
   PIDF body [RFC3863] with the relevant data), whereas if the gateway
   does not have meaningful information about the availability state of
   the XMPP user then the NOTIFY SHOULD be empty as allowed by
   [RFC3265].

That would come before the existing discussion of handling by the
SIMPLE-XMPP gateway.

Peter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 20:47:55 +0200

>     the Expires header.  In response, the SIMPLE-XMPP gateway SHOULD send

S/SHOULD/MUST/

I'm using RFC6665 as my reference, rather than 3265.
See section 4.2.1.2 - the NOTIFY is required.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Aug 2013 13:02:59 -0600

> See section 4.2.1.2 - the NOTIFY is required.

Duly noted!

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Aug 2013 10:17:14 +0200

> That would come before the existing discussion of handling by the

Sounds good, I guess you'll just change the SHOULDs to MUSTs as pointed out by Paul.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Aug 2013 14:04:35 -0600

> Sounds good, I guess you'll just change the SHOULDs to MUSTs as pointed out by Paul.

Yes, that will be in the next version.

Peter

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