Re: [Stox] WGLC for draft-ietf-stox-presence-05

Peter Saint-Andre <stpeter@stpeter.im> Thu, 17 October 2013 22:51 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 F1C4C11E81DE for <stox@ietfa.amsl.com>; Thu, 17 Oct 2013 15:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.631
X-Spam-Level:
X-Spam-Status: No, score=-101.631 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3QZzYJoM4PO for <stox@ietfa.amsl.com>; Thu, 17 Oct 2013 15:51:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 642A811E8213 for <stox@ietf.org>; Thu, 17 Oct 2013 15:51:18 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 19BCE4100F; Thu, 17 Oct 2013 16:57:37 -0600 (MDT)
Message-ID: <526069DF.6050309@stpeter.im>
Date: Thu, 17 Oct 2013 16:51:11 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>
References: <7228C79F-98B8-4AFE-BB7B-99ACAA269EA5@jitsi.org> <526059FD.7040201@goodadvice.pages.de>
In-Reply-To: <526059FD.7040201@goodadvice.pages.de>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] WGLC for draft-ietf-stox-presence-05
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 17 Oct 2013 22:51:25 -0000

On 10/17/13 3:43 PM, Philipp Hancke wrote:
>> Please review the document and bring any remaining issues, or issues
>> whose resolution is not satisfactory, to the attention of the Working
>> Group on this list before October 22. If after reviewing the document
>> you find it complete and do not have any comments, please send a note
>> to that effect as well.
> 
> LGTM, with the usual nits:
> 
> - 3.2.1 Establishing
>   should probably mention what is established (a presence subscription),
> same for the rest of the section headers, also in 3.3.

Yes. I think it would be good to modify the main section headings too,
as follows:

   3.  Subscriptions to Presence Information

   4.  Notifications of Presence Information

   5.  Requests for Presence Information

> - "Upon receiving the first NOTIFY with a subscription state of
> active..." -- I wanted to comment that the xmpp subscription state
> should be none+out, but it's no longer clear to me whether I am assuming
> too much intelligence in the gateway.

Agreed. I would hope the gateways don't need to be that smart.

> - after example 8, should the unsubscribed stana be sent when receiving
> an ack for that (which is not shown)? It doesn't matter much however.

Hmm, I don't know if it's necessary for the gateway to receive an ack
from the SIP users before sending the unsubscribed.

> - "or, if a subscription already exists in the XMPP user's roster,
> discard the subscribe request" -- I think 6121 says the server should
> send subscribed without bothering the user. Simplifies the following
> paragraph.

True. That's better...

   In accordance with [RFC6121], the XMPP user's server MUST deliver the
   presence subscription request to the XMPP user (or, if a subscription
   already exists in the XMPP user's roster, send a presence stanza of
   type 'subscribed').

> - "translating the NOTIFU" before example 20 is a typo obviously.

Indeed.

Thanks for the review!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/