Re: [Stox] Review for stox-7248bis-02
Peter Saint-Andre <peter@andyet.net> Mon, 27 July 2015 13:42 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 C89EE1B2D39 for <stox@ietfa.amsl.com>; Mon, 27 Jul 2015 06:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 lUIi0ZsIc632 for <stox@ietfa.amsl.com>; Mon, 27 Jul 2015 06:42:00 -0700 (PDT)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (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 A65871B2D7F for <stox@ietf.org>; Mon, 27 Jul 2015 06:42:00 -0700 (PDT)
Received: by obbop1 with SMTP id op1so59486380obb.2 for <stox@ietf.org>; Mon, 27 Jul 2015 06:42:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BYD5i3L5KyJoSaN3vQzwnDlfp4C3PfjuQE7a9OANJa8=; b=C08mm7+LEjCgwtQNAO1WL1h30SEyg1jQ8nnhqAxOZHwiQD0LMpNFFjkS7pN+VHS072 K9HOQPIghuAtEwVrU7vCXnd5ac0IC3kQKiFg9Y/398ovRiqbxPbVYUCV6XBcb5NsWVMl 6SN2APBfLsLYvi3k43qO13PolSnItp/gv67UifDpRthtJPH97q9FIhSdl3o7JR6z2gyN UbPFzRW2R/4jLHcdSSskHgGP29+hWmlVItWQAKFoJ0Hb9MXjoqsXKk8agU4CMll/5f9F Yw0WAeHWIC82rA6DGo7njAxPikSMSihzYUmwerorP43HyHzdnq8KIKfRvlH0pX1KsB+J CBOw==
X-Gm-Message-State: ALoCoQlhw8jgyX2vgD2U8s3QYSH8sJwgoH0fGEACh9sQSdoZNvL/hm+78UhmcaJID+WWMU3Kwrke
X-Received: by 10.60.133.137 with SMTP id pc9mr27373382oeb.76.1438004520046; Mon, 27 Jul 2015 06:42:00 -0700 (PDT)
Received: from [10.81.215.170] (mobile-166-173-058-196.mycingular.net. [166.173.58.196]) by smtp.gmail.com with ESMTPSA id jp2sm10335295oeb.4.2015.07.27.06.41.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 06:41:58 -0700 (PDT)
References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <186194A5-0665-4AC9-8588-00C54A59975A@andyet.net>
X-Mailer: iPhone Mail (12H143)
From: Peter Saint-Andre <peter@andyet.net>
Date: Mon, 27 Jul 2015 07:41:50 -0600
To: Saúl Ibarra Corretgé <saul@ag-projects.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/XYp2BN0fJAx-6wa_RSwvJbEeTiw>
Cc: "stox@ietf.org" <stox@ietf.org>, Ben Campbell <ben@nostrum.com>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>, "Isomaki Markus (Nokia-TECH/Espoo)" <markus.isomaki@nokia.com>
Subject: Re: [Stox] Review for stox-7248bis-02
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: Mon, 27 Jul 2015 13:42:03 -0000
Thanks much! :) > On Jul 27, 2015, at 1:52 AM, Saúl Ibarra Corretgé <saul@ag-projects.com> wrote: > > Sorry folks, I’ve been AFK for the past few days. I’ll review this version and get the writeup done. > >> On 26 Jul 2015, at 23:22, Peter Saint-Andre - &yet <peter@andyet.net> wrote: >> >> I've posted -04 to address this feedback. >> >> Peter >> >>> On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote: >>> Hi Markus, thanks for the continued review. >>> >>>> On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: >>>> Hi Peter, >>>> >>>> I checked the revised draft (-03) and it addresses the issues I raised >>>> below. But that brought up another thing still. It's been really long >>>> since I've been dealing with SIP Presence, but I think that the >>>> message flows in 4.2.1 may still need a couple of clarifications: >>>> >>>> 1.) >>>> >>>> In SIP, if the subscription is not immediately authorized (neither >>>> accepted or rejected), it is possible that a 200 OK response to the >>>> SUBSCRIBE is sent immediately followed by a NOTIFY with subscription >>>> state "pending". If the SIP User later on positively authorizes the >>>> subscription, another NOTIFY with subscription state "active" is >>>> generated. The potential "pending" state does not seem to be covered >>>> in the current diagram, but it probably should be. The question is >>>> just what happens in XMPP-to-SIP GW if it gets a NOTIFY with "pending" >>>> subscription state. To my understanding the subscription state would >>>> remain "neutral" on the XMPP side. Would that mean that the >>>> XMPP-to-SIP GW would not send anything to the XMPP side in that case, >>>> i.e. only a NOTIFY indicating subscription state as "active" would >>>> cause the message (F10) to be triggered? In that case, maybe this kind >>>> of addition would be enough: >>>> >>>> OLD: >>>> >>>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >>>> the subscription state to be "neutral" until it receives a NOTIFY >>>> message. Therefore, the SIP user or SIP server at the SIP user's >>>> domain SHOULD immediately send a NOTIFY message containing a >>>> Subscription-State header [RFC6665] whose value contains the string >>>> "active" (see Section 5 below). >>>> >>>> NEW: >>>> >>>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >>>> the subscription state to be "neutral" until it receives a NOTIFY >>>> message. Therefore, the SIP user or SIP server at the SIP user's >>>> domain SHOULD immediately send a NOTIFY message containing a >>>> Subscription-State header [RFC6665] with value "active" (see >>>> Section 5 >>>> below). In case the XMPP-to-SIP gateway initially receives one or >>>> more >>>> NOTIFY messages with Subscription-State "pending", it MUST respond >>>> to them on the SIP side, but not generate any presence stanzas >>>> towards the >>>> XMPP User. >>> >>> That it better. The only further change I would make is: >>> >>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >>> the subscription state to be "neutral" until it receives a NOTIFY >>> message with a Subscription-State header [RFC6665] whose value is >>> "active". >>> >>> Also, I think it would make sense to change SHOULD to MUST here. >>> >>>> 2.) >>>> >>>> If you look at RFCs 3856 and 3857, the typical scenario in SIP >>>> presence is: There is a SIP Presence Server handling the subscriptions >>>> to the presence event package. That is where the SUBSCRIBE (F2) in >>>> 4.2.1 goes. But typically the Presence Server would not forward the >>>> SUBSCRIBE to the SIP User in way shown in (F3). Instead, the Presence >>>> Server and SIP User would interact via the 'presence.winfo' event >>>> package (RFC 3857), to which the SIP User would be subcribed. So, when >>>> the Presence Server gets a SUBSCRIBE to SIP User's Presence, it >>>> generates a 'presence.winfo' NOTIFY the SIP User, who will that way >>>> learn about the new subscription. The SIP User would then authorize >>>> the subscription by some interaction (for instance using XCAP) with >>>> the Presence Server. In this scenario, presence updates from the SIP >>>> User would also not be sent as NOTIFYs, but as PUBLISH messages to the >>>> Presence Server, who would then generate NOTIFYs to all active >>>> subscribers. >>>> >>>> It is however possible that the Presence Server acts in a Proxy mode, >>>> in which case (as far as I remember), it just passes the SUBSCRIBEs >>>> and NOTIFYs through as in the current diagram in 4.2.1. If we don't >>>> want to go into the more complex diagrams, it would suffice just to >>>> say (already in terminology or in 4.2.1): "In these examples it is >>>> assumed that the SIP Server acts as a proxy for Presence event package >>>> and the actual Presence Agent resides with the SIP User." >>> >>> Yes, the latter seems reasonable. However, also pointing to RFC 3857 >>> seems like a good idea. >>> >>> Peter >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox > > -- > Saúl Ibarra Corretgé > AG Projects > > >
- [Stox] Review for stox-7248bis-02 Isomaki Markus (Nokia-TECH/Espoo)
- Re: [Stox] Review for stox-7248bis-02 Peter Saint-Andre - &yet
- Re: [Stox] Review for stox-7248bis-02 Isomaki Markus (Nokia-TECH/Espoo)
- Re: [Stox] Review for stox-7248bis-02 Peter Saint-Andre - &yet
- Re: [Stox] Review for stox-7248bis-02 Peter Saint-Andre - &yet
- Re: [Stox] Review for stox-7248bis-02 Saúl Ibarra Corretgé
- Re: [Stox] Review for stox-7248bis-02 Peter Saint-Andre
- Re: [Stox] Review for stox-7248bis-02 Ben Campbell
- Re: [Stox] Review for stox-7248bis-02 Isomaki Markus (Nokia-TECH/Espoo)
- Re: [Stox] Review for stox-7248bis-02 Peter Saint-Andre - &yet