Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
Peter Saint-Andre <stpeter@stpeter.im> Tue, 13 September 2016 02:36 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19812B1A7 for <stox@ietfa.amsl.com>; Mon, 12 Sep 2016 19:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 LyZDUUWb79FS for <stox@ietfa.amsl.com>; Mon, 12 Sep 2016 19:36:56 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB312B0BF for <stox@ietf.org>; Mon, 12 Sep 2016 19:36:56 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0A4640352; Mon, 12 Sep 2016 20:37:40 -0600 (MDT)
To: Ben Campbell <ben@nostrum.com>, Saúl Ibarra Corretgé <saul@ag-projects.com>
References: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> <a139f13c-9745-0d86-853b-d5d6b8c9124c@stpeter.im> <E1C65C7E-CDFF-40BC-AF01-B2F029B64E6E@nostrum.com> <931fcd90-11c8-0b58-b3ad-eb6e7be2557e@stpeter.im> <f12534a1-bdce-925f-3358-c22975dd3bbe@stpeter.im> <512b8d52-68e1-2bdd-d153-20e24fbb73de@stpeter.im> <B197ACCC-5DB0-4C8F-8C54-1159A89B1796@nostrum.com> <969223de-c09e-eba5-a4a3-4969539c807e@stpeter.im> <87BE83BB-946B-4833-A34C-D890E783F214@nostrum.com> <76151e8b-9abf-7587-c36d-e2bf38180245@stpeter.im> <0C304BC3-0AD3-48C4-958B-AC44122892D7@nostrum.com> <5FA29740-BCD2-402D-BEB1-417A66CA7603@ag-projects.com> <81A30B28-EEDE-4BF2-8BA1-7CD148DF7ECE@ag-projects.com> <233A680F-224C-4799-B20E-E3962908E8DB@nostrum.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <e688a48d-cdf5-aa30-9593-b4b3d6e341f5@stpeter.im>
Date: Mon, 12 Sep 2016 20:36:55 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <233A680F-224C-4799-B20E-E3962908E8DB@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/fDxjvaGfpxN1GatW6aXoEtO63b8>
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Sep 2016 02:36:59 -0000
Thanks for the feedback. Comments inline. On 9/12/16 8:26 AM, Ben Campbell wrote: > Hi, > > A few comments inline. > > Thanks! > > Ben. > > On 12 Sep 2016, at 5:42, Saúl Ibarra Corretgé wrote: > > Review time! > Page 10: " As described in Section 6 > , the XMPP-to-SIP gateway also generates a > presence notification addressed to the XMPP user: > “ > Should we say “if the NOTIFY contains a body” or is it obvious > enough? It’s possible the SIP user is offline, but the XMPP is user > is already authorised, so the NOTIFY will contain > Subscription-State: active, but no body. > > It's probably worth adding an example of how the the gateway might > interpret an empty body. I assume that if this is the first NOTIFY in > the dialog (notification session), the gateway would interpret that as > unknown or possibly "closed". If previous NOTIFYs have in the same > notification session, it should probably mean "no change". Good idea, will do. > Page 11: "As can be seen, because SIMPLE does not > have a construct that enables a contact to cancel her presence > authorization,” > There is: remove the user from the corresponding XCAP rule. Next > time presence is requested, it will be denied. (the SUBSCRIBE dialog > still needs to be terminated though). > > The text is about the subscriber, not the presentity. So if Juliet > subscribes to Romeo's presence, Romeo can change the authorization rule > (via xcap or otherwise). But /Juliet/ cannot. > > I suppose "her authorization" can be a bit ambiguous. (If Romeo > authorizes Juliet, whose authorization is it?) I was tempted to add "outbound" or "inbound" in all cases to make this crystal clear... > Page 14: example 10 > Since the Content-Length is 0, maybe omit Content-Type? Good catch. > Page 15: flow example > Add a NOTIFY with state as “pending” before sending the subscribe > stanza to the XMPP server? > > That's a good question for the xmpp side. Is there an equivalent to the > pending state? There are indeed pending states in XMPP: https://tools.ietf.org/html/rfc6121#appendix-A.1 However, I excluded them in these mappings to avoid too much complexity. > It's not really illegal to go directly to active. It > might look unusual from the SIP side--but it's no different than > subscribing to something you are already authorized to see. We can make mention of them here but I'd prefer not to describe them in great detail. :-) > Page 19: [RFC6121] defines how XMPP > Missing RFC link? Not really, but the wording could be improved. > Page 27: " As described in [RFC3856 > ], this cancels any notification dialog but > causes a NOTIFY to be sent to the subscriber, just as a presence > probe does (the transformation rules for presence notifications have > been previously described in > Section 6.2 of this document).” > A probe would be implemented as a new SUBSCRIBE dialog with expires > 0, which does’t cancel all other dialogs. So while the mechanism is > the same, using a *new* SUBSCRIBE request with Expires: 0 would just > be a probe, not a cancellation. I will look into this. What you say sounds plausible but I'd like to double-check it against my reading of RFC 3856. > General note: the examples with "<show > xmlns='jabber:client'>away</show>” lack the XML namespace > declaration for “jabber”. Another good catch. > These are all quite minor things, I think we are good to go for WGLC > after small fixes for those. > Cheers! Great, I'll work on a slightly revised I-D this week. Thanks! Peter
- [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt internet-drafts
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé