From nobody Mon Aug 3 12:45: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 096311ACD66 for ; Mon, 3 Aug 2015 12:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] 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 CnCVGNM00Uy0 for ; Mon, 3 Aug 2015 12:45:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5118C1ACD62 for ; Mon, 3 Aug 2015 12:45:45 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t73JjTiK082537 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Aug 2015 14:45:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Mon, 03 Aug 2015 14:45:29 -0500 Message-ID: <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.com> In-Reply-To: <55B54FB1.8090009@andyet.net> References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: stox@ietf.org, rjsparks@nostrum.com, Isomaki Markus 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, 03 Aug 2015 19:45:47 -0000 Hi, A couple of thoughts on this: The additional text in 04 about waiting for a NOTIFY with an active state helps. But it might be worth adding an initial "pending" notify exchange to (at least) 5.2.1. On the architectural question: I think that the "more complex" architecture is also the more relevant one. But, you could ignore this completely by just changing "SIP User" to "Presence Server" in 5.2.* . Unless I'm forgetting something, the architectural questions should not change the interactions to the left of the presence server. Then the architectural note could simply state that this may be a separate presence server, or it may be co-located with the SIP UA, but the relevant XMPP to SIP flow is the same either way. Also,the idea of a SIP "server" is architecturally vague--there's no such animal defined in the SIP standards. I suggest calling it a SIP Proxy in 5.2.*. In 5.3.*, it could either be a "SIP Proxy + S2X GW", or just a "S2X GW" Ben. On 26 Jul 2015, at 16:22, Peter Saint-Andre - &yet wrote: > 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 Thu Aug 6 03:31: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 9FB3A1B2C3E for ; Thu, 6 Aug 2015 03:31:35 -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 9wwXhOBRGhMa for ; Thu, 6 Aug 2015 03:31:33 -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 666131B2C3D for ; Thu, 6 Aug 2015 03:31:32 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 06 Aug 2015 13:31:30 +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, 6 Aug 2015 13:31:29 +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, 6 Aug 2015 13:31:29 +0300 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: ext Ben Campbell , Peter Saint-Andre - &yet Thread-Topic: [Stox] Review for stox-7248bis-02 Thread-Index: AdC/0cUiLOk2SX8aQIy0VVTyZI/MLQDHBn4AAGBCokAAIVglgAC284uAAY7taIAAiU2PEA== Date: Thu, 6 Aug 2015 10:31:28 +0000 Message-ID: <09f0827aae654a01947fd2c5f234b80c@NOKWDCFIEXCH02P.nnok.nokia.com> References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.com> In-Reply-To: <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.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: Cc: "stox@ietf.org" , "rjsparks@nostrum.com" 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, 06 Aug 2015 10:31:35 -0000 Hi, This is very good feedback. See inline. Ben Campbell [mailto:ben@nostrum.com] wrote: >=20 > The additional text in 04 about waiting for a NOTIFY with an active state= helps. > But it might be worth adding an initial "pending" notify exchange to (at = least) > 5.2.1. >=20 I agree with this. > On the architectural question: I think that the "more complex" > architecture is also the more relevant one. But, you could ignore this co= mpletely > by just changing "SIP User" to "Presence Server" in 5.2.* . > Unless I'm forgetting something, the architectural questions should not c= hange > the interactions to the left of the presence server. Then the architectur= al note > could simply state that this may be a separate presence server, or it may= be co- > located with the SIP UA, but the relevant XMPP to SIP flow is the same ei= ther > way. >=20 This is my understanding too. One way to address this would be to change "S= IP User" to "SIP User (Agent) or Presence Server" in 5.2.*. Section 4 would= be modified to say that presence subscriptions can be handled directly by = a SIP User (Agent) or by a Presence Server acting on SIP User's behalf. In = either case the message flow from the X2S GW's perspective is identical. Th= e interaction between the Presence Server (when present) and the User Agent= (winfo, PUBLISH, ...) could be verbally explained as already in Section 4,= but it can be said it is out of scope of the diagrams in Section 5.2.*, as= that interaction is hidden from the XMPP-SIP interworking perspective. > Also,the idea of a SIP "server" is architecturally vague--there's no such= animal > defined in the SIP standards. I suggest calling it a SIP Proxy in 5.2.*. = In 5.3.*, it > could either be a "SIP Proxy + S2X GW", or just a "S2X GW" >=20 Perhaps just change it to "SIP Proxy" where applicable. > Ben. >=20 Markus --- >=20 >=20 > On 26 Jul 2015, at 16:22, Peter Saint-Andre - &yet wrote: >=20 > > 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 Aug 10 08:45:19 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 E748B1B3713 for ; Mon, 10 Aug 2015 08:45:17 -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 azOoG-RLCDe3 for ; Mon, 10 Aug 2015 08:45:15 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (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 B32301A885D for ; Mon, 10 Aug 2015 08:45:15 -0700 (PDT) Received: by pdrg1 with SMTP id g1so72843653pdr.2 for ; Mon, 10 Aug 2015 08:45:15 -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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4gKhfh3qIuYxKDbX6Om5JfhUYH+KtQ8AA0lOy1WrXsE=; b=ZPhyO/bnOlsNCjVkh47gdbtte3svt8hL0BCoUxhHRvfsPv4rIRgupCFqpm29jtN8Nv C9UNiWVia6x+mroAb92hTJ04oiVIYXojFPKuVK3ZHd3Zaptl/vF0cLkVtHzSNKZHlJ+L wnqcz1s6lz1Cv/JfIsBoeGAIrOksccBhTZR6MnqZAx808DMtYICRXrbP1xcRm/hiGc7t 07TsDqmOQeIuFtz5g16B/aPzy22fZJ4MhUhIO9tiKbUfQq8OzGiaxy9zwiHJRn18WxFS YC+ViHIALI+pQl0EotreNJ4IIk0Ngpb0ojPt1ZdS9TDXIMF61dPCnI4a+JYu7uELvvs3 dkug== X-Gm-Message-State: ALoCoQl9Eb1nqwgKLBpsjgl2RNzAoMucQXnHx0b+bxzk0kjchlbKA586B2jC/ALmHupDbaJxDMDc X-Received: by 10.70.100.65 with SMTP id ew1mr26096104pdb.110.1439221515205; Mon, 10 Aug 2015 08:45:15 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:d52f:7f28:4f42:28fd]) by smtp.googlemail.com with ESMTPSA id kx11sm10564727pab.13.2015.08.10.08.45.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 08:45:13 -0700 (PDT) To: "Isomaki Markus (Nokia-TECH/Espoo)" , ext Ben Campbell References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.com> <09f0827aae654a01947fd2c5f234b80c@NOKWDCFIEXCH02P.nnok.nokia.com> From: Peter Saint-Andre - &yet Message-ID: <55C8C706.1040104@andyet.net> Date: Mon, 10 Aug 2015 09:45:10 -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: <09f0827aae654a01947fd2c5f234b80c@NOKWDCFIEXCH02P.nnok.nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "stox@ietf.org" , "rjsparks@nostrum.com" 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, 10 Aug 2015 15:45:18 -0000 On 8/6/15 4:31 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote: > Hi, > > This is very good feedback. Indeed, thanks to you both. > See inline. > > Ben Campbell [mailto:ben@nostrum.com] wrote: >> >> The additional text in 04 about waiting for a NOTIFY with an active state helps. >> But it might be worth adding an initial "pending" notify exchange to (at least) >> 5.2.1. >> > > I agree with this. +1 >> On the architectural question: I think that the "more complex" >> architecture is also the more relevant one. But, you could ignore this completely >> by just changing "SIP User" to "Presence Server" in 5.2.* . >> Unless I'm forgetting something, the architectural questions should not change >> the interactions to the left of the presence server. Then the architectural note >> could simply state that this may be a separate presence server, or it may be co- >> located with the SIP UA, but the relevant XMPP to SIP flow is the same either >> way. >> > > This is my understanding too. One way to address this would be to change "SIP User" to "SIP User (Agent) or Presence Server" in 5.2.*. Section 4 would be modified to say that presence subscriptions can be handled directly by a SIP User (Agent) or by a Presence Server acting on SIP User's behalf. In either case the message flow from the X2S GW's perspective is identical. The interaction between the Presence Server (when present) and the User Agent (winfo, PUBLISH, ...) could be verbally explained as already in Section 4, but it can be said it is out of scope of the diagrams in Section 5.2.*, as that interaction is hidden from the XMPP-SIP interworking perspective. I like that proposal. >> Also,the idea of a SIP "server" is architecturally vague--there's no such animal >> defined in the SIP standards. I suggest calling it a SIP Proxy in 5.2.*. In 5.3.*, it >> could either be a "SIP Proxy + S2X GW", or just a "S2X GW" >> > > Perhaps just change it to "SIP Proxy" where applicable. Yes. I'll work on a revised I-D this week. Peter > >> Ben. >> > > Markus > > --- > >> >> >> On 26 Jul 2015, at 16:22, Peter Saint-Andre - &yet wrote: >> >>> 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 >>>> -- Peter Saint-Andre https://andyet.com/ From nobody Tue Aug 11 16:53:06 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 D7F541A0187; Tue, 11 Aug 2015 16:53:03 -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 HvGDjIm0ktof; Tue, 11 Aug 2015 16:53:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D342B1A011B; Tue, 11 Aug 2015 16:53:01 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150811235301.7315.37077.idtracker@ietfa.amsl.com> Date: Tue, 11 Aug 2015 16:53:01 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-7248bis-05.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: Tue, 11 Aug 2015 23:53:04 -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-05.txt Pages : 28 Date : 2015-08-11 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-05 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 Aug 12 06:39:05 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 BEE521A0094 for ; Wed, 12 Aug 2015 06:39: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 n8MdEpuaAGf2 for ; Wed, 12 Aug 2015 06:39:02 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 6A40E1B2DE5 for ; Wed, 12 Aug 2015 06:38:27 -0700 (PDT) Received: by igbij6 with SMTP id ij6so111706538igb.1 for ; Wed, 12 Aug 2015 06:38:26 -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=xNIvdFlB3lNRvdoe3d/3LTT1Oe2qtfCWpFpgVn8DntA=; b=Qu+HfNPvIGmHR/4tiRoqsmYLG2OoQbZJFFbvnmxMZyzMSZh6mfc9+JPuywZHFEh8XA yHPg3T7c3sRHjsjLxk7IwGakggMpBfieY0BOrrghuCUrs2x7aSqA0CQFWFCb6WDfRJg7 19eQrlgzJr0ajBkZPIcVC99JhZZT5NpgWdWyCsgsbLb5VHqoQxMp0slONuP4WCVmJVCo YS0Sb0eKah/9vuAoZYivG2L2ho6ya4XtNbLi4FJ8MyXSPT2TNSAOhOh11CS4Sw8Sfat5 d09Q0e/F1DN6vmcEmZMT11WYHVGrxQSR5r3dJtllYSpDGoeFQt2flFqLvYELe4yGsL27 lGZg== X-Gm-Message-State: ALoCoQkU6I7TU1qUnQukBNuVs73hbDimLOMW+l/rxW0hGym9rDIzehcLoFn5cK8BA0Rlwp2t/FIv X-Received: by 10.50.66.129 with SMTP id f1mr22745744igt.7.1439386706691; Wed, 12 Aug 2015 06:38:26 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id rr5sm3837211igb.7.2015.08.12.06.38.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 06:38:25 -0700 (PDT) To: stox@ietf.org References: <20150811235301.7315.37077.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55CB4C4F.7000107@andyet.net> Date: Wed, 12 Aug 2015 07:38:23 -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: <20150811235301.7315.37077.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-7248bis-05.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: Wed, 12 Aug 2015 13:39:03 -0000 Revisions to address feedback from Markus and Ben. Gentlemen, does this version meet your needs? Peter On 8/11/15 5:53 PM, 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): Presence > Author : Peter Saint-Andre > Filename : draft-ietf-stox-7248bis-05.txt > Pages : 28 > Date : 2015-08-11 > > 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-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-05 > > > 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 Wed Aug 12 06:44: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 9E1D31B2DCD for ; Wed, 12 Aug 2015 06:44:46 -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 RBG1qUkK-bk7 for ; Wed, 12 Aug 2015 06:44:44 -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 2F6FC1B2DF1 for ; Wed, 12 Aug 2015 06:44:43 -0700 (PDT) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 12 Aug 2015 16:44: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, 12 Aug 2015 16:44: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, 12 Aug 2015 16:44:41 +0300 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: ext Peter Saint-Andre - &yet , "stox@ietf.org" Thread-Topic: [Stox] I-D Action: draft-ietf-stox-7248bis-05.txt Thread-Index: AQHQ1JDlbtoFE/GCYUW/ho+AoWB7g54ILOSAgAAz/iA= Date: Wed, 12 Aug 2015 13:44:40 +0000 Message-ID: References: <20150811235301.7315.37077.idtracker@ietfa.amsl.com> <55CB4C4F.7000107@andyet.net> In-Reply-To: <55CB4C4F.7000107@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.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-05.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: Wed, 12 Aug 2015 13:44:46 -0000 Hi, Yes, it looks to me correct now. Markus > -----Original Message----- > From: stox [mailto:stox-bounces@ietf.org] On Behalf Of ext Peter Saint-An= dre - > &yet > Sent: Wednesday, August 12, 2015 4:38 PM > To: stox@ietf.org > Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-05.txt >=20 > Revisions to address feedback from Markus and Ben. >=20 > Gentlemen, does this version meet your needs? >=20 > Peter >=20 > On 8/11/15 5:53 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the SIP-TO-XMPP Working Group of the IET= F. > > > > 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-05.txt > > Pages : 28 > > Date : 2015-08-11 > > > > 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-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-7248bis-05 > > > > > > 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.i= etf.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 > > >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From nobody Thu Aug 13 01:35:54 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 5A53C1B376E for ; Thu, 13 Aug 2015 01:35:53 -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 5YTp16WCTAkJ for ; Thu, 13 Aug 2015 01:35:52 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA21B376C for ; Thu, 13 Aug 2015 01:35:51 -0700 (PDT) Received: from [192.168.1.35] (a82-94-59-122.adsl.xs4all.nl [82.94.59.122]) by mail.sipthor.net (Postfix) with ESMTPSA id A9CE116DC6BD; Thu, 13 Aug 2015 10:35:48 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9AB31AE5-0EED-4082-9725-41E4D8E15C95"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <55CB4C4F.7000107@andyet.net> Date: Thu, 13 Aug 2015 10:35:43 +0200 Message-Id: References: <20150811235301.7315.37077.idtracker@ietfa.amsl.com> <55CB4C4F.7000107@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-05.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: Thu, 13 Aug 2015 08:35:53 -0000 --Apple-Mail=_9AB31AE5-0EED-4082-9725-41E4D8E15C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FWIW, I looked at the diff and it looks good to me. On 12 Aug 2015, at 15:38, Peter Saint-Andre - &yet = wrote: > Revisions to address feedback from Markus and Ben. >=20 > Gentlemen, does this version meet your needs? >=20 > Peter >=20 > On 8/11/15 5:53 PM, internet-drafts@ietf.org wrote: >>=20 >> 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. >>=20 >> 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-05.txt >> Pages : 28 >> Date : 2015-08-11 >>=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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-stox-7248bis-05 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-7248bis-05 >>=20 >>=20 >> 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. >>=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 >>=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects --Apple-Mail=_9AB31AE5-0EED-4082-9725-41E4D8E15C95 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 iQIcBAEBCgAGBQJVzFbjAAoJEN2cyH9ENwiq4ykP/jGt8AzOQMOaiYZwzackKNsk h9p9aQgCtb9WX2GbGBJPyJj6yhp1FLHaRjDA719NKz8hqR8D4jfmTQYX0KJne8WT I6oeg8sA1H1EHVZgWMdKdzLAzMRo7S+H9r9kRVFb8qz1WY2VL2Zh5SwUkBm2NvmO SCPS6WQUgQ5mSALSPb+A+bQ9yfLh/thp9Hw6bzMd2EUYDDUDAQM5Df1nZziqiwQV I+a8zHvEkUmPNUT5EyBC8r3q9j6zRq/NBpK8dr5Tvxi0LTs7J5WMkduquUEfUT2s 7kqPD8a3zQ3oD2rWJZc8Q5YjHqiKUQ1vrfUmq6UZjucinMVZK3PQFL8wr2V7n3AM LO14G83mgqEjAHRd8Bbdb4Ldj+/8RvpK6QXS0OJyOsoKw4yxKwCU2SQYOU16+PRf ksQg0apsjlULAsypjGB2BU+MXTgP0QsUUPrh2PJN/a8S1/OZsWvoRK3oP02qaMqb tJ441bdo26ZUdZkNPjClIsfmcV69OkgFVxXgk3Uu/wfXymDK2RIyMh/6tHr3NGwn L13z1QlQK4w8qV/79bYljzkwOChGeiy6MOQ/pYcKqWr5EvE/9lfL9TfJZjcv7ITB ogPjKx80t+IJ2hWnzuAttkZjiGUBYXiNCYkmAdnjBytzcZ4uObvkzOlzY4TYB1tK q0rVQcm24Y1A250nkLN+ =ylqg -----END PGP SIGNATURE----- --Apple-Mail=_9AB31AE5-0EED-4082-9725-41E4D8E15C95--