Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt

"Ben Campbell" <ben@nostrum.com> Mon, 12 September 2016 14:43 UTC

Return-Path: <ben@nostrum.com>
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 0965312B73F for <stox@ietfa.amsl.com>; Mon, 12 Sep 2016 07:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level:
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508] 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 EArhW6Q84G5V for <stox@ietfa.amsl.com>; Mon, 12 Sep 2016 07:43:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6BAF112B2F8 for <stox@ietf.org>; Mon, 12 Sep 2016 07:26:40 -0700 (PDT)
Received: from [10.10.1.2] ([162.216.46.86]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8CEQX8Y057607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Sep 2016 09:26:34 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.86] claimed to be [10.10.1.2]
From: "Ben Campbell" <ben@nostrum.com>
To: "=?utf-8?q?Sa=C3=BAl?= Ibarra =?utf-8?q?Corretg=C3=A9?=" <saul@ag-projects.com>
Date: Mon, 12 Sep 2016 10:26:32 -0400
Message-ID: <233A680F-224C-4799-B20E-E3962908E8DB@nostrum.com>
In-Reply-To: <81A30B28-EEDE-4BF2-8BA1-7CD148DF7ECE@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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_CD30BDFE-B7F8-44D0-AFED-17469C37C0BB_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5260)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/agr8BIWRc7i3pXyCEYmTGvQi5II>
Cc: stox@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
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: Mon, 12 Sep 2016 14:43:43 -0000

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

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

>
> Page 14: example 10
>
> Since the Content-Length is 0, maybe omit Content-Type?
>
> 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? 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.

>
> Page 19: [RFC6121] defines how XMPP
>
> Missing RFC link?
>
> 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.
>
> General note: the examples with "<show 
> xmlns='jabber:client'>away</show>” lack the XML namespace 
> declaration for “jabber”.
>
> These are all quite minor things, I think we are good to go for WGLC 
> after small fixes for those.
>
> Cheers!
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>