From nobody Sun Jul 5 18:59:12 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0E1B2A0A; Sun, 5 Jul 2015 18:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ydWQlWvEpCmj; Sun, 5 Jul 2015 18:59:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4282F1A92E9; Sun, 5 Jul 2015 18:59:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706015903.17179.95296.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 18:59:03 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-media-06.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 01:59:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions Authors : Peter Saint-Andre Saul Ibarra Emil Ivov Filename : draft-ietf-stox-media-06.txt Pages : 29 Date : 2015-07-05 Abstract: This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of media signaling messages between systems that implement the Session Initiation Protocol (SIP) and systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-media/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stox-media-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 19:01:34 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7141A92BB for ; Sun, 5 Jul 2015 19:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pL9p7ccBN6M8 for ; Sun, 5 Jul 2015 19:01:32 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (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 1571B1A92BA for ; Sun, 5 Jul 2015 19:01:31 -0700 (PDT) Received: by igau2 with SMTP id u2so954333iga.0 for ; Sun, 05 Jul 2015 19:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=PCyG2dP5BrbBLeI6MEMz7/M4rUGHvlzk4sH3kWacFzo=; b=IeG5/w6X7yL9cw7qSahpSHekhiG9GvEmsWNuYMNT/7LI9//F6Y7scEa5bNsBDU3g21 2FdiLr19bBXBRzp2HjezMh/Hwredkj8j4pP3ccsmA0n3HuC1ttwuQuGT9ul1zFloZiaq ipZeCJC+ALDAK8G9GMR+Ap1IQEqjfemrdTa+96h6x5suNOiFWMWoUKQGqN45lgf7QZCF Dit3Ro37eqZdtd0UtDRCUfFGkSizWoHqjofep7K4kVS+2S54c3LYvv9vqy2O4Bmm7P59 83GvYE8mghaT5/cotPsvCj6du0UjdVNFGzqQQIzkutX8PDavu7YH201ssehBauPwFTiH Q61g== X-Gm-Message-State: ALoCoQnksZevnmlhGjUtjwrpg5oyYwO2DRuEAheBJYyu0WfZ5RwhHhpYlf+v8ereXJzyWyPwBnCv X-Received: by 10.50.17.104 with SMTP id n8mr64502281igd.21.1436148091412; Sun, 05 Jul 2015 19:01:31 -0700 (PDT) Received: from ?IPv6:2601:282:4201:ef5b:14db:5064:c0b2:c562? ([2601:282:4201:ef5b:14db:5064:c0b2:c562]) by mx.google.com with ESMTPSA id x4sm11595488iod.26.2015.07.05.19.01.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jul 2015 19:01:30 -0700 (PDT) References: <20150706015903.17179.95296.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (12F70) In-Reply-To: <20150706015903.17179.95296.idtracker@ietfa.amsl.com> Message-Id: <1B8BA819-EB32-47E6-9FBA-B449A9744EBC@andyet.net> Date: Sun, 5 Jul 2015 20:01:28 -0600 To: stox@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-06.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 06 Jul 2015 02:01:33 -0000 Some fixes to address open issues. Hopefully this version or the next will b= e ready for WGLC.=20 Peter Sent from mobile, might be terse=20 > On Jul 5, 2015, at 7:59 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. >=20 > Title : Interworking between the Session Initiation Proto= col (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media S= essions > Authors : Peter Saint-Andre > Saul Ibarra > Emil Ivov > Filename : draft-ietf-stox-media-06.txt > Pages : 29 > Date : 2015-07-05 >=20 > Abstract: > This document defines a bidirectional protocol mapping for use by > gateways that enable the exchange of media signaling messages between > systems that implement the Session Initiation Protocol (SIP) and > systems that implement the Jingle extensions to the Extensible > Messaging and Presence Protocol (XMPP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-media/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stox-media-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-media-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From nobody Thu Jul 16 07:18:48 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8911B3C73 for ; Thu, 16 Jul 2015 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yg55uW-72vxU for ; Thu, 16 Jul 2015 07:18:45 -0700 (PDT) Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E2F1B3C67 for ; Thu, 16 Jul 2015 07:18:44 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 16 Jul 2015 17:18:42 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 16 Jul 2015 17:18:41 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Thu, 16 Jul 2015 17:18:41 +0300 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: "stox@ietf.org" Thread-Topic: Review for stox-7248bis-02 Thread-Index: AdC/0cUiLOk2SX8aQIy0VVTyZI/MLQ== Date: Thu, 16 Jul 2015 14:18:40 +0000 Message-ID: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.50.32.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 16 Jul 2015 14:18:47 -0000 Hi Peter, all, I did a review for the 7248bis-02 draft and unless I'm missing something, t= here seem to be still a few confusing things about the message flow diagra= ms and the terminology about SIP-to-XMPP and XMPP-to-SIP gateways. (The rea= son to go for 7248bis was indeed to fix the message flows so they are reall= y the main part of it.) A minor issue: - In the diagrams abbreviations S2X GW and X2S GW are used. While most read= ers can guess what they mean, it would be good to open them explicitly, per= haps in Section 3, Terminology.=20 Bigger issues: - The diagram in Section 4.2.1: It looks weird that the SIP server already = generates the (F7) 200 OK message, while the (F8) NOTIFY does not get any r= esponse. Shouldn't it be that the 200 OK is generated by the "X2S GW" and t= hen passed forward by the SIP server?=20 - The text in 4.2.1 is somewhat confusing as well, as it first (understanda= bly) talks about XMPP-to-SIP GW as shown in the diagram ("S2X"), but then (= after Example 2) talks a few times about SIP-to-XMPP GW as well. I believe = this is coming from 7248, which does have the two GWs as explicit entities = in the diagram. But in 7248bis they are merged, and the current text makes = the reader wonder if SIP-to-XMPP GW refers to the same entity as XMPP-to-SI= P GW as shown, or whether there is another implicit/invisible GW function i= ncluded.=20 - The same issue occurs in 4.3.1 in reverse. There, the diagram only has "S= 2X GW" but the text contains both SIP-to-XMPP and XMPP-to-SIP.=20 So we have gotten rid of the double gateways of 7248 in the diagrams, but t= hey still somehow loom in the text and terminology. I think there are a cou= ple of options to clarify this: Either always refer to the gateway as XMPP-= to-SIP (X2S) in those sections that are about XMPP-to-SIP, and vice versa. = Or, make the gateway direction neutral and just call it something like SIP-= XMPP GW everywhere. Or, explain some more about the directions. Sorry to be late about this, but I guess this is the last chance and we sho= uld definitely get the gateways right this time :-O Markus From nobody Mon Jul 20 08:44:17 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC97E1A8F34; Mon, 20 Jul 2015 08:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 w4c178q6MgV0; Mon, 20 Jul 2015 08:44:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 943541A8AF7; Mon, 20 Jul 2015 08:44:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720154410.3351.75069.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 08:44:10 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-media-07.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 15:44:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions Authors : Peter Saint-Andre Saul Ibarra Emil Ivov Filename : draft-ietf-stox-media-07.txt Pages : 28 Date : 2015-07-20 Abstract: This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of media signaling messages between systems that implement the Session Initiation Protocol (SIP) and systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-media/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stox-media-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 20 08:45:41 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE871A8F34 for ; Mon, 20 Jul 2015 08:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 F2cbfmz5Cbs7 for ; Mon, 20 Jul 2015 08:45:38 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (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 679F41A8BC2 for ; Mon, 20 Jul 2015 08:45:38 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so120306535ieb.1 for ; Mon, 20 Jul 2015 08:45:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pR1IIJuRvp1mmK04yTp6rQLguO3pDqNVz4VE8j9kKxQ=; b=eL8XgupzNnvucUbHdCz62w67U5jwoT6ZDGTiPTQNsjNJOxj9Gc73NWGs3aw10OWvuL ZmMFIvxsAd38Rvgj1B5gQ7XZZne5h3sJuwUJj/VhUBXSVjFLMlOQmyVD4c9vAASO2p16 QZK9CKmu0c7ZVyCa33N93qtW/4IRN6xwPtBKupRLKmtAfdKD97rGnBDVy36Uz0TyyuL2 k1uVYQ026W02BYGc8CJghXpdXXL87X2lCc/ZeWtkUEqgRmA+mDmpUHcoIh2NCetvfctA fmkvbPkEOortUwGeCsh81ASjXMm862TFo7nH6zDrtUVbYGIbIvLsfd1yuBFTinq3j66k II6w== X-Gm-Message-State: ALoCoQlnHrpioWnfeKOs7RMPPoeF0qrQDfYwpI1uLNKrPcil4Te5CRE0UwHpAJHwBfnuRGh/pCAr X-Received: by 10.50.225.65 with SMTP id ri1mr15996063igc.47.1437407137809; Mon, 20 Jul 2015 08:45:37 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:f92d:45d0:a729:b1a0]) by smtp.googlemail.com with ESMTPSA id p79sm3310206iop.15.2015.07.20.08.45.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 08:45:36 -0700 (PDT) Message-ID: <55AD179E.5090504@andyet.net> Date: Mon, 20 Jul 2015 09:45:34 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: stox@ietf.org References: <20150720154410.3351.75069.idtracker@ietfa.amsl.com> In-Reply-To: <20150720154410.3351.75069.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-07.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 20 Jul 2015 15:45:40 -0000 A few further fixes to achieve agreement among the authors. :-) On 7/20/15 9:44 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions > Authors : Peter Saint-Andre > Saul Ibarra > Emil Ivov > Filename : draft-ietf-stox-media-07.txt > Pages : 28 > Date : 2015-07-20 > > Abstract: > This document defines a bidirectional protocol mapping for use by > gateways that enable the exchange of media signaling messages between > systems that implement the Session Initiation Protocol (SIP) and > systems that implement the Jingle extensions to the Extensible > Messaging and Presence Protocol (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-media/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stox-media-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From nobody Mon Jul 20 09:13:37 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DEF1A9030 for ; Mon, 20 Jul 2015 09:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 UIlkDDnaO_Nd for ; Mon, 20 Jul 2015 09:13:34 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 9F9B41A916D for ; Mon, 20 Jul 2015 09:13:34 -0700 (PDT) Received: by igbij6 with SMTP id ij6so86060431igb.1 for ; Mon, 20 Jul 2015 09:13:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XOYXMIKetJIPebsz5SRrvMWX8eClUqGhe+NNLZhrsiE=; b=YOKecyzr8dHNnlghAc0jc9MyLaDHMv2IumtnZgB3Hj77mg2B/EO90qLAKpGQ8kBQ+y prjNxNuI+z2h0WKxBp+4Ct8XB89/lFtwgsrmXh3PXlKKFTjArxAQ0R3LSDkbFQEIDHcK v7diQDFggBtn7Nn0b1JjwJv8CmicGPbWvF8rXx1aQH1oa7Exes8puRnZXGYQRtmPMtLR GwRH5IUJds3kh1I2jUnZQD/A2Kl60d+JNrLveyZuwTcCPX8ire1nzfgAnpoDF6vkopso rogTMOK5Lnf1eHJLXrWZgFMBRoxQ3b5KOypnbq8s32eHce/oZfbRWik/eYO8IExEBNrB rTcQ== X-Gm-Message-State: ALoCoQm7S+CLYOfKUBagH0Wehn/X2bcPanx+tcLnUbmdNVjBfkRNSNfqAFPZOox6EzI4LpooPOCB X-Received: by 10.50.73.170 with SMTP id m10mr16765227igv.60.1437408813941; Mon, 20 Jul 2015 09:13:33 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:f92d:45d0:a729:b1a0]) by smtp.googlemail.com with ESMTPSA id j3sm5514132ige.0.2015.07.20.09.13.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 09:13:32 -0700 (PDT) Message-ID: <55AD1E2A.9060102@andyet.net> Date: Mon, 20 Jul 2015 10:13:30 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Isomaki Markus (Nokia-TECH/Espoo)" , "stox@ietf.org" References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> In-Reply-To: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 20 Jul 2015 16:13:36 -0000 Hi Markus, thanks for the review. On 7/16/15 8:18 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: > Hi Peter, all, > > I did a review for the 7248bis-02 draft and unless I'm missing something, there seem to be still a few confusing things about the message flow diagrams and the terminology about SIP-to-XMPP and XMPP-to-SIP gateways. (The reason to go for 7248bis was indeed to fix the message flows so they are really the main part of it.) > > A minor issue: > - In the diagrams abbreviations S2X GW and X2S GW are used. While most readers can guess what they mean, it would be good to open them explicitly, perhaps in Section 3, Terminology. Yes, we borrow those terms from RFC 7247 but I agree it would be good to spell them out again here. > Bigger issues: > - The diagram in Section 4.2.1: It looks weird that the SIP server already generates the (F7) 200 OK message, By my reading of RFC 3856 the presence server sends the 200 OK as soon as the subscription request is approved. Do you think it shouldn't send the 200 OK until later (e.g., after it sends the NOTIFY)? > while the (F8) NOTIFY does not get any response. Shouldn't it be that the 200 OK is generated by the "X2S GW" and then passed forward by the SIP server? I agree that the gateway needs to send a 200 OK in response to the NOTIFY, and that would happen right after the current step F8. > - The text in 4.2.1 is somewhat confusing as well, as it first (understandably) talks about XMPP-to-SIP GW as shown in the diagram ("S2X"), but then (after Example 2) talks a few times about SIP-to-XMPP GW as well. I believe this is coming from 7248, which does have the two GWs as explicit entities in the diagram. But in 7248bis they are merged, and the current text makes the reader wonder if SIP-to-XMPP GW refers to the same entity as XMPP-to-SIP GW as shown, or whether there is another implicit/invisible GW function included. You are right - the text needs to be scrubbed a bit more. > - The same issue occurs in 4.3.1 in reverse. There, the diagram only has "S2X GW" but the text contains both SIP-to-XMPP and XMPP-to-SIP. Correct. > So we have gotten rid of the double gateways of 7248 in the diagrams, but they still somehow loom in the text and terminology. I think there are a couple of options to clarify this: Either always refer to the gateway as XMPP-to-SIP (X2S) in those sections that are about XMPP-to-SIP, and vice versa. Or, make the gateway direction neutral and just call it something like SIP-XMPP GW everywhere. Or, explain some more about the directions. Those gateways really don't want to be removed, do they? ;-) I'll clean up the text and diagrams, then post a revised I-D. > Sorry to be late about this, but I guess this is the last chance and we should definitely get the gateways right this time :-O Um, yes. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Jul 20 09:49:24 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76261ACE98; Mon, 20 Jul 2015 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kMto7UPh34VD; Mon, 20 Jul 2015 09:49:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FEF1ACE58; Mon, 20 Jul 2015 09:49:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720164920.13088.84233.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 09:49:20 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-7248bis-03.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 16:49:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author : Peter Saint-Andre Filename : draft-ietf-stox-7248bis-03.txt Pages : 27 Date : 2015-07-20 Abstract: This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stox-7248bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 22 05:30:49 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC95E1B318F for ; Wed, 22 Jul 2015 05:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 YUZRZmwgnf_D for ; Wed, 22 Jul 2015 05:30:45 -0700 (PDT) Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4E11B316D for ; Wed, 22 Jul 2015 05:30:44 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 22 Jul 2015 15:30:42 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 22 Jul 2015 15:30:41 +0300 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Wed, 22 Jul 2015 15:30:41 +0300 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: ext Peter Saint-Andre - &yet , "stox@ietf.org" , Ben Campbell , "rjsparks@nostrum.com" Thread-Topic: [Stox] Review for stox-7248bis-02 Thread-Index: AdC/0cUiLOk2SX8aQIy0VVTyZI/MLQDHBn4AAGBCokA= Date: Wed, 22 Jul 2015 12:30:41 +0000 Message-ID: References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> In-Reply-To: <55AD1E2A.9060102@andyet.net> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.50.32.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 22 Jul 2015 12:30:48 -0000 Hi Peter, I checked the revised draft (-03) and it addresses the issues I raised belo= w. But that brought up another thing still. It's been really long since I'= ve been dealing with SIP Presence, but I think that the message flows in 4.= 2.1 may still need a couple of clarifications: 1.)=20 In SIP, if the subscription is not immediately authorized (neither accepted= or rejected), it is possible that a 200 OK response to the SUBSCRIBE is se= nt immediately followed by a NOTIFY with subscription state "pending". If t= he SIP User later on positively authorizes the subscription, another NOTIFY= with subscription state "active" is generated. The potential "pending" sta= te does not seem to be covered in the current diagram, but it probably shou= ld be. The question is just what happens in XMPP-to-SIP GW if it gets a NOT= IFY with "pending" subscription state. To my understanding the subscription= state would remain "neutral" on the XMPP side. Would that mean that the XM= PP-to-SIP GW would not send anything to the XMPP side in that case, i.e. on= ly a NOTIFY indicating subscription state as "active" would cause the messa= ge (F10) to be triggered? In that case, maybe this kind of addition would b= e enough: OLD: In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider the subscription state to be "neutral" until it receives a NOTIFY message. Therefore, the SIP user or SIP server at the SIP user's domain SHOULD immediately send a NOTIFY message containing a Subscription-State header [RFC6665] whose value contains the string "active" (see Section 5 below). NEW: In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider the subscription state to be "neutral" until it receives a NOTIFY message. Therefore, the SIP user or SIP server at the SIP user's domain SHOULD immediately send a NOTIFY message containing a Subscription-State header [RFC6665] with value "active" (see Section 5=20 below). In case the XMPP-to-SIP gateway initially receives one or more=20 NOTIFY messages with Subscription-State "pending", it MUST respond to them on the SIP side, but not generate any presence stanzas towards t= he=20 XMPP User.=20 2.)=20 If you look at RFCs 3856 and 3857, the typical scenario in SIP presence is:= There is a SIP Presence Server handling the subscriptions to the presence = event package. That is where the SUBSCRIBE (F2) in 4.2.1 goes. But typicall= y the Presence Server would not forward the SUBSCRIBE to the SIP User in wa= y shown in (F3). Instead, the Presence Server and SIP User would interact v= ia the 'presence.winfo' event package (RFC 3857), to which the SIP User wou= ld be subcribed. So, when the Presence Server gets a SUBSCRIBE to SIP User'= s Presence, it generates a 'presence.winfo' NOTIFY the SIP User, who will t= hat way learn about the new subscription. The SIP User would then authorize= the subscription by some interaction (for instance using XCAP) with the Pr= esence Server. In this scenario, presence updates from the SIP User would a= lso not be sent as NOTIFYs, but as PUBLISH messages to the Presence Server,= who would then generate NOTIFYs to all active subscribers.=20 It is however possible that the Presence Server acts in a Proxy mode, in wh= ich case (as far as I remember), it just passes the SUBSCRIBEs and NOTIFYs = through as in the current diagram in 4.2.1. If we don't want to go into the= more complex diagrams, it would suffice just to say (already in terminolog= y or in 4.2.1): "In these examples it is assumed that the SIP Server acts a= s a proxy for Presence event package and the actual Presence Agent resides = with the SIP User." (I'm sure Ben and Robert would know exactly what is the best way of handlin= g these issues, so I included them in To:.) Regards, Markus=20 > -----Original Message----- > From: ext Peter Saint-Andre - &yet [mailto:peter@andyet.net] > Sent: Monday, July 20, 2015 7:14 PM > To: Isomaki Markus (Nokia-TECH/Espoo); stox@ietf.org > Subject: Re: [Stox] Review for stox-7248bis-02 >=20 > Hi Markus, thanks for the review. >=20 > On 7/16/15 8:18 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: > > Hi Peter, all, > > > > I did a review for the 7248bis-02 draft and unless I'm missing > > something, there seem to be still a few confusing things about the > > message flow diagrams and the terminology about SIP-to-XMPP and > > XMPP-to-SIP gateways. (The reason to go for 7248bis was indeed to fix > > the message flows so they are really the main part of it.) > > > > A minor issue: > > - In the diagrams abbreviations S2X GW and X2S GW are used. While most > readers can guess what they mean, it would be good to open them explicitl= y, > perhaps in Section 3, Terminology. >=20 > Yes, we borrow those terms from RFC 7247 but I agree it would be good to > spell them out again here. >=20 > > Bigger issues: > > - The diagram in Section 4.2.1: It looks weird that the SIP server > > already generates the (F7) 200 OK message, >=20 > By my reading of RFC 3856 the presence server sends the 200 OK as soon as > the subscription request is approved. Do you think it shouldn't send the = 200 > OK until later (e.g., after it sends the NOTIFY)? >=20 > > while the (F8) NOTIFY does not get any response. Shouldn't it be that t= he > 200 OK is generated by the "X2S GW" and then passed forward by the SIP > server? >=20 > I agree that the gateway needs to send a 200 OK in response to the NOTIFY= , > and that would happen right after the current step F8. >=20 > > - The text in 4.2.1 is somewhat confusing as well, as it first (underst= andably) > talks about XMPP-to-SIP GW as shown in the diagram ("S2X"), but then (aft= er > Example 2) talks a few times about SIP-to-XMPP GW as well. I believe this= is > coming from 7248, which does have the two GWs as explicit entities in the > diagram. But in 7248bis they are merged, and the current text makes the > reader wonder if SIP-to-XMPP GW refers to the same entity as XMPP-to-SIP > GW as shown, or whether there is another implicit/invisible GW function > included. >=20 > You are right - the text needs to be scrubbed a bit more. >=20 > > - The same issue occurs in 4.3.1 in reverse. There, the diagram only ha= s > "S2X GW" but the text contains both SIP-to-XMPP and XMPP-to-SIP. >=20 > Correct. >=20 > > So we have gotten rid of the double gateways of 7248 in the diagrams, b= ut > they still somehow loom in the text and terminology. I think there are a > couple of options to clarify this: Either always refer to the gateway as = XMPP- > to-SIP (X2S) in those sections that are about XMPP-to-SIP, and vice versa= . Or, > make the gateway direction neutral and just call it something like SIP-XM= PP > GW everywhere. Or, explain some more about the directions. >=20 > Those gateways really don't want to be removed, do they? ;-) I'll clean u= p the > text and diagrams, then post a revised I-D. >=20 > > Sorry to be late about this, but I guess this is the last chance and > > we should definitely get the gateways right this time :-O >=20 > Um, yes. :-) >=20 > Peter >=20 > -- > Peter Saint-Andre > https://andyet.com/ From nobody Wed Jul 22 23:04:37 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5161A870B for ; Wed, 22 Jul 2015 23:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 iVBkcogvOenP for ; Wed, 22 Jul 2015 23:04:34 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (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 A50EA1A70FD for ; Wed, 22 Jul 2015 23:04:34 -0700 (PDT) Received: by padck2 with SMTP id ck2so151190831pad.0 for ; Wed, 22 Jul 2015 23:04:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nqykrjsgITkOa7aKCIYUOm51c04J6v6wYBUmSGTqWVA=; b=dzuuMPobAR5VQM2KSugsXqll3mGQOpZfIVSe4Sb99UQZVHqhsixn+St234fJ7DnhFS soRZShPGPEfcf565DPSb+GJriuvPNc3U/ppH88Saj/eCToxkUSsoz1NEy4Gc/HbavNuO vlZmB/j39rJQh3fDd19khqNLPqXBnSMbMwvMfRGl6m8BV9T5isZYOiFzQe3EM/81xM8H WCrB/vaXvt8k4n4GPTx5xH8saTjNnYs6eDZCwE/UGdvmu9NNAmWQvxc36ya0Z5jdmHoI Mal4CoZE5/o+NbYGLb2lVUDVitmTznDe5OhtjX4PoVGYsGES3FkOUpfP2Dc/1beAIwYv g6nA== X-Gm-Message-State: ALoCoQm9c7WKtZdHPwAgh79ECt5Jx9gKTGK9pGWBKCEFD4y792fstckgIzyZiVPJqWxOlmVEZsXh X-Received: by 10.66.221.226 with SMTP id qh2mr15091079pac.64.1437631474018; Wed, 22 Jul 2015 23:04:34 -0700 (PDT) Received: from aither.local ([67.131.2.150]) by smtp.googlemail.com with ESMTPSA id lj7sm5889805pab.38.2015.07.22.23.04.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jul 2015 23:04:32 -0700 (PDT) To: "Isomaki Markus (Nokia-TECH/Espoo)" , "stox@ietf.org" , Ben Campbell , "rjsparks@nostrum.com" References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55B083ED.3090801@andyet.net> Date: Wed, 22 Jul 2015 23:04:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 23 Jul 2015 06:04:36 -0000 Hi Markus, thanks for the continued review. On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: > Hi Peter, > > I checked the revised draft (-03) and it addresses the issues I raised below. But that brought up another thing still. It's been really long since I've been dealing with SIP Presence, but I think that the message flows in 4.2.1 may still need a couple of clarifications: > > 1.) > > In SIP, if the subscription is not immediately authorized (neither accepted or rejected), it is possible that a 200 OK response to the SUBSCRIBE is sent immediately followed by a NOTIFY with subscription state "pending". If the SIP User later on positively authorizes the subscription, another NOTIFY with subscription state "active" is generated. The potential "pending" state does not seem to be covered in the current diagram, but it probably should be. The question is just what happens in XMPP-to-SIP GW if it gets a NOTIFY with "pending" subscription state. To my understanding the subscription state would remain "neutral" on the XMPP side. Would that mean that the XMPP-to-SIP GW would not send anything to the XMPP side in that case, i.e. only a NOTIFY indicating subscription state as "active" would cause the message (F10) to be triggered? In that case, maybe this kind of addition would be enough: > > OLD: > > In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider > the subscription state to be "neutral" until it receives a NOTIFY > message. Therefore, the SIP user or SIP server at the SIP user's > domain SHOULD immediately send a NOTIFY message containing a > Subscription-State header [RFC6665] whose value contains the string > "active" (see Section 5 below). > > NEW: > > In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider > the subscription state to be "neutral" until it receives a NOTIFY > message. Therefore, the SIP user or SIP server at the SIP user's > domain SHOULD immediately send a NOTIFY message containing a > Subscription-State header [RFC6665] with value "active" (see Section 5 > below). In case the XMPP-to-SIP gateway initially receives one or more > NOTIFY messages with Subscription-State "pending", it MUST respond > to them on the SIP side, but not generate any presence stanzas towards the > XMPP User. That it better. The only further change I would make is: In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider the subscription state to be "neutral" until it receives a NOTIFY message with a Subscription-State header [RFC6665] whose value is "active". Also, I think it would make sense to change SHOULD to MUST here. > 2.) > > If you look at RFCs 3856 and 3857, the typical scenario in SIP presence is: There is a SIP Presence Server handling the subscriptions to the presence event package. That is where the SUBSCRIBE (F2) in 4.2.1 goes. But typically the Presence Server would not forward the SUBSCRIBE to the SIP User in way shown in (F3). Instead, the Presence Server and SIP User would interact via the 'presence.winfo' event package (RFC 3857), to which the SIP User would be subcribed. So, when the Presence Server gets a SUBSCRIBE to SIP User's Presence, it generates a 'presence.winfo' NOTIFY the SIP User, who will that way learn about the new subscription. The SIP User would then authorize the subscription by some interaction (for instance using XCAP) with the Presence Server. In this scenario, presence updates from the SIP User would also not be sent as NOTIFYs, but as PUBLISH messages to the Presence Server, who would then generate NOTIFYs to all active subscribers. > > It is however possible that the Presence Server acts in a Proxy mode, in which case (as far as I remember), it just passes the SUBSCRIBEs and NOTIFYs through as in the current diagram in 4.2.1. If we don't want to go into the more complex diagrams, it would suffice just to say (already in terminology or in 4.2.1): "In these examples it is assumed that the SIP Server acts as a proxy for Presence event package and the actual Presence Agent resides with the SIP User." Yes, the latter seems reasonable. However, also pointing to RFC 3857 seems like a good idea. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Jul 26 14:22:11 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988181A0270; Sun, 26 Jul 2015 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 s_6kmkVZX8wK; Sun, 26 Jul 2015 14:22:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3041A01F0; Sun, 26 Jul 2015 14:22:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150726212206.1259.19484.idtracker@ietfa.amsl.com> Date: Sun, 26 Jul 2015 14:22:06 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-7248bis-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 21:22:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author : Peter Saint-Andre Filename : draft-ietf-stox-7248bis-04.txt Pages : 27 Date : 2015-07-26 Abstract: This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stox-7248bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 26 14:23:04 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D1D1A02F1 for ; Sun, 26 Jul 2015 14:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 XnYvc5SLgs2e for ; Sun, 26 Jul 2015 14:23:01 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 A8E341A0211 for ; Sun, 26 Jul 2015 14:23:01 -0700 (PDT) Received: by igk11 with SMTP id 11so38985815igk.1 for ; Sun, 26 Jul 2015 14:23:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=X14wD8abQJm11A/WeZss/c9RdjPVs69As3ADoPJxjR0=; b=Aja876hpbtkPWODgXjnP+MRQ6V5Iq8eEhqv3FR2RZtVU3P5r+aMutzzvPyLrqr6SCD 56ZT2Mr4riiF8ZlKy+9qtis7+PF3Jrwkspa7OvoYpbbzPo/rL3i8p4msSJh9PcmxNDGX gWYxksVY1gcsn2lWUHKzv+ThDwFsyw4csHA9NBPos951SWm7pW+hwfsf9YzTbQNKuJVp EgEaY0KKbv56dv2A6vJ80OC5kIfaQ2fzssFpP6b4dy61Xjua7XArgZJ9cOkmlQdubA2d gVjQQLywBTb4HNhdEvJ+JHGFdxO6isRhQ9g1ow8qH+43L4wMwRZ8DvhxoLOqO+2khJYk y1gA== X-Gm-Message-State: ALoCoQksdUeo5F/4pyiuaZDZWWMRUzAzZ3VqLxXXFwjH/U53lYy0KOQe2QYA6sm7vn+Xl2jjmFoB X-Received: by 10.50.136.134 with SMTP id qa6mr12423686igb.26.1437945781150; Sun, 26 Jul 2015 14:23:01 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:656a:8ad7:bf39:2c55]) by smtp.googlemail.com with ESMTPSA id j20sm4529550igt.16.2015.07.26.14.22.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 14:22:59 -0700 (PDT) To: "Isomaki Markus (Nokia-TECH/Espoo)" , "stox@ietf.org" , Ben Campbell , "rjsparks@nostrum.com" References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55B54FB1.8090009@andyet.net> Date: Sun, 26 Jul 2015 15:22:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B083ED.3090801@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 26 Jul 2015 21:23:03 -0000 I've posted -04 to address this feedback. Peter On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote: > Hi Markus, thanks for the continued review. > > On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: >> Hi Peter, >> >> I checked the revised draft (-03) and it addresses the issues I raised >> below. But that brought up another thing still. It's been really long >> since I've been dealing with SIP Presence, but I think that the >> message flows in 4.2.1 may still need a couple of clarifications: >> >> 1.) >> >> In SIP, if the subscription is not immediately authorized (neither >> accepted or rejected), it is possible that a 200 OK response to the >> SUBSCRIBE is sent immediately followed by a NOTIFY with subscription >> state "pending". If the SIP User later on positively authorizes the >> subscription, another NOTIFY with subscription state "active" is >> generated. The potential "pending" state does not seem to be covered >> in the current diagram, but it probably should be. The question is >> just what happens in XMPP-to-SIP GW if it gets a NOTIFY with "pending" >> subscription state. To my understanding the subscription state would >> remain "neutral" on the XMPP side. Would that mean that the >> XMPP-to-SIP GW would not send anything to the XMPP side in that case, >> i.e. only a NOTIFY indicating subscription state as "active" would >> cause the message (F10) to be triggered? In that case, maybe this kind >> of addition would be enough: >> >> OLD: >> >> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >> the subscription state to be "neutral" until it receives a NOTIFY >> message. Therefore, the SIP user or SIP server at the SIP user's >> domain SHOULD immediately send a NOTIFY message containing a >> Subscription-State header [RFC6665] whose value contains the string >> "active" (see Section 5 below). >> >> NEW: >> >> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >> the subscription state to be "neutral" until it receives a NOTIFY >> message. Therefore, the SIP user or SIP server at the SIP user's >> domain SHOULD immediately send a NOTIFY message containing a >> Subscription-State header [RFC6665] with value "active" (see >> Section 5 >> below). In case the XMPP-to-SIP gateway initially receives one or >> more >> NOTIFY messages with Subscription-State "pending", it MUST respond >> to them on the SIP side, but not generate any presence stanzas >> towards the >> XMPP User. > > That it better. The only further change I would make is: > > In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider > the subscription state to be "neutral" until it receives a NOTIFY > message with a Subscription-State header [RFC6665] whose value is > "active". > > Also, I think it would make sense to change SHOULD to MUST here. > >> 2.) >> >> If you look at RFCs 3856 and 3857, the typical scenario in SIP >> presence is: There is a SIP Presence Server handling the subscriptions >> to the presence event package. That is where the SUBSCRIBE (F2) in >> 4.2.1 goes. But typically the Presence Server would not forward the >> SUBSCRIBE to the SIP User in way shown in (F3). Instead, the Presence >> Server and SIP User would interact via the 'presence.winfo' event >> package (RFC 3857), to which the SIP User would be subcribed. So, when >> the Presence Server gets a SUBSCRIBE to SIP User's Presence, it >> generates a 'presence.winfo' NOTIFY the SIP User, who will that way >> learn about the new subscription. The SIP User would then authorize >> the subscription by some interaction (for instance using XCAP) with >> the Presence Server. In this scenario, presence updates from the SIP >> User would also not be sent as NOTIFYs, but as PUBLISH messages to the >> Presence Server, who would then generate NOTIFYs to all active >> subscribers. >> >> It is however possible that the Presence Server acts in a Proxy mode, >> in which case (as far as I remember), it just passes the SUBSCRIBEs >> and NOTIFYs through as in the current diagram in 4.2.1. If we don't >> want to go into the more complex diagrams, it would suffice just to >> say (already in terminology or in 4.2.1): "In these examples it is >> assumed that the SIP Server acts as a proxy for Presence event package >> and the actual Presence Agent resides with the SIP User." > > Yes, the latter seems reasonable. However, also pointing to RFC 3857 > seems like a good idea. > > Peter > From nobody Mon Jul 27 00:52:17 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D01AD09D for ; Mon, 27 Jul 2015 00:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 zG25tAsLJU9e for ; Mon, 27 Jul 2015 00:52:12 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8681ACEC0 for ; Mon, 27 Jul 2015 00:52:12 -0700 (PDT) Received: from [192.168.99.53] (g95173.upc-g.chello.nl [80.57.95.173]) by mail.sipthor.net (Postfix) with ESMTPSA id 0078716DC6B2; Mon, 27 Jul 2015 09:52:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_864A60EE-8FD9-46F8-9109-042C1F431534"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: =?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= In-Reply-To: <55B54FB1.8090009@andyet.net> Date: Mon, 27 Jul 2015 09:52:01 +0200 Message-Id: <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com> References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stox@ietf.org" , Ben Campbell , "rjsparks@nostrum.com" , "Isomaki Markus \(Nokia-TECH/Espoo\)" Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 27 Jul 2015 07:52:14 -0000 --Apple-Mail=_864A60EE-8FD9-46F8-9109-042C1F431534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry folks, I=E2=80=99ve been AFK for the past few days. I=E2=80=99ll = review this version and get the writeup done. > On 26 Jul 2015, at 23:22, Peter Saint-Andre - &yet = wrote: >=20 > I've posted -04 to address this feedback. >=20 > Peter >=20 > On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote: >> Hi Markus, thanks for the continued review. >>=20 >> On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: >>> Hi Peter, >>>=20 >>> I checked the revised draft (-03) and it addresses the issues I = raised >>> below. But that brought up another thing still. It's been really = long >>> since I've been dealing with SIP Presence, but I think that the >>> message flows in 4.2.1 may still need a couple of clarifications: >>>=20 >>> 1.) >>>=20 >>> In SIP, if the subscription is not immediately authorized (neither >>> accepted or rejected), it is possible that a 200 OK response to the >>> SUBSCRIBE is sent immediately followed by a NOTIFY with subscription >>> state "pending". If the SIP User later on positively authorizes the >>> subscription, another NOTIFY with subscription state "active" is >>> generated. The potential "pending" state does not seem to be covered >>> in the current diagram, but it probably should be. The question is >>> just what happens in XMPP-to-SIP GW if it gets a NOTIFY with = "pending" >>> subscription state. To my understanding the subscription state would >>> remain "neutral" on the XMPP side. Would that mean that the >>> XMPP-to-SIP GW would not send anything to the XMPP side in that = case, >>> i.e. only a NOTIFY indicating subscription state as "active" would >>> cause the message (F10) to be triggered? In that case, maybe this = kind >>> of addition would be enough: >>>=20 >>> OLD: >>>=20 >>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD = consider >>> the subscription state to be "neutral" until it receives a NOTIFY >>> message. Therefore, the SIP user or SIP server at the SIP user's >>> domain SHOULD immediately send a NOTIFY message containing a >>> Subscription-State header [RFC6665] whose value contains the = string >>> "active" (see Section 5 below). >>>=20 >>> NEW: >>>=20 >>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD = consider >>> the subscription state to be "neutral" until it receives a NOTIFY >>> message. Therefore, the SIP user or SIP server at the SIP user's >>> domain SHOULD immediately send a NOTIFY message containing a >>> Subscription-State header [RFC6665] with value "active" (see >>> Section 5 >>> below). In case the XMPP-to-SIP gateway initially receives one or >>> more >>> NOTIFY messages with Subscription-State "pending", it MUST = respond >>> to them on the SIP side, but not generate any presence stanzas >>> towards the >>> XMPP User. >>=20 >> That it better. The only further change I would make is: >>=20 >> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD = consider >> the subscription state to be "neutral" until it receives a NOTIFY >> message with a Subscription-State header [RFC6665] whose value is >> "active". >>=20 >> Also, I think it would make sense to change SHOULD to MUST here. >>=20 >>> 2.) >>>=20 >>> If you look at RFCs 3856 and 3857, the typical scenario in SIP >>> presence is: There is a SIP Presence Server handling the = subscriptions >>> to the presence event package. That is where the SUBSCRIBE (F2) in >>> 4.2.1 goes. But typically the Presence Server would not forward the >>> SUBSCRIBE to the SIP User in way shown in (F3). Instead, the = Presence >>> Server and SIP User would interact via the 'presence.winfo' event >>> package (RFC 3857), to which the SIP User would be subcribed. So, = when >>> the Presence Server gets a SUBSCRIBE to SIP User's Presence, it >>> generates a 'presence.winfo' NOTIFY the SIP User, who will that way >>> learn about the new subscription. The SIP User would then authorize >>> the subscription by some interaction (for instance using XCAP) with >>> the Presence Server. In this scenario, presence updates from the SIP >>> User would also not be sent as NOTIFYs, but as PUBLISH messages to = the >>> Presence Server, who would then generate NOTIFYs to all active >>> subscribers. >>>=20 >>> It is however possible that the Presence Server acts in a Proxy = mode, >>> in which case (as far as I remember), it just passes the SUBSCRIBEs >>> and NOTIFYs through as in the current diagram in 4.2.1. If we don't >>> want to go into the more complex diagrams, it would suffice just to >>> say (already in terminology or in 4.2.1): "In these examples it is >>> assumed that the SIP Server acts as a proxy for Presence event = package >>> and the actual Presence Agent resides with the SIP User." >>=20 >> Yes, the latter seems reasonable. However, also pointing to RFC 3857 >> seems like a good idea. >>=20 >> Peter >>=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=C3=BAl Ibarra Corretg=C3=A9 AG Projects --Apple-Mail=_864A60EE-8FD9-46F8-9109-042C1F431534 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVteMlAAoJEN2cyH9ENwiqQkQQAKBN2X3JQCEKjx5lJpUNTLWF cPghHYLkgh/2HnL24hrfQMexLz1LCfrlqNopEzuR/L4fpnpJ325m75joXtQVDpu9 X6XfBsxUUeZpAMNYLTfnV6YwG8nxX4jjZ+lzOkKkTHG7fX1rtH/EtmROwsfnNLz2 GQJPkm/TRm9xeHMfD1QBtcN7gzm66CYpnsMJLI9yXX1kIXM9pgBhzn98TxwvBbxL qEY1HD5wM0xQZ+hCCScP8QxGAKZ0eXkUNKP3kodx9NFqXs0zW32N5gTjy5qtbBO8 Kn+WsvozlkG6GEVD0gDvtGB/oYtwllgDBJ/CRHQVJ8LoKeSLEk7yPfi36HE+yv/Z FIbVAeZz4RS+3cTe2PHFzRlUKirII90NFrSSZ9OcEQaCE//Yh8nkL+sa3sjyuIoy 2kHommvGKywfir8Ybh8GLfA1EDxs0FJOMtnEpDrxzKcI5ES+9XDy/9Ws1nkuoCfd 4qjGotmvASASzPb/Izz0CtOEaYYOxCLfCMlAc/g4hCJzZvZB3b/7w093NhSswtPa x2uB+geq4OKrdJhAtn04NE7KKEENTTuMXCwtPw7Pyw+GVbi4Ep5iKDZqpbqxqyFB al4GXVw+oirUExulb9YOlynr3eBdR9n/4hmlmZyUjAFbaS9A7wJSLC/2IuJwOHZP q30ixEeYAbqdpaqABE13 =GxXB -----END PGP SIGNATURE----- --Apple-Mail=_864A60EE-8FD9-46F8-9109-042C1F431534-- From nobody Mon Jul 27 06:42:03 2015 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89EE1B2D39 for ; Mon, 27 Jul 2015 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 lUIi0ZsIc632 for ; Mon, 27 Jul 2015 06:42:00 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (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 A65871B2D7F for ; Mon, 27 Jul 2015 06:42:00 -0700 (PDT) Received: by obbop1 with SMTP id op1so59486380obb.2 for ; Mon, 27 Jul 2015 06:42:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BYD5i3L5KyJoSaN3vQzwnDlfp4C3PfjuQE7a9OANJa8=; b=C08mm7+LEjCgwtQNAO1WL1h30SEyg1jQ8nnhqAxOZHwiQD0LMpNFFjkS7pN+VHS072 K9HOQPIghuAtEwVrU7vCXnd5ac0IC3kQKiFg9Y/398ovRiqbxPbVYUCV6XBcb5NsWVMl 6SN2APBfLsLYvi3k43qO13PolSnItp/gv67UifDpRthtJPH97q9FIhSdl3o7JR6z2gyN UbPFzRW2R/4jLHcdSSskHgGP29+hWmlVItWQAKFoJ0Hb9MXjoqsXKk8agU4CMll/5f9F Yw0WAeHWIC82rA6DGo7njAxPikSMSihzYUmwerorP43HyHzdnq8KIKfRvlH0pX1KsB+J CBOw== X-Gm-Message-State: ALoCoQlhw8jgyX2vgD2U8s3QYSH8sJwgoH0fGEACh9sQSdoZNvL/hm+78UhmcaJID+WWMU3Kwrke X-Received: by 10.60.133.137 with SMTP id pc9mr27373382oeb.76.1438004520046; Mon, 27 Jul 2015 06:42:00 -0700 (PDT) Received: from [10.81.215.170] (mobile-166-173-058-196.mycingular.net. [166.173.58.196]) by smtp.gmail.com with ESMTPSA id jp2sm10335295oeb.4.2015.07.27.06.41.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 06:41:58 -0700 (PDT) References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <186194A5-0665-4AC9-8588-00C54A59975A@andyet.net> X-Mailer: iPhone Mail (12H143) From: Peter Saint-Andre Date: Mon, 27 Jul 2015 07:41:50 -0600 To: =?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Archived-At: Cc: "stox@ietf.org" , Ben Campbell , "rjsparks@nostrum.com" , "Isomaki Markus \(Nokia-TECH/Espoo\)" Subject: Re: [Stox] Review for stox-7248bis-02 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 27 Jul 2015 13:42:03 -0000 Thanks much! :) > On Jul 27, 2015, at 1:52 AM, Sa=C3=BAl Ibarra Corretg=C3=A9 wrote: >=20 > Sorry folks, I=E2=80=99ve been AFK for the past few days. I=E2=80=99ll rev= iew this version and get the writeup done. >=20 >> On 26 Jul 2015, at 23:22, Peter Saint-Andre - &yet wro= te: >>=20 >> I've posted -04 to address this feedback. >>=20 >> Peter >>=20 >>> On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote: >>> Hi Markus, thanks for the continued review. >>>=20 >>>> On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: >>>> Hi Peter, >>>>=20 >>>> I checked the revised draft (-03) and it addresses the issues I raised >>>> below. But that brought up another thing still. It's been really long >>>> since I've been dealing with SIP Presence, but I think that the >>>> message flows in 4.2.1 may still need a couple of clarifications: >>>>=20 >>>> 1.) >>>>=20 >>>> In SIP, if the subscription is not immediately authorized (neither >>>> accepted or rejected), it is possible that a 200 OK response to the >>>> SUBSCRIBE is sent immediately followed by a NOTIFY with subscription >>>> state "pending". If the SIP User later on positively authorizes the >>>> subscription, another NOTIFY with subscription state "active" is >>>> generated. The potential "pending" state does not seem to be covered >>>> in the current diagram, but it probably should be. The question is >>>> just what happens in XMPP-to-SIP GW if it gets a NOTIFY with "pending" >>>> subscription state. To my understanding the subscription state would >>>> remain "neutral" on the XMPP side. Would that mean that the >>>> XMPP-to-SIP GW would not send anything to the XMPP side in that case, >>>> i.e. only a NOTIFY indicating subscription state as "active" would >>>> cause the message (F10) to be triggered? In that case, maybe this kind >>>> of addition would be enough: >>>>=20 >>>> OLD: >>>>=20 >>>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider= >>>> the subscription state to be "neutral" until it receives a NOTIFY >>>> message. Therefore, the SIP user or SIP server at the SIP user's >>>> domain SHOULD immediately send a NOTIFY message containing a >>>> Subscription-State header [RFC6665] whose value contains the string >>>> "active" (see Section 5 below). >>>>=20 >>>> NEW: >>>>=20 >>>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider= >>>> the subscription state to be "neutral" until it receives a NOTIFY >>>> message. Therefore, the SIP user or SIP server at the SIP user's >>>> domain SHOULD immediately send a NOTIFY message containing a >>>> Subscription-State header [RFC6665] with value "active" (see >>>> Section 5 >>>> below). In case the XMPP-to-SIP gateway initially receives one or >>>> more >>>> NOTIFY messages with Subscription-State "pending", it MUST respond >>>> to them on the SIP side, but not generate any presence stanzas >>>> towards the >>>> XMPP User. >>>=20 >>> That it better. The only further change I would make is: >>>=20 >>> In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider >>> the subscription state to be "neutral" until it receives a NOTIFY >>> message with a Subscription-State header [RFC6665] whose value is >>> "active". >>>=20 >>> Also, I think it would make sense to change SHOULD to MUST here. >>>=20 >>>> 2.) >>>>=20 >>>> If you look at RFCs 3856 and 3857, the typical scenario in SIP >>>> presence is: There is a SIP Presence Server handling the subscriptions >>>> to the presence event package. That is where the SUBSCRIBE (F2) in >>>> 4.2.1 goes. But typically the Presence Server would not forward the >>>> SUBSCRIBE to the SIP User in way shown in (F3). Instead, the Presence >>>> Server and SIP User would interact via the 'presence.winfo' event >>>> package (RFC 3857), to which the SIP User would be subcribed. So, when >>>> the Presence Server gets a SUBSCRIBE to SIP User's Presence, it >>>> generates a 'presence.winfo' NOTIFY the SIP User, who will that way >>>> learn about the new subscription. The SIP User would then authorize >>>> the subscription by some interaction (for instance using XCAP) with >>>> the Presence Server. In this scenario, presence updates from the SIP >>>> User would also not be sent as NOTIFYs, but as PUBLISH messages to the >>>> Presence Server, who would then generate NOTIFYs to all active >>>> subscribers. >>>>=20 >>>> It is however possible that the Presence Server acts in a Proxy mode, >>>> in which case (as far as I remember), it just passes the SUBSCRIBEs >>>> and NOTIFYs through as in the current diagram in 4.2.1. If we don't >>>> want to go into the more complex diagrams, it would suffice just to >>>> say (already in terminology or in 4.2.1): "In these examples it is >>>> assumed that the SIP Server acts as a proxy for Presence event package >>>> and the actual Presence Agent resides with the SIP User." >>>=20 >>> Yes, the latter seems reasonable. However, also pointing to RFC 3857 >>> seems like a good idea. >>>=20 >>> Peter >>=20 >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >=20 > -- > Sa=C3=BAl Ibarra Corretg=C3=A9 > AG Projects >=20 >=20 >=20