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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 07 September 2016 20:45 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 48C1F12B2EC for <stox@ietfa.amsl.com>; Wed, 7 Sep 2016 13:45:13 -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 vilsmHU6cr5z for <stox@ietfa.amsl.com>; Wed, 7 Sep 2016 13:45:12 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 40DA712B213 for <stox@ietf.org>; Wed, 7 Sep 2016 13:45:12 -0700 (PDT)
Received: from aither.local (unknown [98.245.40.52]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 303E2416BD; Wed, 7 Sep 2016 14:45:35 -0600 (MDT)
To: Ben Campbell <ben@nostrum.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>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <969223de-c09e-eba5-a4a3-4969539c807e@stpeter.im>
Date: Wed, 7 Sep 2016 14:45:11 -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: <B197ACCC-5DB0-4C8F-8C54-1159A89B1796@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/F57MMqRyVl-vh2T1VwQ7RGD6gu0>
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: Wed, 07 Sep 2016 20:45:13 -0000

On 9/7/16 2:39 PM, Ben Campbell wrote:
> Hi Peter,
>
> I think version 10 is very close to ready. I have two minor comments;
> for the most part these don't change the interaction. I've actually
> suggested text this time :-)
>
> -4, list item 1:
>
> OLD:
>   Instead of forwarding a SUBSCRIBE message to the SIP user, the
> Presence Server
>   would act on the basis of a policy set by the SIP User Agent using the ’
>   presence.winfo’ event package, for which the SIP user would receive
> events.
> NEW:
>   Instead of forwarding a SUBSCRIBE message to the SIP user, the
> Presence Server
>   would inform the user of subscription activity using the ’presence.winfo’
>   event package.
>
> -5.1, paragraph after bullet list:
> OLD:
>    As described in [RFC3856], SIP presence authorizations are
>    effectively implicit: when a SIP user receives an initial SIP
>    SUBSCRIBE event from a contact, the recipient’s SIP User Agent will
>    prompt the user to approve or deny the request.
> NEW:
>    As described in [RFC3856], in SIP the subscriber does not explicitly
>    request the creation or removal of presence authorizations. Rather,
>    the authorizations are triggered by subscription activity. When a
>    SIP user receives an initial SIP SUBSCRIBE event from a contact,
>    the recipient’s SIP User Agent or presence server notifies the
>    user to make an authorization policy decision.

Definite improvements. Would you like me to submit a revised I-D? Easy 
enough. :-)

Peter