Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

["Ben Campbell" <[e-mail]>]

Thanks for the quick response. More inline; I've removed sections that 
do not seem to need further discussion.

Ben.

On 23 Sep 2015, at 22:52, Peter Saint-Andre - &yet wrote:

> Hi Ben, thanks for the continued careful reviews. Comments inline.
>
> On 9/21/15 9:25 PM, Ben Campbell wrote:

[...]

>
>> -- section 4, 1st bullet:
>>
>> "Instead of forwarding a SUBSCRIBE message to the SIP user, the 
>> Presence
>> Server and SIP User Agent would interact via the ’presence.winfo’ 
>> event
>> package"
>>
>> This is only true if the presentity has not already setup policy to
>> allow the subscriber to subscribe. Typically, this happens on the
>> initial subscription, and future subscriptions may not require the
>> presence.winfo interaction.
>
> Right. How about:
>
> OLD
>    Instead of forwarding a SUBSCRIBE message
>    to the SIP user, the Presence Server and SIP User Agent would
>    interact via the 'presence.winfo' event package, to which the SIP
>    user would be subcribed.
>
> NEW
>    Instead of forwarding a SUBSCRIBE message
>    to the SIP user, the Presence Server would act on the basis of a
>    policy set by the SIP User Agent using the 'presence.winfo' event
>    package, to which the SIP user would be subcribed.
>

That works for me.

>> -- Example 2:
>> The "To" tag should not exist on the first request in a dialog. The 
>> tag
>> value is learned from the SIP Response (200 OK in this example). The 
>> UAC
>> does not know the tag value at the time of the initial SUBSCRIBE
>> request. (Note that this repeats in later examples)
>
> Correct.
>
> Does this also apply to the NOTIFY messages later in the spec?

The NOTIFY requests will always be part of an existing dialog, so those 
should have both from and to tags.

[...]

>
>> -- 5.2.3
>>
>> The flow and message details are missing the final SIP NOTIFY 
>> request.
>
> The use case here is that the XMPP user no longer wants to receive 
> presence information about the SIP user. Is the SIP NOTIFY tiggered 
> because there's an assumption that the subscription needs to be 
> bidirectional?

No, there is no assumption that subscriptions are bi-directional. But a 
NOTIFY request is needed to send the SIP subscription dialog. The 
SUBSCRIBE with expires=0 merely triggers that notify.

 From RFC 6665, section 4.4.1:

       A subscriber may send a SUBSCRIBE request with an "Expires" 
header
       field of 0 in order to trigger the sending of such a NOTIFY
       request; however, for the purposes of subscription and dialog
       lifetime, the subscription is not considered terminated until the
       NOTIFY transaction with a "Subscription-State" of "terminated"
       completes.

[...]

>
>> -- Table 1:
>> - I think this could use some more text around what happens if you 
>> have
>> multiple XMPP resources, or a SIP presentity sends multiple tuples. 
>> The
>> note discusses how to map the resource identifier to the tuple id, 
>> but
>> not much about what it means to have multiple of either.
>
> That could get messy. I'll need to think about it and propose text.
>

I agree on the messy. It's worth some discussion about whether it makes 
sense to model multiple tuples as if they represented multiple 
resources. My kneejerk response is that is the easiest approach, even if 
it might not always be strictly true. (In my mind, modeling resources as 
tuples seems to make more sense when going from xmpp to sip.)

>> - I don't think it's correct to try to map CSeq. That's an artifact 
>> of
>> the SIP state machine that seems
>> meaningless to the XMPP side. (Same for table 2)
>
> OK.

I meant to go on and say that if a gateway decided to map id to CSeq to 
save local session state (with some scheme that preserved the semantics 
for either side), that would be perfectly acceptable--but there's no 
need to standardize it.

>
>> -- 6.2, note 5:
>>
>> The NOTIFY with a subscription state of "terminated" tears down the 
>> SIP
>> subscription. Is that the intent? Why would the unavailability of the
>> contact end the SIP subscription?
>
> Hmm. I would have thought this falls out from the ephemeral nature of 
> subscriptions in SIP. What you write would suggest that it's OK for 
> the SIP user's subscription to last beyond the XMPP user's presence 
> session (for example because the XMPP user might start another 
> presence session during the life of the SIP user's subscription). I 
> suppose that would be fine.

I think of the SIP dialog as representing the subscriber's active 
interest. The subscriber does not necessarily stop caring just because 
the contact became unavailable--as you say, he might come back.

>
>> -- note 7:
>>
>> Do you expect a SIP Presence UA to do something useful with the 
>> <show/>
>> element ? Most will probably ignore it.
>
> Losing that information along the way would guarantee that a presence 
> UA can't do something useful with it; preserving the information seems 
> helpful.

Okay. It might be worth a note that the sender should not depend on the 
receiver to render it.

>
>> -- 9, 2nd paragraph:
>>
>> "an XMPP-to-SIP gateway ought to be associated only with a single 
>> domain
>> or trust realm"
>>
>> Is this intended to discourage multi-tenant gateways? Does the 
>> existence
>> of draft-ietf-xmpp-dna change that?
>
> No, because that's the same trust realm (i.e., a service under the 
> control of a single administrative entity even if that entity hosts 
> multiple tenants).
>
> This text is intended to discourage the gateway equivalent of open 
> relays that are shared across XMPP domains from different trust 
> realms.

Okay

[...]

>
>> -- Editorial Comments and nits:
>>
>> -- 5.2.2, 2nd paragraph:
>>
>> Technically, RFC 6665 doesn’t talk about “presence” 
>> subscriptions,
>> but it does give the rules for SIP-events subscriptions in general.
>> Should the citation be to 3856?
>
> Actually I think this paragraph should cite both:
>
> In accordance with Section 6.7 of [RFC3856], the XMPP-to-SIP gateway
> MUST consider the subscription state to be "neutral" until it
> receives a NOTIFY message with a Subscription-State header [RFC6665]
> whose value is "active".
>

WFM


>> -- 5.3.1:
>> The flow leaves out the SIP responses. That's okay if it's on 
>> purpose,
>> but it would be good to mention you are doing so. (especially since 
>> the
>> previous examples showed them.)
>
> I'm happy to add them.

That would solve my concern. A note that they are omitted on purpose 
would also solve my concern.

>
>> - 2nd paragraph after example 10: "Request-URI or To header"
>> Shouldn't this just be the Request-URI?
>
> Given that the SUBSCRIBE can't have a To header yet (see above), yes.

Hmm, it has a To header--just not a To header _tag_. (I don't think that 
effects this answer, but I hope we don't have a misunderstanding in the 
previous sections.)


>
>> -2nd paragraph after example 11:
>> This also needs a NOTIFY. You mention one in the following paragraph 
>> for
>> the declined case, but you need one in either case.
>
> Yes. The XMPP server will generate a presence notification in this 
> case, so that's the primary NOTIFY of interest here, I think.

I think it's still worth mentioning that it happens. And that brings up 
another question: A RFC 6665 notifier is required to send an "immediate" 
NOTIFY. Do you think the presence stanza will reliably arrive at the 
gateway in time to be considered "immediate"? If there's any likelihood 
of delay, the gateway may need to send a "pending" NOTIFY.

[...]

>
>> - 2nd bullet:
>> This description is confusing. You aren’t maintaining the SIP
>> subscription, just the xmpp subscription.
>
> "Treat the subscription as if it were long-lived" might be clearer.
>

WFM.

>> -- 2nd bullet, sub-item 2:
>>
>> Do I understand this to mean the XMPP gateway infers availability of 
>> the
>> SIP user from the SIP user’s subscription? That should come from a
>> reciprocal subscription. Just because a SIP user subscribes to 
>> someone
>> else's presence doesn't mean that user is available. Just because he
>> doesn't doesn't mean he is not.
>
> This flow describes what happens when the SIP user ends its presence 
> session. In that case, it seems to me that sending a presence stanza 
> of type "unavailable" to the XMPP user is appropriate (when the 
> gateway treats the subscription as if it were long-lived).

While it's probably not common in practice, it's perfectly okay 
according to the protocol for a SIP user to stop subscribing to a 
resource, while continuing to send updates to that resource on a 
reciprocal subscription. It might be reasonable to assume the user to be 
unavailable if you have no information to the contrary, but this advice 
seems to suggest overriding presence information sent explicitly by the 
SIP user with presence information inferred from the subscription.


>
>> Also, how does this violate the SIP semantic?
>
> There's a mismatch in the meaning of subscribe. Treating a SIP 
> subscription as if it were long-lived means the gateway follows the 
> XMPP subscription model, not the SIP subscription model. A gateway 
> implementer needs to choose which model to honor, and if it chooses 
> the XMPP model then it's not honoring the SIP model (and vice-versa).

I think this depends on the resolution to the previous comment, but I 
would say that if the protoocl behavior expectations of the SIP 
subscriber are met, the semantic has not been violated.


[...]


>> -- 7:
>>
>> This is about polling, right? It seems like polling and subscribing 
>> are
>> just two ways to request presence info.
>
> Yes, the good way and the bad way. :-)
>
> Perhaps it's not sensible to talk about polling for presence, but I 
> think we included this for the sake of completeness.

I guess my objection was to characterize "polling" as a "request" for 
presence information, as if subscribing was not also a way of 
"requesting" that. I don't object to mapping between probes and 
zero-duration subscriptions.