From Markus.Isomaki@nokia.com Thu Jan 9 06:40:51 2014 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 392511AE338 for ; Thu, 9 Jan 2014 06:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.739 X-Spam-Level: X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 U7Z-T7PykNP1 for ; Thu, 9 Jan 2014 06:40:49 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DA1AE367 for ; Thu, 9 Jan 2014 06:40:48 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s09EXC3x026818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 16:33:12 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.242]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0158.002; Thu, 9 Jan 2014 14:33:12 +0000 From: To: , Thread-Topic: STOX Virtual Interim Meeting 2013-12-17 Minutes Thread-Index: Ac8NR0nFwwyfUuEiSoGQfjiUrs62pQ== Date: Thu, 9 Jan 2014 14:33:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only; x-titus-version: 3.5.9.3 x-headerinfofordlp: x-tituslabs-classificationhash-30: 2PrCjJ7f5poVv9TjWbkmkhopNxHEHLShEt0vca8Qu3P01Dug6J1biCl8FI+pIe1syMSnP6Trf3iPet5oJJVgjq4nuYh6cBR0ryb5uu2LFGrp7UPezCFfwzTJHshYCLdxPgG5efG/PEmH/zb+VuDRzhZJCboN6E8pvxp89ZOoH/ZQ0vpx7nzydYIU4iqExaLD67RZMgTfWsLIykHt65F1LZrwWL9Ng8YkkjMjy42M0F/TWhUBfKiwSBJDnoe8EXhW x-originating-ip: [10.163.29.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes 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, 09 Jan 2014 14:40:51 -0000 Hi, You can also find the minutes and other proceedings from: http://www.ietf.org/proceedings/interim/2013/12/17/stox/proceedings.html Based on the minutes there are two (open) action points (Mary already sent = her reviews): Jonathan Lennox: Review the fmtp related section in -media. Paul Kyzivat: Review the "hold" related section in -media. Jonathan, Paul: If you could do those reviews and send comments on the list= it would be very helpful to progress the specific sections in -media draft= . Thanks! Markus --- From: stox [mailto:stox-bounces@ietf.org] On Behalf Of ext Yana Stamcheva Sent: 18 December, 2013 16:57 To: stox@ietf.org Subject: [Stox] STOX Virtual Interim Meeting 2013-12-17 Recording Thanks to all the participants in the interim meeting! Below you'll find the WebEx recording of the meeting. Begin forwarded message: From: Cindy Morgan Subject: Invitation to view WebEx recording "STOX-20131217 1603-1" Date: 18 Dec 2013 15:13:03 GMT+1 To: yana@jitsi.org Reply-To: cmorgan@amsl.com I want to share the following WebEx recording with you. Click the link belo= w to play it:=20 https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&rID=3D19788772&rKey=3Db= f9fb06ac41c884e =20 STOX-20131217 1603-1=20 December 17, 2013, 9:34 am San Francisco Time=20 1 hour 28 mins=20 If you need assistance, you can contact me at cmorgan@amsl.com.=20 http://www.webex.com=20 From jonathan@vidyo.com Thu Jan 9 09:22:16 2014 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 EC8681AE4B4 for ; Thu, 9 Jan 2014 09:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] 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 C1DfYON724KA for ; Thu, 9 Jan 2014 09:22:15 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id D1D251AE4B8 for ; Thu, 9 Jan 2014 09:22:14 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/9/2014 12:22:03 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-84/SG:2 1/9/2014 12:21:59 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.782655 p=-0.975855 Source White X-Signature-Violations: 0-0-0-4042-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 1/9/2014 12:21:57 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 62168828 for stox@ietf.org; Thu, 09 Jan 2014 12:22:03 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0146.000; Thu, 9 Jan 2014 11:22:02 -0600 From: Jonathan Lennox To: "stox@ietf.org" Thread-Topic: stox-media: format parameter translation Thread-Index: AQHPDV9PVnx5eBwDn0i//6+EvMAtCQ== Date: Thu, 9 Jan 2014 17:22:02 +0000 Message-ID: <1CFAA181-4E37-42EF-A5B4-70737C697B9E@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <820258A62BDF214F8B0BB1C0D754A8A4@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Stox] stox-media: format parameter translation 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, 09 Jan 2014 17:22:16 -0000 This is the issue I brought up at the Interim -- I'll try to put it in writ= ing. The point I raised is that the stox-media draft's section on format paramet= er translation should try to focus on media types which are actually used b= y existing, deployed Jingle clients, since this is probably a relatively sm= all set. The important question is which payload formats in use by existin= g Jingle clients have SDP fmtp formats that don't follow the normal semicol= on-separated parameter model. I of course haven't done a full inventory of such payload formats, but two = that seem reasonably likely and I think should be particularly called out a= re: audio/telephone-event: RFC 4733: the fmtp contains the value of an implicit= "events" parameter. audio/red: RFC 2198, with its media type registration in RFC 3555: the fmtp= is the payload types of the encompassed formats. The RFC 3555 definition = of the actual media type parameters is weird (in an attempt to make it self= -contained), and I doubt that any Jingle client that does RED would actuall= y use it that way. So we need to figure out what any actual Jingle implemen= tations do. Does anyone have a reasonably-authoritative list of which RTP payload forma= ts are supported by existing Jingle clients? Does anyone know of any other= real-world usage of codecs that have unusual fmtp encodings? Someone on t= he call mentioned that they thought that Speex's was weird, but as far as I= can tell, it's a normal semicolon-separated encoding.= From jonathan@vidyo.com Thu Jan 9 09:31:25 2014 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 A7E791AE4D4 for ; Thu, 9 Jan 2014 09:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] 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 1PRvQf4WfDRu for ; Thu, 9 Jan 2014 09:31:24 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 73B841AE3DC for ; Thu, 9 Jan 2014 09:31:24 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/9/2014 12:31:14 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-60/SG:2 1/9/2014 12:30:59 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.783275 p=-0.976 Source White X-Signature-Violations: 0-0-0-2848-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 1/9/2014 12:30:58 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 62174612 for stox@ietf.org; Thu, 09 Jan 2014 12:31:14 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0146.000; Thu, 9 Jan 2014 11:31:13 -0600 From: Jonathan Lennox To: "stox@ietf.org" Thread-Topic: Stox-media: Should XEP-176 translations have Require: ice? Thread-Index: AQHPDWCXO0GcUwCdhEOXXqfhFzsiYw== Date: Thu, 9 Jan 2014 17:31:12 +0000 Message-ID: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <5263A5B77972C84F8E6E4BD89A40BB7B@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Stox] Stox-media: Should XEP-176 translations have Require: ice? 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, 09 Jan 2014 17:31:25 -0000 I was thinking about the issue that unlike RFC 5245, XEP-176's definition o= f ICE doesn't support fallback to a non-ICE mode. It occurred to me that SIP has a way of saying "do ICE, or fail the call": = putting a "Require: ice" SIP option tag (from RFC 5768) in the SIP INVITE. Should we recommend this? It clearly has the right semantics, and will pre= vent interop failure when a non-ICE SIP endpoint answers a XEP-176 Jingle c= all. My concern, though, is whether there are a) endpoints that implement RFC 52= 45 but not RFC 5768, or b) non-media-terminating B2BUAs that will pass ICE = parameters through, but will reject calls with Require headers they don't k= now. In either of these cases, adding this Require header would cause a ca= ll that would otherwise have worked to fail. Any thoughts, especially from folks who know the state of deployed SIP bett= er than I do?= From pkyzivat@alum.mit.edu Thu Jan 9 09:41:13 2014 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 78E8C1AE4FE for ; Thu, 9 Jan 2014 09:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_INVITATION=-2, SPF_SOFTFAIL=0.665] 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 FXWwX7zl5YUb for ; Thu, 9 Jan 2014 09:41:11 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 404AC1ADF8C for ; Thu, 9 Jan 2014 09:41:11 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id Boqx1n0031GhbT851th1Xb; Thu, 09 Jan 2014 17:41:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id Bth11n00M3ZTu2S3Tth1UB; Thu, 09 Jan 2014 17:41:01 +0000 Message-ID: <52CEDF2D.9090607@alum.mit.edu> Date: Thu, 09 Jan 2014 12:41:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: stox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389289261; bh=Xxnbl7qf0f29IGGDJjNOI2KfmE1OTWzvID6my/gTIng=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CMOScN9HRAltkvHB0KiOpRnIal0Z4i3mWXWWNP7rPuBXUizG1L3H3nVMqVH+IsQGV Rv2H88/JXzWv6o9PhUuQgu2xAAslBAMmdwdoDClbBCNhl13uhZLYSU5/fH3/pQtOJc nleSHiHmEh5FYws0sece5sylCD+r/Hl4uHI9bR7BclqgNELG20vsjx/KDhTOEEsQNW W7LdyylZfhJPDBd0sVPvFifZ7BTgvhSmuixcVGbtDpccnEVEzbiAEYnsfuVICfBpp1 kso+uN9Ml6rXWn+gvZNmtNhggF6GzHdrcq7E15F5bqH+VgaPWP74+4A59Qz5MfXfQ6 KGi72YyBMh6nA== Subject: Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes 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, 09 Jan 2014 17:41:13 -0000 As requested, I have taken a look at treatment of Hold in section 6 of draft-ietf-stox-media-02. The draft says: The same semantics are also supported by Jingle through the "senders" element and its "initiator" and "responder" values. [example to follow] In addition to these semantics however Jingle also defines a more concise way for achieving the same, which consists in sending a "hold" command within a "session-info" action: Before I can make any useful comments I need to get educated on some aspects of xmpp. (I *browsed* XEP 0166, but couldn't quickly figure this out.) Hopefully somebody can clue me in on the following: 1) I see that the "senders" element has values that correspond 1:1 with SDP sendrecv/sendonly/recvonly/inactive. Are there equivalent constraints on O/A behavior? Specifically that: Offer Permissible Answer ----- ------------------ sendrecv sendrecv/sendonly/recvonly/inactive sendonly recvonly/inactive recvonly sendonly/inactive inactive inactive 2) Are the "senders" element values semantically equivalent to the corresponding SDP attributes in their implications to how the corresponding RTP stream is used? 3)) What are the precise semantics of the "hold" command within a "session-info" action? Is it formally equivalent to "initiator" on every media session? Thanks, Paul On 1/9/14 9:33 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > You can also find the minutes and other proceedings from: > http://www.ietf.org/proceedings/interim/2013/12/17/stox/proceedings.html > > Based on the minutes there are two (open) action points (Mary already sent her reviews): > > Jonathan Lennox: Review the fmtp related section in -media. > Paul Kyzivat: Review the "hold" related section in -media. > > Jonathan, Paul: If you could do those reviews and send comments on the list it would be very helpful to progress the specific sections in -media draft. Thanks! > > Markus > > --- > > From: stox [mailto:stox-bounces@ietf.org] On Behalf Of ext Yana Stamcheva > Sent: 18 December, 2013 16:57 > To: stox@ietf.org > Subject: [Stox] STOX Virtual Interim Meeting 2013-12-17 Recording > > Thanks to all the participants in the interim meeting! > > Below you'll find the WebEx recording of the meeting. > > Begin forwarded message: > > > From: Cindy Morgan > Subject: Invitation to view WebEx recording "STOX-20131217 1603-1" > Date: 18 Dec 2013 15:13:03 GMT+1 > To: yana@jitsi.org > Reply-To: cmorgan@amsl.com > > I want to share the following WebEx recording with you. Click the link below to play it: > > https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=19788772&rKey=bf9fb06ac41c884e > > STOX-20131217 1603-1 > December 17, 2013, 9:34 am San Francisco Time > 1 hour 28 mins > > > > If you need assistance, you can contact me at cmorgan@amsl.com. > > http://www.webex.com > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From gonzalo.camarillo@ericsson.com Tue Jan 21 07:57:22 2014 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 63D051A03D9; Tue, 21 Jan 2014 07:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rsKzrrK1sKFF; Tue, 21 Jan 2014 07:57:20 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 438711A0393; Tue, 21 Jan 2014 07:57:17 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-2c-52de98dd975e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 05.C4.04853.DD89ED25; Tue, 21 Jan 2014 16:57:17 +0100 (CET) Received: from [147.214.22.241] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Tue, 21 Jan 2014 16:57:16 +0100 Message-ID: <52DE98DC.90900@ericsson.com> Date: Tue, 21 Jan 2014 16:57:16 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: , Peter Saint-Andre , Apps Discuss , , References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52B07028.4020609@dcrocker.net> In-Reply-To: <52B07028.4020609@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7dGfeCDLa0SlmsfrmCzeL3pw9s FvN6rzJbzPgzkdni/44mVotje/qZHdg8Lu08yeaxZMlPJo+5e14we3y5/JktgCWKyyYlNSez LLVI3y6BK6Nv9wTGggmJFfe7lzI2MO717mLk5JAQMJH4s3oKI4QtJnHh3nq2LkYuDiGBE4wS 6yd/YoJw1jBKLLuyG6iKg4NXQFNi71IDkAYWAVWJg33d7CA2m4CFxJZb91lAbFGBKIkD83aA DeUVEJQ4OfMJC8gcEYGVjBLvV15mB5nDLCAhcWRlEEiNsIC1xLpF69hAbCGBTImlK0+DreIU 0JG4sK0KxJQQEJfoaQSrZhbQk5hytYURwpaX2P52DjNEp7bE8mctLBMYhWYhWTwLScssJC0L GJlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIExsHBLb+NdjCe3GN/iFGag0VJnPc6 a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsY9LDPVOf9+t/7etnfT/x3Cqcrn3Zyt94ft 3Fz7teR9Q7A398/7tZP/q/s84NW/J9vNM+3bRIvDLJOKrpgZLYzqZWe503nyqtGfxfPlYriv tJvfjebZw95x9ohiMItlrcyt7e75Zl+D71r2vru+Z2Oq6PmC06aqL20zYubEXvfboH59S9SC txOUWIozEg21mIuKEwG1cXvPUQIAAA== Cc: iesg Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06 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: Tue, 21 Jan 2014 15:57:22 -0000 Hi Peter, when do you think you will get around to revising the draft per Dave's comments? Thanks for the review, Dave. Cheers, Gonzalo On 17/12/2013 4:39 PM, Dave Crocker wrote: > Only responded where it seems needed or useful... > > > > On 12/13/2013 2:47 PM, Peter Saint-Andre wrote: > >>> 1. When citing the earlier efforts, there should be something to >>> explain why the current work is expected to be more successful. >> >> Not "expected", but "is". :-) AFAIK there are no implementations of the > > I'd missed that this is based on deployed work. That is a point that > always makes writing text justifying/motivating the document quite easy: > just say that. > > >> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e., >> mapping to the abstract semantics of RFC 3860), whereas there are >> multiple implementations of the approach described here (i.e., direct >> mapping between SIP and XMPP). >> >>> That is, >>> what makes the current approach notably tractable for implementation and >>> deployment? >> >> Do you think that explaining why would improve the document? IMHO this > > I'm a fan of context and systems views, because I think it orients the > reader usefully, so the simple answer is yes. > > Whenever there is a lengthy history with alternative efforts, readers > can benefit from some context that distinguishes the current work. Not > in qualitative terms like better or worse, but in technical and > operational terms. > > Hence I think language like what's already in the document, that > distinguishes the 'architectural' difference from earlier work, but also > one that says that the current work is based on deployed industry choice. > > >> verges into developer psychology (I've got this SIP thing here and this > > >>> 5. When showing protocol examples, usually only one side of the >>> sequence is shown. For gatewaying that does interesting transforms, >>> such as this one, an example should show both the before and after >>> versions. That is, the 'native' protocol unit that was created and then >>> the one that results from the translation. >> >> I thought we'd already done that. For instance, Example 2 is the SIP >> transformation of the XMPP stanza shown in Example 1. > > Either the document didn't do it as diligently as I'm suggesting, or I > didn't understand this aspect of the document, which might be remedied > by better labeling. > > For any example that is done in a gateway and is a translation between > sip presence and xmpp presence, something simple and rigorous, such as > "before" and "after" labels to source and transformed versions, ought to > remedy this. > > > > >>> This probably raises a larger issue: How much expertise is expected of >>> someone who is implementing this or otherwise reading for deep >>> comprehension? In the extreme, they will need to have serious expertise >>> on both protocol sets. The other extreme would be a cookbook inside >>> this document, with no outside knowledge required. The document needs >>> to specify the nature and extent of the expertise required. (In fact, >>> the document seems pretty clean, in terms of explaining things, so I >>> suspect that 'fair' knowledge of one suite will suffice. But the author >>> and wg beliefs about the requirement should be made explicit.) >> >> See above. Perhaps not expert level, but significant familiarity with >> one "side" or the other. > > Just to emphasize, whatever the knowledge-level of reader that's > required, the document should make that explicit. > > I'm always a fan of making documents more accessible to wider > readership, but it's not practical to make all documents fully > accessible, especially within a suite of docs that build on each other. > > >>>> | SUBSCRIBE sip:romeo@example.net SIP/2.0 >>> >>> Later text (section 4.1) equates the label pres: with sip: and sips:. >>> Why choose sip: here? >> >> In practice, we don't see 'pres' URIs in the wild. > > Hmmm. While 'statistics' of use is a relatively fragile basis for > putting things into a spec -- since a doc can last for decades and > statistics can change -- it might be worth mentioning as the basis for > the choice in the doc. I suppose that's in the realm of giving the > reader a bit of operational insight. But definitely not an important > point. > > > >>>> Example 3: SIP accepts subscription request: >>>> >>>> | SIP/2.0 200 OK >>>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>>> | From: ;tag=ffd2 >>>> | To: ;tag=j89d >>>> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >>>> | CSeq: 234 SUBSCRIBE >>>> | Contact: >>>> | Expires: 3600 >>>> | Content-Length: 0 >>> >>> Hmmm. This appears to be the original SIP acceptance, but with no >>> separate display of it's being translated into XMPP. >> >> That is Example 5. > > Oh. It's worth making that explicit. (My tendency to get confused > reading specs is a useful canary in the tunnel, for what needs > clarifying for other readers, IMO...) > > > >>>> Example 10: SIP user subscribes to XMPP contact: >>>> >>>> | SUBSCRIBE sip:juliet@example.com SIP/2.0 >>>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>>> | From: ;tag=xfg9 >>>> | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 >>>> | Event: presence >>>> | Max-Forwards: 70 >>>> | CSeq: 263 SUBSCRIBE >>>> | Contact: >>>> | Accept: application/pidf+xml >>>> | Content-Length: 0 >>>> >>>> Notice that the "Expires" header was not included in the SUBSCRIBE >>>> request; this means that the default value of 3600 (i.e., 3600 >>>> seconds = 1 hour) applies. >>>> >>>> Upon receiving the SUBSCRIBE, the SIP server needs to determine the >>>> identity of the domain portion of the Request-URI or To header, >>>> which >>>> it does by following the procedures discussed in >>>> [I-D.ietf-stox-core]. Here we assume that the SIP server has >>>> determined that the domain is serviced by an XMPP server, that it >>> >>> >>> This seems to mean that a regular SIP server needs to be familiar with >>> technical details in a gatewaying specification?? >> >> Well, it is (IMHO) really the responsibility of a core "server" to >> implement this kind of routing functionality, but the "gateway" might >> make the determination that the remote domain uses SIP or XMPP and if >> SIP then pass it on to the SIP "server" and if not handle delivery to > > I think this matches the usual model: an unchanged server does routing > as if all participants were part of its 'native' protocol service. A > gateway translates and tries to hide any differences between two services. > > The current doc language seems confusing on this point, when it talks > about a (native) server choosing a server that is part of the other > service. > > This is a sufficiently basic point to probably warrant going into -core, > rather than here. But the language here probably therefore ought to > just be in terms of originators and recipients (or whatever generic > terminology works for presence) with an initial, simple note that > knowledge of the need for translation only resides in the gateway(s). > > But I'm not sure I mentioned another point that confused me from -core: > It shows the two types of gateways as talking to each other, but I > suspect that's not reality. FOr example, when doing SIP-XMPP, I suspect > the actual flow is: > > SIP User > SIP Server > SIP-XMPP Server > XMPP Server > XMPP User > > whereas the implication from the -core diagram and some of the language > in the spec(s) is: > > SIP User > SIP Server > SIP-XMPP Server > XMPP-SIP Server > XMPP Server > XMPP Use > > If it really is the later sequence, I don't understand why. > > > >> the remote XMPP domain. To some extent it's a matter of implementation >> where exactly the code lives to complete these functions, which is why >> draft-ietf-stox-core talks about a "SIP service" consisting of both a >> SIP "server" and a "gateway". In XMPP this translation function is often >> handled by what we call a "connection manager", but that depends a bit >> on the internal architecture of the overall "service". > > This point highlights the essential difference between a "networking > architecture" and an "implementation architecture". > > Mapping from the first to the second often permits very wide variations. > The former concerns distinct functionality that /can/ be distributed, > where the latter makes specific choices for what /is/ distributed. > > > > >>>> As described in [RFC3856], presence information about an entity is >>>> communicated by means of a SIP NOTIFY event sent from a SIP user >>>> agent to an intended recipient who is most generally referenced >>>> by an >>>> Presence URI of the form but who might be >>>> referenced by a SIP or SIPS URI of the form or >>>> . Here again we introduce the simplifying >>>> assumption that the user agent is controlled by a human user. >>> >>> I guess I'm not understanding how the nature of what is controlling the >>> agent affects anything in this document. Might be worth explaining >>> that. >> >> A "presentity" doesn't have to be a human -- it could be a bot, a >> device, or some other automated entity. People related more to human >> users. > > Sure, but when reading the doc, it felt as if the reference to this > issue was relevant to functionality. I'd expect the issue to be raised > once in an Intro and then avoided later by use of a neutral term like > user or presentity or whatever. > > > >>>> Note the following regarding these mappings: >>>> >>>> 1. Only a presence stanza that lacks a 'type' attribute or whose >>> >>> presence -> XMPP presence >> >> Stanzas are an XMPP artifact. But yes. > > Choosing the level of semantic redundancy in the language is always a > balancing act. In a gatewaying document that will be reader by folks > likely to be expert in only one half of the necessary technologies, I'd > be inclined towards more redundancy, to reduce likelihood of > misunderstanding... > > > >>>> 'type' attribute has a value of "unavailable" SHOULD be >>>> mapped by >>>> an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are >>>> the only presence stanzas that represent notifications. >>>> 2. The PIDF schema defines the tuple 'id' attribute as having a >>>> datatype of "xs:ID"; because this datatype is more restrictive >>>> than the "xs:string" datatype for XMPP resourceparts (in >>>> particular, a number is not allowed as the first character >>>> of an >>>> ID), it is RECOMMENDED to prepend the resourcepart with >>>> "ID-" or >>>> some other alphabetic string when mapping from XMPP to SIP. >>>> 3. This mapping is OPTIONAL. >>> >>> What does that mean? This sort of mapping is usually the essence of >>> gatewaying semantics. How can interoperability tolerate it's being >>> optional? >> >> In XMPP, the 'id' attribute is not usually included in presence stanzas, >> and nothing is lost if it's ignored. But I'll give it a bit more thought. >> >>>> 4.3. SIP to XMPP >>>> >>>> When Romeo changes his presence, his SIP user agent generates a SIP >>> >>> Romeo is doing SIP? And Juliet does XMPP? >> >> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at >> least for me. > > So why isn't the other side Steve or Sid or... > > Nevermind... > > > >>> So, SIP is more macho than XMPP??? >> >> Have you configured a SIP client lately? ;-) >> >> But seriously, the Romeo and Juliet scenarios enable me to use a male > > The word seriously is entirely out of scope for this segment. Or at > least, it certainly was when I started it... > > d/ > From stpeter@stpeter.im Wed Jan 22 10:44:04 2014 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 691451A03CF for ; Wed, 22 Jan 2014 10:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 5fIDxZRSkJ-B for ; Wed, 22 Jan 2014 10:44:03 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5F1A03B6 for ; Wed, 22 Jan 2014 10:44:03 -0800 (PST) Received: from rcdn-vpn-client-10-89-0-179.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0A07B40067; Wed, 22 Jan 2014 11:44:01 -0700 (MST) Message-ID: <52E01171.3060102@stpeter.im> Date: Wed, 22 Jan 2014 11:44:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: stox@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] Post-WGLC review: draft-ietf-stox-im-06 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 Jan 2014 18:44:04 -0000 Hi Mary, thanks for the review and my apologies for the delayed reply. On 12/24/13 1:22 PM, Mary Barnes wrote: > HI all, > > I've reviewed the document and believe it's ready to progress with a > couple of minor clarification/nit fixes required. > > - Section 1, 1st bullet. RFC 3428 was not developed in the SIMPLE WG. > It was a product of the old SIP WG. I would suggest to reword that > bullet as follows: > Various extensions to the Session Initiation Protocol ([RFC3261]) > for instant messaging, including the MESSAGE method extension > [RFC3428]. Agreed. > - Related to my previous comment, there shouldn't be any references to > a SIMPLE-XMPP Gateway, which is used widely in the document, although > there are some places where SIP-XMPP is used, which is more correct. > > - All occurrences of "SIMPLE Server" should be changed to "SIP Server" The reason we use the term SIMPLE here is that a base SIP server or gateway would not necessarily have awareness of the instant messaging extensions to SIP, and "SIMPLE server" is less wordy than "IM-aware SIP server". But if the latter is more accurate then I'm happy to make that change. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jan 22 11:07:24 2014 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 978AC1A01B7 for ; Wed, 22 Jan 2014 11:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, 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 1EvFWwy9rmZW for ; Wed, 22 Jan 2014 11:07:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F27E21A01AF for ; Wed, 22 Jan 2014 11:07:22 -0800 (PST) Received: from rcdn-vpn-client-10-89-0-179.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4CFD240067; Wed, 22 Jan 2014 12:07:22 -0700 (MST) Message-ID: <52E016E9.4070206@stpeter.im> Date: Wed, 22 Jan 2014 12:07:21 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "stox@ietf.org" References: <52E016D4.3010709@stpeter.im> In-Reply-To: <52E016D4.3010709@stpeter.im> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52E016D4.3010709@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] Fwd: Re: Post-WGLC Review: draft-ietf-stox-chat 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 Jan 2014 19:07:24 -0000 Forgot to reply to all. Peter -------- Original Message -------- Subject: Re: [Stox] Post-WGLC Review: draft-ietf-stox-chat Date: Wed, 22 Jan 2014 12:07:00 -0700 From: Peter Saint-Andre To: Mary Barnes And thanks for this review, too. On 12/24/13 1:57 PM, Mary Barnes wrote: > HI all, > > I've reviewed the document and believe it's ready to progress with a few > changes/minor nits fixed: > > 1) Section 3. The text related to F6 uses the term MSRP user agent. > That term isn't used at all in RFC 4975, in particular since an MSRP > user doesn't have to be a SIP User agent. I would suggest to just > reword as follows: > OLD > Romeo can then send a reply using his MSRP user agent. > NEW > Romeo can then send a reply using his MSRP client. Makes sense. > 2) Section 4. The numbered references to Fx are off by one starting > with Example 16:, which should be F7 and not F8. F9 should be F8 and > F10 should be F9. Good catch! > 3) Section 9. RFC 4975 should be referenced for security for MSRP > rather than RFC 3428. Yes. > 4) References. RFC 3428 should be removed as a reference as MSRP/RFC > 4975 is entirely independent of the MESSAGE/RFC 3428. You are right. There are also some stray words about SIMPLE instead of MSRP, so I'll fix those at the same time. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jan 22 18:38:21 2014 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 A83FE1A0365; Wed, 22 Jan 2014 18:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, 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 tVf5oXnmydmF; Wed, 22 Jan 2014 18:38:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF71A01D6; Wed, 22 Jan 2014 18:38:18 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 423F5400AD; Wed, 22 Jan 2014 19:38:16 -0700 (MST) Message-ID: <52E08096.5070307@stpeter.im> Date: Wed, 22 Jan 2014 19:38:14 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Apps Discuss , draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> In-Reply-To: <52AB8E69.7070906@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06 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 Jan 2014 02:38:21 -0000 Hi Dave, sorry about the delayed processing of your feedback. Life has gotten in the way here. Further comments and proposed text inline. On 12/13/2013 03:47 PM, Peter Saint-Andre wrote: > Hi Dave, thank you for the review. Comments inline. I have not yet > proposed text for the issues you raise, because that will take more time. > > On 12/11/13 10:34 PM, Dave Crocker wrote: >> >> G'day. >> >> I have been selected as the Applications Area Review Team reviewer for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> >> >> Review of: Interworking between the Session Initiation Protocol (SIP) >> and the >> Extensible Messaging and Presence Protocol (XMPP): Presence >> I-D: draft-ietf-stox-presence-06 >> >> Reviewer: D. Crocker >> Review date: 12 Dec 13 >> >> >> >> Summary: >> >> XMPP and SIP both have deployed versions of instant messaging and >> presence. The current draft is part of a set of specifications that >> define a gateway capability between the the two services. In >> particular, the current draft specifies the translation mechanism >> between the presence mechanisms used by SIP and XMPP. >> >> The draft is well-structured and the text is mostly clear. For an >> implementer already familiar with the details of the two services and >> the basics of the gatewaying specified here, the document probably is >> sufficient -- although responses to some of the detailed comments, >> below, might to turn out to show that a bit more work is needed. However >> at the most, any technical improvements that might be needed will be >> minor. And I expect these to more in the nature of clarifying language >> than of changing bits over the wire. >> >> However for a reader who is new to the topic, the document needs to be >> clearer and sometimes more complete. >> >> Specific changes or concerns: >> >> 1. When citing the earlier efforts, there should be something to >> explain why the current work is expected to be more successful. > > Not "expected", but "is". :-) AFAIK there are no implementations of the > approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e., > mapping to the abstract semantics of RFC 3860), whereas there are > multiple implementations of the approach described here (i.e., direct > mapping between SIP and XMPP). > >> That is, >> what makes the current approach notably tractable for implementation and >> deployment? > > Do you think that explaining why would improve the document? IMHO this > verges into developer psychology (I've got this SIP thing here and this > XMPP thing there, let me see how I can make them work as easily as > possible without venturing off into abstract semantic stuff). Text adjusted to read: One approach to helping ensure interworking between these protocols is to map each protocol to the abstract semantics described in [RFC3860]; although that is the approach taken by both [RFC3922] and [I-D.ietf-simple-cpim-mapping], to the best of our knowledge that approach has never been implemented. The approach taken in this document is to directly map semantics from one protocol to another (i.e., from SIP/SIMPLE to XMPP and vice-versa), since that is how existing systems solve the interworking problem. See also http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-09.txt for relevant changes to the "core" STOX document. >> 2. The document is not clear about the prerequisites for reading >> this draft. What must the reader already know in depth? What must they >> have at least superficial knowledge of? I suspect that, in particular, >> they need deep familiarity with stox-core. > > At the very least. Also RFC 3261, RFC 3856, RFC 6120, and RFC 6121. > (Note: the total page count of those RFCs is 621.) The specifications > normatively referenced by RFC 3856 are also relevant. Added the following section: 2. Intended Audience The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). We assume that readers are familiar with the core specifications for both SIP [RFC3261] and XMPP [RFC6120], with the base document for this series [I-D.ietf-stox-core], and with the following presence-related specifications: o A Presence Event Package for the Session Initiation Protocol [RFC3856] o Presence Information Data Format (PIDF) [RFC3863] o Extensible Messaging and Presence Protocol: Instant Messaging and Presence [RFC6121] o SIP-Specific Event Notification [RFC6665] >> 3. Saying that terms are taken from a substantial number of other >> documents, and then merely citing the documents in their entirety, is >> not helpful to the reader, unless the reader is required to be deeply >> familiar with those documents. > > I do think it's required. See text posted above. >> If that's what this document requires, >> say that. If it's not, I suggest listing terms explicitly and >> indicating what document they are drawn from. >> >> 4. As the architecture diagram in Section 3 of stox-core shows, this >> service has at least separate actors Actually I think it actually has at >> least 6, which that diagram probably should show explicitly. The six are: >> >> a. SIP user >> b. SIP server >> c. SIP-XMPP gateway >> d. XMPP-SIP gateway >> e. XMPP server >> f. XMPP user >> >> In any event, the specification needs to be very diligent to >> carefully identify each actor involved in an activity and the >> interaction between actors. The current document uses language that >> often left me wondering such things as who was the target of the action. >> >> Much of this would be aided by some form of protocol sequence >> diagrams, to show who does what and in what order. > > I'll review the document again with these comments in mind. Your > suggestion of sequence diagrams is a good one. I've added sequence diagrams. >> 5. When showing protocol examples, usually only one side of the >> sequence is shown. For gatewaying that does interesting transforms, >> such as this one, an example should show both the before and after >> versions. That is, the 'native' protocol unit that was created and then >> the one that results from the translation. > > I thought we'd already done that. For instance, Example 2 is the SIP > transformation of the XMPP stanza shown in Example 1. I've made the example descriptions a bit clearer in this regard. >> Detailed Comments: >> >> >>> Table of Contents >> >> >> Nicely organized and concise TOC [ie, document structure). >> >> >> >>> 1. Introduction >> ... >>> One approach to helping ensure interworking between these protocols >>> is to map each protocol to the abstract semantics described in >>> [RFC3860]; that is the approach taken by both [RFC3922] and >>> [I-D.ietf-simple-cpim-mapping]. The approach taken in this document >>> is to directly map semantics from one protocol to another (i.e., from >>> SIP/SIMPLE to XMPP and vice-versa). >> >> This begs the obvious question: Why? What was wrong with the previous >> approach? > > No one implemented it. The running code all takes the direct gatewaying > approach. > >> The purpose of the question is not for criticizing prior work but to >> understand the expected benefit of the approach taken in the current >> work. What are the function, or OA&M differences produced through this >> new approach, that are expected to be helpful? > > These documents describe what people do in the field, what works and > what doesn't, etc. We're not saying that other approaches are bad or > infeasible. See previous note. >>> The architectural assumptions underlying such direct mappings are >>> provided in [I-D.ietf-stox-core], including mapping of addresses and >>> error conditions. The mappings specified in this document cover >>> basic presence functionality. Mapping of more advanced functionality >>> (e.g., so-called "rich presence") is out of scope for this document. >>> >>> SIP and XMPP differ significantly in their presence subscription >>> models, since SIP subscriptions are short-lived (requiring relatively >>> frequent refreshes even during a presence session) whereas XMPP >>> subscriptions last across presence sessions until they are explicitly >>> cancelled. This document provides suggestions for bridging the gap >>> between these very different models. >>> >>> >>> 2. Terminology >>> >>> A number of terms used here are explained in [RFC3261], [RFC3856], >>> [RFC6120], and [RFC6121]. >> >> This sentence probably implies that the current draft should not be read >> in the absence of familiarity with all 4 of those RFCs. I suggest some >> sort of explicit statement about how much prior knowledge is needed for >> understanding the current draft, and where to get that knowledge. > > Agreed. See note above about the new Section 2. >> In purely mechanical terms, the problem with the above sentence is that >> it means that when the reader sees a term they don't understand, they >> have to run around to four different documents looking for definitions. >> This mostly ensures reader frustration, for everyone but experts. >> >> The cleanest fix for this is to list terms and where they are defined. >> The other, usual fix is to indeed say that the reader must be familiar >> with those other documents before reading this one. (sigh.) > > I think these documents are for experts. In all likelihood, members of > the target audience already have a SIP implementation and need to > connect it to the XMPP network, or vice-versa. I don't think someone who > is not familiar with either SIP or XMPP (or both) is going to hack up a > gateway. There are much more rewarding tasks one might choose. > > To your point, we need to say that. > >>> 3.1. Overview >> ... >>> As described in [RFC6121], XMPP presence subscriptions are managed >>> using XMPP presence stanzas of type "subscribe", "subscribed", >>> "unsubscribe", and "unsubscribed". The main subscription states are >>> "none" (neither the user nor the contact is subscribed to the other's >>> presence information), "from" (the user has a subscription from the >>> contact), "to" (the user has a subscription to the contact's presence >>> information), and "both" (both user and contact are subscribed to >>> each other's presence information). >> >> Nit: for technical documents, lists like the above should be shown in >> list format. It really does help for quick comprehension. > > Will fix. Done. >>> As described in [RFC3856], SIP presence subscriptions are managed >>> through the use of SIP SUBSCRIBE events sent from a SIP user agent to >>> an intended recipient who is most generally referenced by a Presence >>> URI of the form but who might be referenced by a >>> SIP or SIPS URI of the form or . >>> >>> The subscription models underlying XMPP and SIP are quite different. >>> For instance, XMPP presence subscriptions are long-lived (indeed >>> permanent if not explicitly cancelled), whereas SIP presence >>> subscriptions are short-lived (the default time-to-live of a SIP >>> presence subscription is 3600 seconds, as specified in Section 6.4 of >>> [RFC3856]). These differences are addressed below. >> >> The text that follows this 'addresses' the differences in terms of >> specifying how to handle specific differences. >> >> What's missing -- but I think would aid for the framework of this >> document's effort -- is for the above "For instance" to instead be >> expanded into a detailed statement of what the differences are, separate >> from the later text that says how to deal with the differences. > > That "for instance" is the main thing, so you're right that it needs to > be described in more detail. Changed to: The subscription models underlying XMPP and SIP differ mainly in the fact that XMPP presence subscriptions are long-lived (indeed permanent if not explicitly cancelled, so that a subscription need never be refreshed during any given presence "session"), whereas SIP presence subscriptions are short-lived (the default time-to-live of a SIP presence subscription is 3600 seconds, as specified in Section 6.4 of [RFC3856], so that a subscription needs to be explicitly refreshed if it will have the appearance of being permanent or even of lasting as for the duration of a presence "session"). This disparity has implications for the handling of subscription cancellations in either direction and, from the SIP side, subscription refreshes. [much text snipped where we have areas of agreement] Thanks again for the review! I'll post a revised I-D soon. Peter From internet-drafts@ietf.org Wed Jan 22 18:48:33 2014 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 3BCD51A018A; Wed, 22 Jan 2014 18:48:33 -0800 (PST) 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 7r2-vQDPKMij; Wed, 22 Jan 2014 18:48:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C92631A0136; Wed, 22 Jan 2014 18:48:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123024829.29671.15565.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 18:48:29 -0800 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-presence-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: Thu, 23 Jan 2014 02:48:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Proto= col (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presen= ce Authors : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-presence-07.txt Pages : 28 Date : 2014-01-22 Abstract: This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-presence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-presence-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-presence-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 stpeter@stpeter.im Wed Jan 22 18:50:35 2014 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 3D6251A0132 for ; Wed, 22 Jan 2014 18:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, 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 V7R0JjD_kDQP for ; Wed, 22 Jan 2014 18:50:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 425C71A00E7 for ; Wed, 22 Jan 2014 18:50:30 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7995E400AD; Wed, 22 Jan 2014 19:50:29 -0700 (MST) Message-ID: <52E08374.3030600@stpeter.im> Date: Wed, 22 Jan 2014 19:50:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: stox@ietf.org References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52B07028.4020609@dcrocker.net> <52DE98DC.90900@ericsson.com> In-Reply-To: <52DE98DC.90900@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06 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 Jan 2014 02:50:35 -0000 Done! On 01/21/2014 08:57 AM, Gonzalo Camarillo wrote: > Hi Peter, > > when do you think you will get around to revising the draft per Dave's > comments? > > Thanks for the review, Dave. > > Cheers, > > Gonzalo > > On 17/12/2013 4:39 PM, Dave Crocker wrote: >> Only responded where it seems needed or useful... >> >> >> >> On 12/13/2013 2:47 PM, Peter Saint-Andre wrote: >> >>>> 1. When citing the earlier efforts, there should be something to >>>> explain why the current work is expected to be more successful. >>> >>> Not "expected", but "is". :-) AFAIK there are no implementations of the >> >> I'd missed that this is based on deployed work. That is a point that >> always makes writing text justifying/motivating the document quite easy: >> just say that. >> >> >>> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e., >>> mapping to the abstract semantics of RFC 3860), whereas there are >>> multiple implementations of the approach described here (i.e., direct >>> mapping between SIP and XMPP). >>> >>>> That is, >>>> what makes the current approach notably tractable for implementation and >>>> deployment? >>> >>> Do you think that explaining why would improve the document? IMHO this >> >> I'm a fan of context and systems views, because I think it orients the >> reader usefully, so the simple answer is yes. >> >> Whenever there is a lengthy history with alternative efforts, readers >> can benefit from some context that distinguishes the current work. Not >> in qualitative terms like better or worse, but in technical and >> operational terms. >> >> Hence I think language like what's already in the document, that >> distinguishes the 'architectural' difference from earlier work, but also >> one that says that the current work is based on deployed industry choice. >> >> >>> verges into developer psychology (I've got this SIP thing here and this >> >> >>>> 5. When showing protocol examples, usually only one side of the >>>> sequence is shown. For gatewaying that does interesting transforms, >>>> such as this one, an example should show both the before and after >>>> versions. That is, the 'native' protocol unit that was created and then >>>> the one that results from the translation. >>> >>> I thought we'd already done that. For instance, Example 2 is the SIP >>> transformation of the XMPP stanza shown in Example 1. >> >> Either the document didn't do it as diligently as I'm suggesting, or I >> didn't understand this aspect of the document, which might be remedied >> by better labeling. >> >> For any example that is done in a gateway and is a translation between >> sip presence and xmpp presence, something simple and rigorous, such as >> "before" and "after" labels to source and transformed versions, ought to >> remedy this. >> >> >> >> >>>> This probably raises a larger issue: How much expertise is expected of >>>> someone who is implementing this or otherwise reading for deep >>>> comprehension? In the extreme, they will need to have serious expertise >>>> on both protocol sets. The other extreme would be a cookbook inside >>>> this document, with no outside knowledge required. The document needs >>>> to specify the nature and extent of the expertise required. (In fact, >>>> the document seems pretty clean, in terms of explaining things, so I >>>> suspect that 'fair' knowledge of one suite will suffice. But the author >>>> and wg beliefs about the requirement should be made explicit.) >>> >>> See above. Perhaps not expert level, but significant familiarity with >>> one "side" or the other. >> >> Just to emphasize, whatever the knowledge-level of reader that's >> required, the document should make that explicit. >> >> I'm always a fan of making documents more accessible to wider >> readership, but it's not practical to make all documents fully >> accessible, especially within a suite of docs that build on each other. >> >> >>>>> | SUBSCRIBE sip:romeo@example.net SIP/2.0 >>>> >>>> Later text (section 4.1) equates the label pres: with sip: and sips:. >>>> Why choose sip: here? >>> >>> In practice, we don't see 'pres' URIs in the wild. >> >> Hmmm. While 'statistics' of use is a relatively fragile basis for >> putting things into a spec -- since a doc can last for decades and >> statistics can change -- it might be worth mentioning as the basis for >> the choice in the doc. I suppose that's in the realm of giving the >> reader a bit of operational insight. But definitely not an important >> point. >> >> >> >>>>> Example 3: SIP accepts subscription request: >>>>> >>>>> | SIP/2.0 200 OK >>>>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>>>> | From: ;tag=ffd2 >>>>> | To: ;tag=j89d >>>>> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >>>>> | CSeq: 234 SUBSCRIBE >>>>> | Contact: >>>>> | Expires: 3600 >>>>> | Content-Length: 0 >>>> >>>> Hmmm. This appears to be the original SIP acceptance, but with no >>>> separate display of it's being translated into XMPP. >>> >>> That is Example 5. >> >> Oh. It's worth making that explicit. (My tendency to get confused >> reading specs is a useful canary in the tunnel, for what needs >> clarifying for other readers, IMO...) >> >> >> >>>>> Example 10: SIP user subscribes to XMPP contact: >>>>> >>>>> | SUBSCRIBE sip:juliet@example.com SIP/2.0 >>>>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>>>> | From: ;tag=xfg9 >>>>> | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 >>>>> | Event: presence >>>>> | Max-Forwards: 70 >>>>> | CSeq: 263 SUBSCRIBE >>>>> | Contact: >>>>> | Accept: application/pidf+xml >>>>> | Content-Length: 0 >>>>> >>>>> Notice that the "Expires" header was not included in the SUBSCRIBE >>>>> request; this means that the default value of 3600 (i.e., 3600 >>>>> seconds = 1 hour) applies. >>>>> >>>>> Upon receiving the SUBSCRIBE, the SIP server needs to determine the >>>>> identity of the domain portion of the Request-URI or To header, >>>>> which >>>>> it does by following the procedures discussed in >>>>> [I-D.ietf-stox-core]. Here we assume that the SIP server has >>>>> determined that the domain is serviced by an XMPP server, that it >>>> >>>> >>>> This seems to mean that a regular SIP server needs to be familiar with >>>> technical details in a gatewaying specification?? >>> >>> Well, it is (IMHO) really the responsibility of a core "server" to >>> implement this kind of routing functionality, but the "gateway" might >>> make the determination that the remote domain uses SIP or XMPP and if >>> SIP then pass it on to the SIP "server" and if not handle delivery to >> >> I think this matches the usual model: an unchanged server does routing >> as if all participants were part of its 'native' protocol service. A >> gateway translates and tries to hide any differences between two services. >> >> The current doc language seems confusing on this point, when it talks >> about a (native) server choosing a server that is part of the other >> service. >> >> This is a sufficiently basic point to probably warrant going into -core, >> rather than here. But the language here probably therefore ought to >> just be in terms of originators and recipients (or whatever generic >> terminology works for presence) with an initial, simple note that >> knowledge of the need for translation only resides in the gateway(s). >> >> But I'm not sure I mentioned another point that confused me from -core: >> It shows the two types of gateways as talking to each other, but I >> suspect that's not reality. FOr example, when doing SIP-XMPP, I suspect >> the actual flow is: >> >> SIP User >> SIP Server >> SIP-XMPP Server >> XMPP Server >> XMPP User >> >> whereas the implication from the -core diagram and some of the language >> in the spec(s) is: >> >> SIP User >> SIP Server >> SIP-XMPP Server >> XMPP-SIP Server >> XMPP Server >> XMPP Use >> >> If it really is the later sequence, I don't understand why. >> >> >> >>> the remote XMPP domain. To some extent it's a matter of implementation >>> where exactly the code lives to complete these functions, which is why >>> draft-ietf-stox-core talks about a "SIP service" consisting of both a >>> SIP "server" and a "gateway". In XMPP this translation function is often >>> handled by what we call a "connection manager", but that depends a bit >>> on the internal architecture of the overall "service". >> >> This point highlights the essential difference between a "networking >> architecture" and an "implementation architecture". >> >> Mapping from the first to the second often permits very wide variations. >> The former concerns distinct functionality that /can/ be distributed, >> where the latter makes specific choices for what /is/ distributed. >> >> >> >> >>>>> As described in [RFC3856], presence information about an entity is >>>>> communicated by means of a SIP NOTIFY event sent from a SIP user >>>>> agent to an intended recipient who is most generally referenced >>>>> by an >>>>> Presence URI of the form but who might be >>>>> referenced by a SIP or SIPS URI of the form or >>>>> . Here again we introduce the simplifying >>>>> assumption that the user agent is controlled by a human user. >>>> >>>> I guess I'm not understanding how the nature of what is controlling the >>>> agent affects anything in this document. Might be worth explaining >>>> that. >>> >>> A "presentity" doesn't have to be a human -- it could be a bot, a >>> device, or some other automated entity. People related more to human >>> users. >> >> Sure, but when reading the doc, it felt as if the reference to this >> issue was relevant to functionality. I'd expect the issue to be raised >> once in an Intro and then avoided later by use of a neutral term like >> user or presentity or whatever. >> >> >> >>>>> Note the following regarding these mappings: >>>>> >>>>> 1. Only a presence stanza that lacks a 'type' attribute or whose >>>> >>>> presence -> XMPP presence >>> >>> Stanzas are an XMPP artifact. But yes. >> >> Choosing the level of semantic redundancy in the language is always a >> balancing act. In a gatewaying document that will be reader by folks >> likely to be expert in only one half of the necessary technologies, I'd >> be inclined towards more redundancy, to reduce likelihood of >> misunderstanding... >> >> >> >>>>> 'type' attribute has a value of "unavailable" SHOULD be >>>>> mapped by >>>>> an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are >>>>> the only presence stanzas that represent notifications. >>>>> 2. The PIDF schema defines the tuple 'id' attribute as having a >>>>> datatype of "xs:ID"; because this datatype is more restrictive >>>>> than the "xs:string" datatype for XMPP resourceparts (in >>>>> particular, a number is not allowed as the first character >>>>> of an >>>>> ID), it is RECOMMENDED to prepend the resourcepart with >>>>> "ID-" or >>>>> some other alphabetic string when mapping from XMPP to SIP. >>>>> 3. This mapping is OPTIONAL. >>>> >>>> What does that mean? This sort of mapping is usually the essence of >>>> gatewaying semantics. How can interoperability tolerate it's being >>>> optional? >>> >>> In XMPP, the 'id' attribute is not usually included in presence stanzas, >>> and nothing is lost if it's ignored. But I'll give it a bit more thought. >>> >>>>> 4.3. SIP to XMPP >>>>> >>>>> When Romeo changes his presence, his SIP user agent generates a SIP >>>> >>>> Romeo is doing SIP? And Juliet does XMPP? >>> >>> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at >>> least for me. >> >> So why isn't the other side Steve or Sid or... >> >> Nevermind... >> >> >> >>>> So, SIP is more macho than XMPP??? >>> >>> Have you configured a SIP client lately? ;-) >>> >>> But seriously, the Romeo and Juliet scenarios enable me to use a male >> >> The word seriously is entirely out of scope for this segment. Or at >> least, it certainly was when I started it... >> >> d/ >> > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From dhc@dcrocker.net Wed Jan 22 19:00:39 2014 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 726031A00D9; Wed, 22 Jan 2014 19:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 tOVvLkQXHGSW; Wed, 22 Jan 2014 19:00:37 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B618F1A00AC; Wed, 22 Jan 2014 19:00:37 -0800 (PST) Received: from [192.168.200.211] (rrcs-74-62-19-234.west.biz.rr.com [74.62.19.234]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0N30XaN005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 19:00:36 -0800 Message-ID: <52E085C0.5060202@dcrocker.net> Date: Wed, 22 Jan 2014 19:00:16 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Saint-Andre , Apps Discuss , draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52E08096.5070307@stpeter.im> In-Reply-To: <52E08096.5070307@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 22 Jan 2014 19:00:37 -0800 (PST) Cc: iesg Subject: Re: [Stox] Review of: draft-ietf-stox-presence-06 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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 Jan 2014 03:00:39 -0000 On 1/22/2014 6:38 PM, Peter Saint-Andre wrote: > Text adjusted to read: > > One approach to helping ensure interworking between these protocols > is to map each protocol to the abstract semantics described in > [RFC3860]; although that is the approach taken by both [RFC3922] and > [I-D.ietf-simple-cpim-mapping], to the best of our knowledge that > approach has never been implemented. The approach taken in this > document is to directly map semantics from one protocol to another > (i.e., from SIP/SIMPLE to XMPP and vice-versa), since that is how > existing systems solve the interworking problem. wfm. >>> 2. The document is not clear about the prerequisites for reading >>> this draft. What must the reader already know in depth? What must they >>> have at least superficial knowledge of? I suspect that, in particular, >>> they need deep familiarity with stox-core. >> >> At the very least. Also RFC 3261, RFC 3856, RFC 6120, and RFC 6121. >> (Note: the total page count of those RFCs is 621.) The specifications >> normatively referenced by RFC 3856 are also relevant. > > Added the following section: > > 2. Intended Audience > > The documents in this series are intended for use by software > developers who have an existing system based on one of these > technologies (e.g., SIP), and would like to enable communication from > that existing system to systems based on the other technology (e.g., > XMPP). We assume that readers are familiar with the core > specifications for both SIP [RFC3261] and XMPP [RFC6120], with the > base document for this series [I-D.ietf-stox-core], and with the > following presence-related specifications: > > o A Presence Event Package for the Session Initiation Protocol > [RFC3856] > > o Presence Information Data Format (PIDF) [RFC3863] > > o Extensible Messaging and Presence Protocol: Instant Messaging and > Presence [RFC6121] > > o SIP-Specific Event Notification [RFC6665] Well, that's certainly clear and thorough... if onerous. But yeah, probably right. >>>> As described in [RFC3856], SIP presence subscriptions are managed >>>> through the use of SIP SUBSCRIBE events sent from a SIP user agent to >>>> an intended recipient who is most generally referenced by a Presence >>>> URI of the form but who might be referenced by a >>>> SIP or SIPS URI of the form or . >>>> >>>> The subscription models underlying XMPP and SIP are quite different. >>>> For instance, XMPP presence subscriptions are long-lived (indeed >>>> permanent if not explicitly cancelled), whereas SIP presence >>>> subscriptions are short-lived (the default time-to-live of a SIP >>>> presence subscription is 3600 seconds, as specified in Section 6.4 of >>>> [RFC3856]). These differences are addressed below. >>> >>> The text that follows this 'addresses' the differences in terms of >>> specifying how to handle specific differences. >>> >>> What's missing -- but I think would aid for the framework of this >>> document's effort -- is for the above "For instance" to instead be >>> expanded into a detailed statement of what the differences are, separate >>> from the later text that says how to deal with the differences. >> >> That "for instance" is the main thing, so you're right that it needs to >> be described in more detail. > > Changed to: > > The subscription models underlying XMPP and SIP differ mainly in the > fact that XMPP presence subscriptions are long-lived (indeed > permanent if not explicitly cancelled, so that a subscription need > never be refreshed during any given presence "session"), whereas SIP > presence subscriptions are short-lived (the default time-to-live of a > SIP presence subscription is 3600 seconds, as specified in > Section 6.4 of [RFC3856], so that a subscription needs to be > explicitly refreshed if it will have the appearance of being > permanent or even of lasting as for the duration of a presence > "session"). This disparity has implications for the handling of > subscription cancellations in either direction and, from the SIP > side, subscription refreshes. wfm. > Thanks again for the review! I'll post a revised I-D soon. ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Thu Jan 23 07:03:58 2014 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 CCD551A000C; Thu, 23 Jan 2014 07:03:58 -0800 (PST) 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 2RKHHphbNAhX; Thu, 23 Jan 2014 07:03:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1A1A0004; Thu, 23 Jan 2014 07:03:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123150357.13407.24039.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 07:03:57 -0800 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-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: Thu, 23 Jan 2014 15:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Proto= col (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instan= t Messaging Authors : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-07.txt Pages : 12 Date : 2014-01-23 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-im-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 internet-drafts@ietf.org Thu Jan 23 07:05:22 2014 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 7DB541A0013; Thu, 23 Jan 2014 07:05:22 -0800 (PST) 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 foaMd7RDx52Z; Thu, 23 Jan 2014 07:05:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2BB1A0004; Thu, 23 Jan 2014 07:05:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123150519.14691.6718.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 07:05:19 -0800 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-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: Thu, 23 Jan 2014 15:05:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Proto= col (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to= -One Text Chat Sessions Authors : Peter Saint-Andre Salvatore Loreto Filename : draft-ietf-stox-chat-05.txt Pages : 17 Date : 2014-01-23 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-chat-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 stpeter@stpeter.im Fri Jan 31 14:25:47 2014 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 AF7D51A04DF for ; Fri, 31 Jan 2014 14:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 VDMqGW-dQWCA for ; Fri, 31 Jan 2014 14:25:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 931051A04E8 for ; Fri, 31 Jan 2014 14:25:45 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6EF6D40067; Fri, 31 Jan 2014 15:25:41 -0700 (MST) Message-ID: <52EC22E4.5040700@stpeter.im> Date: Fri, 31 Jan 2014 15:25:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: stox@ietf.org References: <20131212182625.7247.96401.idtracker@ietfa.amsl.com> <52B09E17.3030707@goodadvice.pages.de> In-Reply-To: <52B09E17.3030707@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-02.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: Fri, 31 Jan 2014 22:25:47 -0000 On 12/17/13, 10:55 AM, Philipp Hancke wrote: >> Abstract: >> This document defines a bi-directional protocol mapping for use by >> gateways that enable the exchange of media signalling messages >> between systems that implement the Jingle extensions to the >> Extensible Messaging and Presence Protocol (XMPP) and those that >> implement the Session Initiation Protocol (SIP). >> > > A couple of comments, I just had some time (90 minutes :-)) to review this: Thanks, Philipp. Sorry about the delay in replying - as you might be aware I've had quite a bit happening since the interim meeting. ;-) > Section 5.1: > the syntax and semantics of element are defined > in [XEP-0167] > > nit: 0167 defines the semantics of elements in the > urn:xmpp:...:rtp:1 namespace. Giving 0167 again as an example for other > description types in the next sentence is somewhat odd. Agreed on all that. Let's use XEP-0234 (Jingle File Transfer) as the second example. > 'name' > maps to a=mid: from RFC 5888 -- not sure if that is required for the > basic usecase. > 'profile' > 0167 does (in it's current version) not have a profile. This was removed > in Version 0.23 (2008-07-31). > > the 'action' attribute [...] nine allowable values > No, it's 15. The missing ones are content-reject, description-info, > security-info, transport-reject, transport-replace, transport-accept. > > All the transport- are unused. Right, those are for fallback scenarios and such. > description-info is for suggested > application parameters (width, height), so we dont need it either. > security-info is only used for xtls, so unused, too. At the core/general level, I agree. > I am not sure about > content-reject. As you know, that's used by the recipient to decline the addition of a new content type to the session (e.g., the other party wants to add video to an audio-only session). Potentially we could map this to a SIP 415 Unsupported Media Type response. However, this wouldn't round-trip very well because the stox-core document says to map SIP 415 to XMPP whereas Jingle content-reject is not an stanza-level error but a Jingle-level response. > Section 6: > senders can also have a value of "none" which maps to a=inactive. That > is only in XEP-0166 and not in 0167. We'll add that to the first table in Section 5 (and number the tables while we're at it). > Actually, Jingle has a cool message for hold which is content-modify > (which only modifies senders). Why bother with two hold mechanisms when > you can have three :-) Sure, the more the merrier. :P Is senders='none' implemented for hold functionality? We've been trying to define only what is in general use. > Section 9: > s/comas/commas/ That might have been a Freudian slip on the part of the authors. ;-) > XEP-0177 doesn't define . 0167 defines which is > what you describe (and it does so in a wrong way, spec bug). Are you saying there is a spec bug in XEP-0167 or in the stox-media I-D? (The Jingle specs need a general round of cleanup, so I would not be surprised about the former and you probably already mentioned this to me months ago.) Naturally, this element works only for RTP communications, not other Jingle applications (say, file transfer). So we'll mention that in the text. > I think DTMF is the relevant example for bullet #3 (example from RFC 4733) > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > Saul : I think I disagree with your comment about name being required by > the xep's schema (which isn't normative anyway), both are required. > My take (after some discussions in jingle@) is that 'name' should be > left empty and you should put the stuff to 'value'. Yes, that seems better. Notice how RFC 4733 says the following things represent the same information: (1) audio/telephone-event;events="0-15,66,70";rate="8000" and (2) m=audio 12346 RTP/AVP 100 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15,66,70 Although (1) says events='', the events name doesn't appear in (2). So putting the stuff in the (and empty name) seems reasonable. > Section 10: > This section actually concerns me. Jingle is based on full jids > typically. So in order to forward a call from a SIP entity to an xmpp > entity, the gateway needs to determine which full jid to send to. > So it either has to have a presence subscription or can use presence > decloaking (XEP-0276; deferred because of inactivity but works nicely). > If there are multiple possible resources, the gateway needs to decide, > where to route the call. The text here talks about the XMPP 'from' address that the gateway will place on provisional responses received from the SIP side. Since there might be multiple responses, we're saying to ignore the GRUU and make believe that the JID-equivalent of the SIP sender is a bare JID, not a full JID. I'm not yet convinced that this is the best we can do in the SIP to XMPP direction, but it might be... > As Emil mentioned, some people (i.e. me) are considering using > for the session-initiate which would allow an xmppish way of > forking (Jonathan: want to help out? :-)), but that is not ready yet. Yes, that might be helpful. > Section 11.1: > the candidate in the example should probably have an id (at least where > the 0177 schema is concerned which is not normative). It needs to have a 'component' attribute too, per XEP-0177. > It might be worth noting (elsewhere?) that Jingle and SIP do ice > restarts differently WRT to the generation parameter. Agreed, we have an open issue to add some text to Section 5.4. > The last example contains a reasoncode='no-error'. I am not sure what > old version of jingle this comes from, these days it's done with > Noted, will fix. > other issues: > routing of (for the jingle->sip call-a-telephone-number usecase) > that was raised at the end of the meeting: > this should go to the bare JID. Semantically, this means "don't route it > to a client, server handles it". Here, the 'server' is handling it. I'll need to listen to the audio recording in order to know the context here. > Peter: during the call I made a note "more disco#info examples", I think > this was based on a comment by Markus about capability negotiation. I > hope I remember the actual context when seeing the minutes. As in all of these mapping specs, we try not to reply too much on discovering the capabilities of other entities, since SIP doesn't have any reliable facilities for that. But if you remember the context, let us know. :-) Thanks again, Peter