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/
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- [Stox] AD Evaluation of draft-ietf-stox-7248bis-05 Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre - &yet
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre - &yet
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre - &yet
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre - &yet
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Saúl Ibarra Corretgé
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Ben Campbell
- Re: [Stox] AD Evaluation of draft-ietf-stox-7248b… Peter Saint-Andre