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

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Ben, thanks for the continued careful reviews. Comments inline.

On 9/21/15 9:25 PM, Ben Campbell wrote:
> Hi,
>
> This is my AD evaluation of draft-ietf-stox-7248bis-05
>
> Summary:
>
> This is not quite ready for IETF last call. There are a number of SIP
> errors in the examples, and I think we need some more text to discuss a
> potential privacy issue. There's some questionable use of 2119 keywords,
> and a few other comments.  Details follow.
>
> Thanks!
>
> Ben.
>
> -- Privacy:
>
> I'm concerned that a naive implementation of the gateway could allow an
> XMPP user to see presence information for a SIP user that they were not
> authorized to see. The issue is that SIP allows a presentity to send
> different presence information to different subscribers. For example, if
> [e-mail] and [e-mail] both subscribe to
> sip:[e-mail], what if Carol wants to tell Alice that she is
> available, but Bob that she is not? (This is allowed in SIP.)

This also exists in XMPP, where it is called "directed presence":

http://tools.ietf.org/html/rfc6121#section-4.6

However, in XMPP this is the exception, not the rule.

> Can we be
> sure the gateway won't take presence intended for Alice and also send it
> to Bob?
>
> I think this is an issue, since if I understand things correctly, an
> XMPP presentity typically sends one presence stanza to her server, and
> that server distributes it among her subscribers.

Yes, this is the usual broadcast model for presence in XMPP.

> I _think_ this can
> work as long as we make sure the gateway sends each presence stanza
> directly to the subscriber that was targeted by the SIP Notify, and
> never mixes them up. But I think we need some text to describe the issue
> and give guidance on how to do the Right Thing.

It can't hurt.

We actually need a bit of text in the XMPP-to-SIP direction, too. The 
behavior of the XMPP server is specified in RFC 6121, but perhaps it 
would help to mention here that the server adds a 'to' address on each 
presence stanza it generates when it broadcasts the undirected presence 
stanza to the XMPP user's subscribers. This 'to' address is used for 
routing and needs to be honored by the XMPP-to-SIP gateway. From the 
perspective of the gateway, all it knows is that it has a presence 
stanza that it needs to transform into a SIP NOTIFY, and that stanza 
includes a 'to' address - it can't just assume that it can send that 
stanza to any random SIP user (and in fact it doesn't have the 
information it would need to make such decisions, since it isn't privy 
to the XMPP user's roster, which includes the subscription states).

I'll work to formulate some proposed text and post it in this thread.

> -- 2119 Keywords.
>
> There's quite a number of 2119 keywords used to describe existing
> normative SIP and XMPP behavior. Those should be written in descriptive
> language, or very clearly attribute the authoritative source. (There are
> a few attributed keywords, but many are not.)

Agreed. I'll check those over and scrub the text.

> -- 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.

> "The SIP User Agent would then authorize the subscription through..,"
>
> Typically, the user agent persistently authorizes the _subscriber_.
> (Remembering that in SIP the subscription is ephemeral. )

It's hard to remember unless I put on my SIP glasses. ;-)

> -- 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?

> -- Example 3:
> The From and To values are swapped. Remember that a SIP _response_ uses
> the exact same From and To as in the request. (Except for adding the To
> tag in a response to a request that did not contain one.) (Note that
> this repeats in later examples.)

Will fix.

> -- Example 4:
>
> The Request-URI should match the Contact header field value from the
> SUBSCRIBE. (Technically, from the last message from the peer, but
> assuming you don't have them change contacts mid-stream, it's the same.)
> You also might want to consider whether the aforementioned contact
> values are useful examples. (Repeats in later examples)

Noted.

> -- 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?

> -- Example 8:
>
> The request-URI should match the peers Contact field value.

Ack.

> -- 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 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.

> -- 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.

> -- 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.

> -- 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.

> "... whenever an XMPP-to-SIP gateway seeks to refresh an XMPP user’s
> long-lived subscription to a SIP user’s presence, it MUST first send an
> XMPP <presence/> stanza of type "probe" ..."
>
> I would have liked to see that discussed in the relevant procedures
> section(s).

OK, I'll see if we can include it earlier in the document.

> -- 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".

> -- 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.

> - 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.

> -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.

> -- 5.3.2, 1st bullet:
> "will seem strange to the XMPPcontact"
>
> Does the contact's human typically get notified of this?

Only the first time. It would be strange in XMPP to continually receive 
unsubscribe events whenever an ephemeral SIP subscription happens to 
expire (and subscribe events whenever a subscription is renewed).

> - 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.

> -- 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).

> 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).

> -- 6.2:
> 7 and 8 seem mostly redundant—and there doesn’t seem to be a citation
> for 8 in the table.

That seems to be a copy-paste error.

> -- 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.

Peter

-- 
Peter Saint-Andre
https://andyet.com/