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

Peter Saint-Andre <> Tue, 13 September 2016 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC19812B1A7 for <>; Mon, 12 Sep 2016 19:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.41
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LyZDUUWb79FS for <>; Mon, 12 Sep 2016 19:36:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C9BB312B0BF for <>; Mon, 12 Sep 2016 19:36:56 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id E0A4640352; Mon, 12 Sep 2016 20:37:40 -0600 (MDT)
To: Ben Campbell <>, Saúl Ibarra Corretgé <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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.