Re: [Stox] Review for stox-7248bis-02
Peter Saint-Andre - &yet <peter@andyet.net> Sun, 26 July 2015 21:23 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 73D1D1A02F1 for <stox@ietfa.amsl.com>; Sun, 26 Jul 2015 14:23:03 -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=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 XnYvc5SLgs2e for <stox@ietfa.amsl.com>; Sun, 26 Jul 2015 14:23:01 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 A8E341A0211 for <stox@ietf.org>; Sun, 26 Jul 2015 14:23:01 -0700 (PDT)
Received: by igk11 with SMTP id 11so38985815igk.1 for <stox@ietf.org>; Sun, 26 Jul 2015 14:23:01 -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:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=X14wD8abQJm11A/WeZss/c9RdjPVs69As3ADoPJxjR0=; b=Aja876hpbtkPWODgXjnP+MRQ6V5Iq8eEhqv3FR2RZtVU3P5r+aMutzzvPyLrqr6SCD 56ZT2Mr4riiF8ZlKy+9qtis7+PF3Jrwkspa7OvoYpbbzPo/rL3i8p4msSJh9PcmxNDGX gWYxksVY1gcsn2lWUHKzv+ThDwFsyw4csHA9NBPos951SWm7pW+hwfsf9YzTbQNKuJVp EgEaY0KKbv56dv2A6vJ80OC5kIfaQ2fzssFpP6b4dy61Xjua7XArgZJ9cOkmlQdubA2d gVjQQLywBTb4HNhdEvJ+JHGFdxO6isRhQ9g1ow8qH+43L4wMwRZ8DvhxoLOqO+2khJYk y1gA==
X-Gm-Message-State: ALoCoQksdUeo5F/4pyiuaZDZWWMRUzAzZ3VqLxXXFwjH/U53lYy0KOQe2QYA6sm7vn+Xl2jjmFoB
X-Received: by 10.50.136.134 with SMTP id qa6mr12423686igb.26.1437945781150; Sun, 26 Jul 2015 14:23:01 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:656a:8ad7:bf39:2c55]) by smtp.googlemail.com with ESMTPSA id j20sm4529550igt.16.2015.07.26.14.22.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 14:22:59 -0700 (PDT)
To: "Isomaki Markus (Nokia-TECH/Espoo)" <markus.isomaki@nokia.com>, "stox@ietf.org" <stox@ietf.org>, Ben Campbell <ben@nostrum.com>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com> <55B083ED.3090801@andyet.net>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <55B54FB1.8090009@andyet.net>
Date: Sun, 26 Jul 2015 15:22:57 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55B083ED.3090801@andyet.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/59Bo9_KJYr9YyFRvXtEbGIjrC6w>
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: Sun, 26 Jul 2015 21:23:03 -0000
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] 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