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

Peter Saint-Andre - &yet <peter@andyet.net> Tue, 29 September 2015 02:39 UTC

Return-Path: <peter@andyet.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A61B2D77 for <stox@ietfa.amsl.com>; Mon, 28 Sep 2015 19:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqNKCukC1UFY for <stox@ietfa.amsl.com>; Mon, 28 Sep 2015 19:39:22 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017F11B2D74 for <stox@ietf.org>; Mon, 28 Sep 2015 19:39:22 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so70390553igb.0 for <stox@ietf.org>; Mon, 28 Sep 2015 19:39:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=M8v7cXKrQtsR8zduujT0pKcDwirPRVf0e572UCTkIuQ=; b=JY1AtZs/1s8k3GqJXM+M/1417iNrfrZM4d1cL8Fdi9kj6Lt6y5ggqp/zOaZj38jnYA zlbY6t1woAJMaFa1aH7HasI/BL00shnxMN5AVOwWmHTlRC4x1FQArhZy2+ZPjo9Oz429 ieU2lnWHf+oIR3AZkgXl4OiEqX67GJb9D7+5egHXRV1AlidXf+0VNIjspsN4IV7kUT2u kyeszENaAmG46ZoBonBM0VPdIbo9VYpKtk1OHafZBMtIax7CkeVdHsg3PfOnetC+mvw2 iNLAi8CGpyZ1KpVFwS7XGNZSQx0Es7I0UY3JR6FaC6KSUCm+KrqgHnFn24sAMwkHV77t fpmQ==
X-Gm-Message-State: ALoCoQk3obginr+pnOwb/+Dpi3F+St8uPHuD++R4LxJdulv9z5y9H7v/iRvVsZlFAmlUKTDMKTh+
X-Received: by 10.50.79.167 with SMTP id k7mr19998659igx.28.1443494361153; Mon, 28 Sep 2015 19:39:21 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id c97sm10045609ioj.41.2015.09.28.19.39.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 19:39:20 -0700 (PDT)
To: Ben Campbell <ben@nostrum.com>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <5609F9D5.2080306@andyet.net>
Date: Mon, 28 Sep 2015 20:39:17 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/V9tJJrtt_x9ODN0Dt0NnkM5d-kI>
Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org
Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 02:39:24 -0000

On 9/24/15 11:55 AM, Ben Campbell wrote:
> Thanks for the quick response. More inline; I've removed sections that
> do not seem to need further discussion.

Likewise.

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

[...]

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

Thanks for the clarification.

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

That's how I've been thinking about the matter, but I need to ponder it 
further.

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

I think your initial intuition was correct. In XMPP the 'id' attribute 
is not a sequence number, whereas in SIP the CSeq header values are, in 
request dialogs, strictly monotonically increasing. Thus I don't think 
the semantics align well enough to even suggest a mapping.

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

Correct.

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

Actually the XMPP sender (or the sender's client) doesn't necessarily 
know that the receiver is a SIP user. Therefore I'm not sure what we can 
say about the sender. At most perhaps we can add a sentence like this:

        However, there is no guarantee that the SIP receiver will render
        a standard XMPP <show/> value or custom extension.

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

See the other message I just sent in this thread.

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

Right, no tag. We're on the same page.

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

Not sure. I'll think about that some more.

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

Yes, such a difference is possible in XMPP, too, depending on the 
subscription state.

Let me see if I can formulate some text to address this scenario, and 
clean up the current text referenced above.

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

Maybe. :-)

It still seems to me that the gateway is enforcing one model or the 
other. Perhaps "violate" is a strong word in this context, though.

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

Ah, I see. I suppose we meant "one-time request" as opposed to the 
"standing request" that is a subscription.

Peter

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