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

Saúl Ibarra Corretgé <saul@ag-projects.com> Wed, 14 September 2016 16:27 UTC

Return-Path: <saul@ag-projects.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 DBB3F12B33A for <stox@ietfa.amsl.com>; Wed, 14 Sep 2016 09:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9EZH7SRhRw0d for <stox@ietfa.amsl.com>; Wed, 14 Sep 2016 09:27:56 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDFB12B34F for <stox@ietf.org>; Wed, 14 Sep 2016 09:27:54 -0700 (PDT)
Received: from [192.168.0.35] (unknown [90.209.144.173]) by mail.sipthor.net (Postfix) with ESMTPSA id 6AB1814AC039; Wed, 14 Sep 2016 18:27:51 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7F221E24-5BFE-4461-A87A-0DAB317B7647"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: =?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= <saul@ag-projects.com>
In-Reply-To: <6cd05347-ae22-28e2-fa05-297c49711d6d@stpeter.im>
Date: Wed, 14 Sep 2016 17:27:50 +0100
Message-Id: <B5010EFC-5A6D-4531-94F7-EC733B46B66C@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> <e688a48d-cdf5-aa30-9593-b4b3d6e341f5@stpeter.im> <5bc83063-11ad-aa70-723a-2bc9127685d8@stpeter.im> <6cd05347-ae22-28e2-fa05-297c49711d6d@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/lsW2D-Bi1lqLm3TgDBeCi318itk>
Cc: Ben Campbell <ben@nostrum.com>, 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: Wed, 14 Sep 2016 16:27:59 -0000

> On 14 Sep 2016, at 16:25, Peter Saint-Andre <stpeter@stpeter.im>; wrote:
> 
> On 9/14/16 9:24 AM, Peter Saint-Andre wrote:
>> A few additional notes...
>> 
>> On 9/12/16 8:36 PM, Peter Saint-Andre wrote:
>>> 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.
>> 
>>   As described in Section 6, if this first NOTIFY in the notification
>>   session contains a body then the XMPP-to-SIP gateway also generates a
>>   presence notification addressed to the XMPP user (if the NOTIFY does
>>   not contain a body then the gateway would interpret it as unknown or
>>   "closed"):
>> 
>>>>    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...
>> 
>> Changed to "cancel her outbound presence authorization"
>> 
>> <snip/>
>> 
>>>>    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.
>> 
>> Yes, that looks right. I would change things as follows (note the new
>> Call-ID, too):
>> 
>>   A SIP-to-XMPP gateway would transform the presence probe into its SIP
>>   equivalent, which is a SUBSCRIBE request with an Expires header value
>>   of zero in a new dialog:
>> 
>>   Example 23: SIP Transformation of XMPP Presence Probe
>> 
>>   |  SUBSCRIBE sip:romeo@example.net SIP/2.0
>>   |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>>   |  From: <sip:juliet@example.com>;tag=j89d
>>   |  Call-ID: 2398B737-566F-4CBB-A21A-1F8EEF7AF423
>>   |  Event: presence
>>   |  Max-Forwards: 70
>>   |  CSeq: 1 SUBSCRIBE
>>   |  Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
>>   |  Accept: application/pidf+xml
>>   |  Expires: 0
>>   |  Content-Length: 0
>> 
>>   As described in [RFC3856], this 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).
>> 
>>>>    General note: the examples with "<show
>>>>    xmlns='jabber:client'>away</show>” lack the XML namespace
>>>>    declaration for “jabber”.
>>> 
>>> Another good catch.
>> 
>> Actually, 'jabber' is not a prefix here and the namespace name is indeed
>> "jabber:client" - this was defined in the very early days of XML
>> namespaces and we Jabberites didn't fully understand what a namespace
>> name was supposed to look like. :(
>> 
>> If that all looks good, I will publish a revised I-D soon.
> 
> A diff is here:
> 
> https://github.com/stpeter/sip-xmpp/commit/a3ded08cbf1cc527f3f648813b3ecc46d5039094#diff-7f5e67ec097d24a4490853a1770f411b
> 

LGTM.  No objections from me!

--
Saúl Ibarra Corretgé
AG Projects