From Ofir.Roth@nice.com Wed Dec 5 01:36:58 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA3A21F8BB2 for ; Wed, 5 Dec 2012 01:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk6ZPxWcqWCH for ; Wed, 5 Dec 2012 01:36:58 -0800 (PST) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5E21F8C0B for ; Wed, 5 Dec 2012 01:36:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,377,1352066400"; d="scan'208";a="5695656" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 5 Dec 2012 11:36:54 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 5 Dec 2012 11:36:53 +0200 Thread-Topic: Metadata version indicator consensus? Thread-Index: Ac3MzWW9f8PW/dTwSciO4LVM9GZy3wAA3CXwAX5+vAA= Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF01371ABF@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF01371ABF@MCHP04MSX.global-ad.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:36:58 -0000 Hi, In regarding to the Andrew's statement below:=20 > I also got the impression that there was a body of opinion that the=20 > version should NOT be automatically incremented on a per draft basis. I think that there is a concrete need for such support in versioning per dr= aft - especially in the few first drafts where there were major changes bet= ween drafts.=20 The fact is that there are implementations out there which are not planned = to be aligned with the formal/final RFC version.=20 Thanks, Ofir. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, November 27, 2012 8:58 PM To: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? Hi All, I noticed a typo in the first sentence it should have read: Having just read through the thread again with the possible exception of Ma= ry I think that everyone who contributed to the discussion is in favor of s= ome kind of version number for metadata. Does anyone disagree with that? Sorry about that I think the rest of the text is ok. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: 27 November 2012 18:31 > To: siprec@ietf.org > Subject: [siprec] Metadata version indicator consensus? >=20 > Hi All, >=20 > Having just read through the thread again and with the possible=20 > exception of Mary I don't think that everyone who contributed to the=20 > discussion is in favour of some kind of version number for metadata. > Does anyone disagree with that? >=20 > I also got the impression that there was a body of opinion that the=20 > version should NOT be automatically incremented on a per draft basis. >=20 > So I think we may be able to get consensus to use the mechanism as=20 > used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail-=20 > archive/web/siprec/current/msg03532.html. In which he stated: >=20 > "This led the XSF to use a protocol versioning scheme currently in use=20 > (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and=20 > increments with each protocol-breaking change. It meant that=20 > different teams understood to what level another had implemented to,=20 > and adoption of an I-D phase document to an RFC phase document meant=20 > no churn simply because the XSF accepted the work". >=20 > So for SIPREC we would use something like=20 > "urn:ietf:params:xml:ns:recording:0" starting with the next update to=20 > the draft and then only update the version number if we doing=20 > something that brakes the backwards compatibility. >=20 > Could people please let us know if they agree or disagree with this. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Dec 5 02:00:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846821F85F5 for ; Wed, 5 Dec 2012 02:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbJPRxZfsFqi for ; Wed, 5 Dec 2012 02:00:35 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 281B121F86A7 for ; Wed, 5 Dec 2012 02:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3633; q=dns/txt; s=iport; t=1354701634; x=1355911234; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=3VByJoGIoC5SpehCOxF7yMQHhvaOBYTSlEEjTqBW+Yk=; b=PRJejNyK4sdPcMC8Iz099qn40+f0KUt/9I4vPn3m09Q1trALy1Af16NW r26OrIawK6Sapo0C+IyzvJXmARiBnzrrgLdFb2s+x0R0BX3WMtGwOcWie 8FISg804NHsOZj6nuVTOh1J0Sui3zhhmgJ4fWv8hDPDB5qR/nK9WSgDH3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABQav1CtJXG//2dsb2JhbABEg2u6QxZzgh4BAQEDAQEBATc0EAcGAQgRBAEBCxQJLgsUCQgCBAESCAGIAQYHBcFmjDcbg0VhA6E9hQ2CcoFsNQ X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="146554849" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 05 Dec 2012 10:00:33 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB5A0Xpe015246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 10:00:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 04:00:32 -0600 From: "Ram Mohan R (rmohanr)" To: Ofir Roth , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07A== Date: Wed, 5 Dec 2012 10:00:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <998BFD9540DE78418ECF32052840A100@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:00:35 -0000 > On 05/12/12 3:06 PM, "Ofir Roth" wrote: >Hi, > >In regarding to the Andrew's statement below: >> I also got the impression that there was a body of opinion that the >> version should NOT be automatically incremented on a per draft basis. > >I think that there is a concrete need for such support in versioning per >draft - especially in the few first drafts where there were major changes >between drafts. Are you asking about having metadata versions for the older versions (10 and below) of the draft ? I am afraid that may not be possible. From ver 11 we would have this versioning numbers assuming we agree on what is being discussed in this thread. Ram =20 >=20 >The fact is that there are implementations out there which are not >planned to be aligned with the formal/final RFC version. > >Thanks, >Ofir. > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Tuesday, November 27, 2012 8:58 PM >To: siprec@ietf.org >Subject: Re: [siprec] Metadata version indicator consensus? > >Hi All, > >I noticed a typo in the first sentence it should have read: > >Having just read through the thread again with the possible exception of >Mary I think that everyone who contributed to the discussion is in favor >of some kind of version number for metadata. Does anyone disagree with >that? > >Sorry about that I think the rest of the text is ok. > >Regards >Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: 27 November 2012 18:31 >> To: siprec@ietf.org >> Subject: [siprec] Metadata version indicator consensus? >>=20 >> Hi All, >>=20 >> Having just read through the thread again and with the possible >> exception of Mary I don't think that everyone who contributed to the >> discussion is in favour of some kind of version number for metadata. >> Does anyone disagree with that? >>=20 >> I also got the impression that there was a body of opinion that the >> version should NOT be automatically incremented on a per draft basis. >>=20 >> So I think we may be able to get consensus to use the mechanism as >> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- >> archive/web/siprec/current/msg03532.html. In which he stated: >>=20 >> "This led the XSF to use a protocol versioning scheme currently in use >> (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and >> increments with each protocol-breaking change. It meant that >> different teams understood to what level another had implemented to, >> and adoption of an I-D phase document to an RFC phase document meant >> no churn simply because the XSF accepted the work". >>=20 >> So for SIPREC we would use something like >> "urn:ietf:params:xml:ns:recording:0" starting with the next update to >> the draft and then only update the version number if we doing >> something that brakes the backwards compatibility. >>=20 >> Could people please let us know if they agree or disagree with this. >>=20 >> Regards >> Andy (SIPREC Co-Chair). >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From Ofir.Roth@nice.com Wed Dec 5 02:16:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014921F85D1 for ; Wed, 5 Dec 2012 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW+ITTc7dREb for ; Wed, 5 Dec 2012 02:16:17 -0800 (PST) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 794AD21F84EA for ; Wed, 5 Dec 2012 02:16:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,377,1352066400"; d="scan'208";a="5696565" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 5 Dec 2012 12:16:15 +0200 From: Ofir Roth To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Wed, 5 Dec 2012 12:16:13 +0200 Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07JgJ/Rxg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:16:17 -0000 Hi Ram,=20 Why is it not possible? Thanks, Ofir. =20 -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Wednesday, December 05, 2012 12:01 PM To: Ofir Roth; siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? > On 05/12/12 3:06 PM, "Ofir Roth" wrote: >Hi, > >In regarding to the Andrew's statement below: >> I also got the impression that there was a body of opinion that the=20 >> version should NOT be automatically incremented on a per draft basis. > >I think that there is a concrete need for such support in versioning=20 >per draft - especially in the few first drafts where there were major=20 >changes between drafts. Are you asking about having metadata versions for the older versions (10 an= d below) of the draft ? I am afraid that may not be possible. From ver 11 we would have this versioning numbers assuming we agree on what is being= discussed in this thread. Ram =20 >=20 >The fact is that there are implementations out there which are not=20 >planned to be aligned with the formal/final RFC version. > >Thanks, >Ofir. > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >Behalf Of Hutton, Andrew >Sent: Tuesday, November 27, 2012 8:58 PM >To: siprec@ietf.org >Subject: Re: [siprec] Metadata version indicator consensus? > >Hi All, > >I noticed a typo in the first sentence it should have read: > >Having just read through the thread again with the possible exception=20 >of Mary I think that everyone who contributed to the discussion is in=20 >favor of some kind of version number for metadata. Does anyone disagree=20 >with that? > >Sorry about that I think the rest of the text is ok. > >Regards >Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: 27 November 2012 18:31 >> To: siprec@ietf.org >> Subject: [siprec] Metadata version indicator consensus? >>=20 >> Hi All, >>=20 >> Having just read through the thread again and with the possible=20 >> exception of Mary I don't think that everyone who contributed to the=20 >> discussion is in favour of some kind of version number for metadata. >> Does anyone disagree with that? >>=20 >> I also got the impression that there was a body of opinion that the=20 >> version should NOT be automatically incremented on a per draft basis. >>=20 >> So I think we may be able to get consensus to use the mechanism as=20 >> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail-=20 >> archive/web/siprec/current/msg03532.html. In which he stated: >>=20 >> "This led the XSF to use a protocol versioning scheme currently in=20 >> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and=20 >> increments with each protocol-breaking change. It meant that=20 >> different teams understood to what level another had implemented to,=20 >> and adoption of an I-D phase document to an RFC phase document meant=20 >> no churn simply because the XSF accepted the work". >>=20 >> So for SIPREC we would use something like=20 >> "urn:ietf:params:xml:ns:recording:0" starting with the next update to=20 >> the draft and then only update the version number if we doing=20 >> something that brakes the backwards compatibility. >>=20 >> Could people please let us know if they agree or disagree with this. >>=20 >> Regards >> Andy (SIPREC Co-Chair). >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Dec 5 08:10:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79621F8CE8 for ; Wed, 5 Dec 2012 08:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F0ciySCt8gM for ; Wed, 5 Dec 2012 08:10:12 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 52C7021F8CDD for ; Wed, 5 Dec 2012 08:10:04 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id XocZ1k0010bG4ec55sA37Q; Wed, 05 Dec 2012 16:10:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id XsA31k00R3ZTu2S3PsA3td; Wed, 05 Dec 2012 16:10:03 +0000 Message-ID: <50BF71DA.8090702@alum.mit.edu> Date: Wed, 05 Dec 2012 11:10:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: siprec@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=1354723803; bh=oRKfsJfTNCMQ37L5o7YArFndUxnGBKV8C8sEIHWiVpE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fvc79hud4jkilA7CJ+x9E/kc7S/B+do2FZL/+k5+f1UsrZJIrmVgXBequO2+TNgcE f8xnnAiYoqP0YsccbjUpCPEziyVXPD6qZX5cUy7Cobk8wQ19uaY5LAZgUNqnyhmrxV x+b3LjzioSMn3rTUQ2GHgpvTiB6gYulD7vVp4EXACXGbtopSpojZI32NK9vG0wcFl6 HfFhNWPVI8AON1xSxmJ6DAswgh3FSpvRhKWVOvEbf3Jll2+Gz2/z+sIYdDXzEwDAF9 StRADZFVM9yfvPXDWUwv7NnySNUBzxaH8gdl2riVExOx1fZFX4dnfoALhtj5ky5282 Ps8l6uDvOiorQ== Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:10:13 -0000 On 12/5/12 5:16 AM, Ofir Roth wrote: > Hi Ram, > > Why is it not possible? It would require rewriting history? Specifically, changing the name of the schema (or anything about it) would require a new draft. And in any case this should be about interoperating with implementations that already exist. Nobody should be creating a *new* implementation to an obsolete draft. Thanks, Paul > Thanks, > Ofir. > > > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Wednesday, December 05, 2012 12:01 PM > To: Ofir Roth; siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > >> On 05/12/12 3:06 PM, "Ofir Roth" wrote: > >> Hi, >> >> In regarding to the Andrew's statement below: >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >> >> I think that there is a concrete need for such support in versioning >> per draft - especially in the few first drafts where there were major >> changes between drafts. > > Are you asking about having metadata versions for the older versions (10 and below) of the draft ? I am afraid that may not be possible. From ver > 11 we would have this versioning numbers assuming we agree on what is being discussed in this thread. > > Ram > >> >> The fact is that there are implementations out there which are not >> planned to be aligned with the formal/final RFC version. >> >> Thanks, >> Ofir. >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Tuesday, November 27, 2012 8:58 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indicator consensus? >> >> Hi All, >> >> I noticed a typo in the first sentence it should have read: >> >> Having just read through the thread again with the possible exception >> of Mary I think that everyone who contributed to the discussion is in >> favor of some kind of version number for metadata. Does anyone disagree >> with that? >> >> Sorry about that I think the rest of the text is ok. >> >> Regards >> Andy >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: 27 November 2012 18:31 >>> To: siprec@ietf.org >>> Subject: [siprec] Metadata version indicator consensus? >>> >>> Hi All, >>> >>> Having just read through the thread again and with the possible >>> exception of Mary I don't think that everyone who contributed to the >>> discussion is in favour of some kind of version number for metadata. >>> Does anyone disagree with that? >>> >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >>> >>> So I think we may be able to get consensus to use the mechanism as >>> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- >>> archive/web/siprec/current/msg03532.html. In which he stated: >>> >>> "This led the XSF to use a protocol versioning scheme currently in >>> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and >>> increments with each protocol-breaking change. It meant that >>> different teams understood to what level another had implemented to, >>> and adoption of an I-D phase document to an RFC phase document meant >>> no churn simply because the XSF accepted the work". >>> >>> So for SIPREC we would use something like >>> "urn:ietf:params:xml:ns:recording:0" starting with the next update to >>> the draft and then only update the version number if we doing >>> something that brakes the backwards compatibility. >>> >>> Could people please let us know if they agree or disagree with this. >>> >>> Regards >>> Andy (SIPREC Co-Chair). >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partha@parthasarathi.co.in Wed Dec 5 08:19:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D721F8CB2 for ; Wed, 5 Dec 2012 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUe5WXYdam-q for ; Wed, 5 Dec 2012 08:19:37 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB4B21F8CCA for ; Wed, 5 Dec 2012 08:19:37 -0800 (PST) Received: from userPC (unknown [122.179.44.151]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 45B331908185; Wed, 5 Dec 2012 16:19:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1354724376; bh=mfl/Td0jYGO7YYVpOXA+azEAWis+qGNmfcYduV6lwhI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U1WbeX8LLyE/+lGAHvy2HCUfdxlvCYAvoPRDHhr28D/Yn7Wx5S6HmPvo1Vs6fqja+ Pj3mw2X1bTc1ELGF6Z8/ouiGcCB2FB3p2aGqqVm6vkIIoA9MfK23GU7+XiaGzsMrB4 mXEpXjy7MabV+zkjD0/I/SFlBIa4YltyDo9s4lUc= From: "Parthasarathi R" To: "'Ofir Roth'" , "'Ram Mohan R \(rmohanr\)'" , References: In-Reply-To: Date: Wed, 5 Dec 2012 21:49:27 +0530 Message-ID: <000301cdd304$4fcb0ed0$ef612c70$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07JgJ/RxggABgR5A= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0202.50BF7418.0176, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:19:41 -0000 Ofir, It is not possible to change the published draft XML schema. IMO, it is not required to change the XML schema for each upcoming draft also. In case there is a change in the XML schema, the version shall be incremented. I agree with you that the initial version is not required to be "0", please let me know how abt starting the value with "1". Apart from this, > >The fact is that there are implementations out there which are not >planned to be aligned with the formal/final RFC version. > Your above statement was my initial concern because the market leader implement the draft and claim for the (SIPREC) compliance which forces other vendors to implement the draft version as well as RFC version in the reality. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, December 05, 2012 3:46 PM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? Hi Ram, Why is it not possible? Thanks, Ofir. -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] Sent: Wednesday, December 05, 2012 12:01 PM To: Ofir Roth; siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? > On 05/12/12 3:06 PM, "Ofir Roth" wrote: >Hi, > >In regarding to the Andrew's statement below: >> I also got the impression that there was a body of opinion that the >> version should NOT be automatically incremented on a per draft basis. > >I think that there is a concrete need for such support in versioning >per draft - especially in the few first drafts where there were major >changes between drafts. Are you asking about having metadata versions for the older versions (10 and below) of the draft ? I am afraid that may not be possible. From ver 11 we would have this versioning numbers assuming we agree on what is being discussed in this thread. Ram > >The fact is that there are implementations out there which are not >planned to be aligned with the formal/final RFC version. > >Thanks, >Ofir. > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >Behalf Of Hutton, Andrew >Sent: Tuesday, November 27, 2012 8:58 PM >To: siprec@ietf.org >Subject: Re: [siprec] Metadata version indicator consensus? > >Hi All, > >I noticed a typo in the first sentence it should have read: > >Having just read through the thread again with the possible exception >of Mary I think that everyone who contributed to the discussion is in >favor of some kind of version number for metadata. Does anyone disagree >with that? > >Sorry about that I think the rest of the text is ok. > >Regards >Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: 27 November 2012 18:31 >> To: siprec@ietf.org >> Subject: [siprec] Metadata version indicator consensus? >> >> Hi All, >> >> Having just read through the thread again and with the possible >> exception of Mary I don't think that everyone who contributed to the >> discussion is in favour of some kind of version number for metadata. >> Does anyone disagree with that? >> >> I also got the impression that there was a body of opinion that the >> version should NOT be automatically incremented on a per draft basis. >> >> So I think we may be able to get consensus to use the mechanism as >> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- >> archive/web/siprec/current/msg03532.html. In which he stated: >> >> "This led the XSF to use a protocol versioning scheme currently in >> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and >> increments with each protocol-breaking change. It meant that >> different teams understood to what level another had implemented to, >> and adoption of an I-D phase document to an RFC phase document meant >> no churn simply because the XSF accepted the work". >> >> So for SIPREC we would use something like >> "urn:ietf:params:xml:ns:recording:0" starting with the next update to >> the draft and then only update the version number if we doing >> something that brakes the backwards compatibility. >> >> Could people please let us know if they agree or disagree with this. >> >> Regards >> Andy (SIPREC Co-Chair). >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From simon.farrow@stancilcorp.com Wed Dec 5 10:39:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D141721F8431 for ; Wed, 5 Dec 2012 10:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyqsfb05PYGL for ; Wed, 5 Dec 2012 10:39:43 -0800 (PST) Received: from mail46.atl.registeredsite.com (mail46.atl.registeredsite.com [209.237.134.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5B08F21F842E for ; Wed, 5 Dec 2012 10:39:43 -0800 (PST) Received: from mymail.myregisteredsite.com (wmailnode1a.webmail.web.com [209.237.134.166]) by mail46.atl.registeredsite.com (8.12.11.20060308/8.12.11) with SMTP id qB5IO8S9021244 for ; Wed, 5 Dec 2012 13:24:08 -0500 Received: (qmail 32253 invoked by uid 80); 5 Dec 2012 18:39:41 -0000 Received: from unknown (HELO VOXSTORSERVER) (simon.farrow@stancilcorp.com@65.244.196.81) by wmailnode1a.mymail.myregisteredsite.com with ESMTPA; 5 Dec 2012 18:39:41 -0000 From: "Simon Farrow" To: "'Ram Mohan R \(rmohanr\)'" , References: Date: Wed, 5 Dec 2012 10:35:52 -0800 Organization: Stancil Corporation Message-ID: <5930422A50B54579887730EB836079A9@VOXSTORSERVER> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001B_01CDD2D4.4DBB9090" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07JgKhRlA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [siprec] Metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: simon.farrow@stancilcorp.com List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:39:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01CDD2D4.4DBB9090 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01CDD2D4.4DBE0190" ------=_NextPart_001_001C_01CDD2D4.4DBE0190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ram I copied the schema from section 8 from the draft-ieft-siprec-metadata-10.txt file (copy included in the text file siprec-metadata-10.txt). I got some namespace errors I ran xsd.exe over it. I modified it so xsd.exe now works and I have included it (siprec-metadata-10-SF.txt) as attachment. The salient points are The tns was missing on recording (and other types) type e.g. A couple of xs: were missing from datetime. I appreciate there are a couple of ways of achieving the same results but I have included mine as a starting point in creating a standardized schema. Simon Farrow Stancil Corporation 2644 South Croddy Way Santa Ana CA 92704 http://www.stancilcorp.com simon.farrow@stancilcorp.com 714-546-2002 ext 4311 ------=_NextPart_001_001C_01CDD2D4.4DBE0190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ram

I copied the = schema from=20 section 8 from the draft-ieft-siprec-metadata-10.txt file (copy included = in the=20 text file siprec-metadata-10.txt). I got some namespace errors I ran = xsd.exe=20 over it. I modified it so xsd.exe now works and I have included it=20 (siprec-metadata-10-SF.txt) as attachment.

The salient points=20 are

The tns was missing on = recording (and=20 other types) type e.g. <xs:element name=3D"recording"=20 type=3D"tns:recording"/>

A couple of xs: were = missing from=20 datetime.

I appreciate there are a couple of ways of achieving = the same=20 results but I have included mine as a starting point in creating a=20 standardized schema.


Simon Farrow
Stancil = Corporation
2644=20 South Croddy Way
Santa Ana
CA 92704
http://www.stancilcorp.com
simon.farrow@stancilcorp.com
714-546-2002 ext=20 4311
 

------=_NextPart_001_001C_01CDD2D4.4DBE0190-- ------=_NextPart_000_001B_01CDD2D4.4DBB9090 Content-Type: text/plain; name="siprec-metadata-10.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="siprec-metadata-10.txt" ------=_NextPart_000_001B_01CDD2D4.4DBB9090 Content-Type: text/plain; name="siprec-metadata-10-SF.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="siprec-metadata-10-SF.txt" ------=_NextPart_000_001B_01CDD2D4.4DBB9090-- From eckelcu@cisco.com Wed Dec 5 11:13:24 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2F21F8C3F for ; Wed, 5 Dec 2012 11:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ7X0x+hZv5X for ; Wed, 5 Dec 2012 11:13:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D873821F8C14 for ; Wed, 5 Dec 2012 11:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6116; q=dns/txt; s=iport; t=1354734804; x=1355944404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TZUR9+/sH0ML6Zv3w8/Ofif8j8GNdQ9XAfsV/T+p0lM=; b=h37NP6Nm5ehjJJGgF3jyis2HjtQ+2J0tPBsFTb7BvOFHMY7etCZeV6AJ UuM7yjxXzCmGln+GredXmisjE1ogkNH9TOUe/aL3bsopqnToEEiajuSdk Ga1zTBSFizjS0Lqf4UcLyo62fiB3ei8t5whLgYe8LPw0Y+rMUVux8PS0A o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAACbv1CtJXG8/2dsb2JhbAA7CQ6+FhZzgh4BAQEEAQEBNzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCIgHAQzCXgSMNxKDTmEDklCTeoI1PYFlJBg X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149820387" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2012 19:13:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB5JDNWk020433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 19:13:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 13:13:22 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAz4PeAAFcHzOAAAa+9MAANaNmAAAolb6D//9FNAP/4nihQ Date: Wed, 5 Dec 2012 19:13:22 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046D3C4A@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <50B64B4D.40709@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CDF85@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828046CE010@xmb-aln-x08.cisco.com> <50B8F8A9.1080407@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CE0CC@xmb-aln-x08.cisco.com> <50B91594.1060909@alum.mit.edu> In-Reply-To: <50B91594.1060909@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] security considerations for protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:13:25 -0000 Hi Paul, I don't disagree that something better than transitive trust is desirable; = however, I don't think Digest authentication really helps. Connected Identi= ty does seem useful, but adding requirements around it seems troublesome at= this point to me. P-Asserted-Identity relies on transitive trust, so I don= 't think it makes things any better. I'd like to hear from those with deployment experience what they do and wha= t would work for them.=20 Cheers, Charles =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, November 30, 2012 12:23 PM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] security considerations for protocol draft >=20 > On 11/30/12 2:32 PM, Charles Eckel (eckelcu) wrote: > > I am leaning back toward my original proposal, of dropping the discussi= on > about digest authentication entirely and relying on TLS. For cases in whi= ch > there is an intermediary, transitive trust comes into play. If an SRS or = SRC > wants to use digest authentication, it can, but we do not need to say > anything specific about it in SIPREC. >=20 > I don't see how transitive trust would work in typical cases. There is > no guarantee that your call to the SRS hasn't been redirected to someone > else. >=20 > At a minimum, connected identity (RFC4916) might be of *some* help to > ensure you got who you intended to get. Getting an identity assertion, > via Identity (RFC4474) or P-Asserted-Identity (RFC3325) would be > stronger. (But I have no evidence that 4474 is deployed.) >=20 > I expect if we don't have something reasonably robust to recommend then > we will have trouble with security review. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Friday, November 30, 2012 10:19 AM > >> To: Charles Eckel (eckelcu) > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] security considerations for protocol draft > >> > >> On 11/30/12 1:02 PM, Charles Eckel (eckelcu) wrote: > >>> Thinking about this more, I'm still a bit dubious of the value of thi= s. > >>> For the general case in which the SRC is initiating the RS, the SRS = can > >> challenge the INVITE from the SRC with a 401 in order to force the SRC= to > >> authenticate itself to the SRS. However, we state later on that is rea= lly > more > >> important for the SRS to authentication itself to the SRC. The Digest > >> authentication mechanism can be used by the SRC for this in the case o= f > SRS > >> initiated RSs, but not for the general case. Am I missing something ag= ain? > >> > >> I think it is good as far as it goes. (An SRS is likely to not want to > >> do recording for everybody who comes along.) > >> > >> But what you say, together with what I said, does raise a question of > >> whether we actually have an adequate mechanism for the SRC to > >> authenticate the SRS. We may need to have a further discussion about > that. > >> > >> Is it plausible that we require a direct connection without > >> intermediaries? (Probably not.) > >> > >> I wish this had come up sooner, rather than now. :-( > >> > >> Thanks, > >> Paul > >> > >>> Thanks, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf > >>>> Of Charles Eckel (eckelcu) > >>>> Sent: Friday, November 30, 2012 9:08 AM > >>>> To: Paul Kyzivat; siprec@ietf.org > >>>> Subject: Re: [siprec] security considerations for protocol draft > >>>> > >>>> Good point. Thanks for clarifying. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf > >>>>> Of Paul Kyzivat > >>>>> Sent: Wednesday, November 28, 2012 9:35 AM > >>>>> To: siprec@ietf.org > >>>>> Subject: Re: [siprec] security considerations for protocol draft > >>>>> > >>>>> On 11/27/12 5:49 PM, Charles Eckel (eckelcu) wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I am in the process of updating some sections of the protocol draf= t > per > >>>> the > >>>>> conclusions reached at IETF 85. In working on the security > >> considerations, I > >>>>> ran into a couple issues. > >>>>>> > >>>>>> First, section 12.1 Authentication and Authorization, reads as > follows: > >>>>>> > >>>>>> The recording session reuses the SIP mechanism to challenge > >> requests > >>>>>> that are based on HTTP authentication. The mechanism relies= on > 401 > >>>>>> and 407 SIP responses as well as other SIP header fields for > carrying > >>>>>> challenges and credentials. > >>>>>> > >>>>>> At the transport level, the recording session uses TLS > authentication > >>>>>> to validate the authenticity of the SRC and SRS. The SRC an= d SRS > >>>>>> MUST implement TLS mutual authentication for establishing th= e > >>>>>> recording session, and whether the SRC/SRS chooses to use > >>>>>> authentication is a deployment decision. > >>>>>> > >>>>>> If using mutual TLS authentication, what is the purpose of the dig= est > >>>>> authentication? It seems to me the paragraph on digest > authentication > >>>>> should be removed. Does anyone disagree? > >>>>> > >>>>> TLS authentication is hop by hop. Digest authentication is e2e. > >>>>> > >>>>> *If* there are no intermediaries between the SRC and SRS then > perhaps > >>>>> digest authentication is unnecessary. But I don't think it is even > >>>>> possible to determine if this situation holds. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>> > > > > From pkyzivat@alum.mit.edu Wed Dec 5 11:50:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4D621F8C72 for ; Wed, 5 Dec 2012 11:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txd36Zn-+0wc for ; Wed, 5 Dec 2012 11:50:52 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF0B21F8C64 for ; Wed, 5 Dec 2012 11:50:50 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id XnXu1k0040xGWP855vqqE3; Wed, 05 Dec 2012 19:50:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Xvqq1k00A3ZTu2S3Yvqq8C; Wed, 05 Dec 2012 19:50:50 +0000 Message-ID: <50BFA599.3000708@alum.mit.edu> Date: Wed, 05 Dec 2012 14:50:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <50B64B4D.40709@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CDF85@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828046CE010@xmb-aln-x08.cisco.com> <50B8F8A9.1080407@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CE0CC@xmb-aln-x08.cisco.com> <50B91594.1060909@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046D3C4A@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046D3C4A@xmb-aln-x08.cisco.com> 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=1354737050; bh=7QmGuP4X4gSfaEmIBEYNpppricxOmv1UH082O3T+O1U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F5SDF8LeEsVN1sttnQDOf+ffRzFMIH3/dMeQtIVAMVo5qHB2PsWlVN5aakhFk96Ig 6p1EW0Xb91dEOnEu2S30cHLLspDVbjALZWUP4w4mfISmpD/uF+XRUzavreaXd0WQP3 wSPlzIjV7x/8MxlfZ57n+nSGsRcJTHe/H+G0dws3ozqjBnfB5bvG0AOdLSOQB7gVJN Z5ZcNtKYqb7/ECTePbVpo8+tkVlae/pJn0THwGUYzup4gZoDdSrbSXU9CEkbDJQjg4 4WwtJttGmf3jpKlK/2LVylWo/MxCWFaNKshmj6R2OKuCCqp3QaMzmlUbvc+59QEkNK BG6UJZyH4ix1g== Cc: "siprec@ietf.org" Subject: Re: [siprec] security considerations for protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:50:53 -0000 On 12/5/12 2:13 PM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > I don't disagree that something better than transitive trust is desirable; however, I don't think Digest authentication really helps. It could help if it was deployed and used. It would require that SRCs (assuming they are the initiators) be configured with a password. > Connected Identity does seem useful, but adding requirements around it seems troublesome at this point to me. It we required it, then it might indeed be a problem for some. But we could make it mandatory to implement, optional to use. And offer it as one of several alternatives for meeting the security requirement. > P-Asserted-Identity relies on transitive trust, so I don't think it makes things any better. It does require transitive trust. But it still can make things better. It at least ensures that, based on trust, you are talking to who you called, rather than the possibility that this was forwarded to a different UA than expected. Perhaps we could say that the SRC MUST/SHOULD verify that it is talking to the intended SRS via one of a list of techniques. I have two concerns here: - as a user of phones, and caller of call centers, I would like some assurance that when my calls are recorded, that those recordings are secure. - I expect that this will get a very thorough security review. I would prefer to get this nailed down now rather than invite objections by the security reviewers. > I'd like to hear from those with deployment experience what they do and what would work for them. Yes, that would be good. But I fear that in most cases people just don't worry about it at all. Thanks, Paul From eckelcu@cisco.com Wed Dec 5 13:35:14 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8361121F8CB8 for ; Wed, 5 Dec 2012 13:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYpLnf+APFKz for ; Wed, 5 Dec 2012 13:35:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9985221F871A for ; Wed, 5 Dec 2012 13:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2439; q=dns/txt; s=iport; t=1354743312; x=1355952912; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eJbn0LlIpIX+acB0i2F2GMTSNk19B9fqFJ7LJoOBgT8=; b=A3E3nYymITMCwnUCT19hLDEfE05Gl7kq4QvHCsQojXTXKgcBR1gkcsSz cGeDFDrtjBev1DsldI0KnxJWqJOT+u56CvTPOs8wzHjrNJqdILwIrgQA+ T582NUDanfUz4YA30r16wkT1fNcnbYCGFB2a9ubUCWFsPjFo7d5ayUxn9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIO8v1CtJV2Y/2dsb2JhbAA7CQ6+FhZzgh4BAQEDATo/BQcEAgEIDgMEAQEBCg4GCQcyFAkIAgQOBQiIAgUBwl2MNxKBCoJEYQOmSoI1PYIh X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="146831673" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Dec 2012 21:35:12 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB5LZCFu029344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 21:35:12 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 15:35:11 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAz4PeAAFcHzOAAAa+9MAANaNmAAAolb6D//9FNAP/4nihQgA80lYCAAEkpwA== Date: Wed, 5 Dec 2012 21:35:10 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046D3E7B@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <50B64B4D.40709@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CDF85@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828046CE010@xmb-aln-x08.cisco.com> <50B8F8A9.1080407@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CE0CC@xmb-aln-x08.cisco.com> <50B91594.1060909@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046D3C4A@xmb-aln-x08.cisco.com> <50BFA599.3000708@alum.mit.edu> In-Reply-To: <50BFA599.3000708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] security considerations for protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:35:14 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, December 05, 2012 11:51 AM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] security considerations for protocol draft >=20 > On 12/5/12 2:13 PM, Charles Eckel (eckelcu) wrote: > > Hi Paul, > > > > I don't disagree that something better than transitive trust is desirab= le; > however, I don't think Digest authentication really helps. >=20 > It could help if it was deployed and used. It would require that SRCs > (assuming they are the initiators) be configured with a password. Yes, but that simply allows the SRS to authenticate the SRC. However, we st= ate in the draft that authentication of the SRS by the SRS is what is reall= y important.=20 =20 > > Connected Identity does seem useful, but adding requirements around it > seems troublesome at this point to me. >=20 > It we required it, then it might indeed be a problem for some. > But we could make it mandatory to implement, optional to use. And offer > it as one of several alternatives for meeting the security requirement. >=20 > > P-Asserted-Identity relies on transitive trust, so I don't think it mak= es > things any better. >=20 > It does require transitive trust. But it still can make things better. > It at least ensures that, based on trust, you are talking to who you > called, rather than the possibility that this was forwarded to a > different UA than expected. >=20 > Perhaps we could say that the SRC MUST/SHOULD verify that it is talking > to the intended SRS via one of a list of techniques. This approach could help with a security review, but I don't see if helping= interworking much. That said, I do not have any better ideas right now. Cheers, Charles > I have two concerns here: > - as a user of phones, and caller of call centers, I would like some > assurance that when my calls are recorded, that those recordings are > secure. >=20 > - I expect that this will get a very thorough security review. > I would prefer to get this nailed down now rather than invite > objections by the security reviewers. >=20 > > I'd like to hear from those with deployment experience what they do and > what would work for them. >=20 > Yes, that would be good. > But I fear that in most cases people just don't worry about it at all. >=20 > Thanks, > Paul From Ofir.Roth@nice.com Thu Dec 6 04:30:58 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1421F8706 for ; Thu, 6 Dec 2012 04:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B612LbVqwwAg for ; Thu, 6 Dec 2012 04:30:57 -0800 (PST) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id F24AB21F8703 for ; Thu, 6 Dec 2012 04:30:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,230,1355090400"; d="scan'208";a="5735808" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 6 Dec 2012 14:30:54 +0200 From: Ofir Roth To: Parthasarathi R , "'Ram Mohan R (rmohanr)'" , "siprec@ietf.org" Date: Thu, 6 Dec 2012 14:30:53 +0200 Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07JgJ/RxggABgR5CAAVZl4A== Message-ID: References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> In-Reply-To: <000301cdd304$4fcb0ed0$ef612c70$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 12:30:58 -0000 Hi Partha, Still, considering the fact that there are such implementations, I think it= will be very helpful to have 0.x versions according to the draft numbers.= =20 >From my experience with such implementations, it is very hard to determine = the draft number by just looking in the metadata XML itself.=20 Thanks, Ofir. -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 Sent: Wednesday, December 05, 2012 6:19 PM To: Ofir Roth; 'Ram Mohan R (rmohanr)'; siprec@ietf.org Subject: RE: [siprec] Metadata version indicator consensus? Ofir, It is not possible to change the published draft XML schema. IMO, it is not= required to change the XML schema for each upcoming draft also. In case th= ere is a change in the XML schema, the version shall be incremented. I agre= e with you that the initial version is not required to be "0", please let m= e know how abt starting the value with "1". Apart from this, >=20 >The fact is that there are implementations out there which are not=20 >planned to be aligned with the formal/final RFC version. > Your above statement was my initial concern because the market leader imple= ment the draft and claim for the (SIPREC) compliance which forces other ven= dors to implement the draft version as well as RFC version in the reality. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ofir Roth Sent: Wednesday, December 05, 2012 3:46 PM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? Hi Ram,=20 Why is it not possible? Thanks, Ofir. =20 -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] Sent: Wednesday, December 05, 2012 12:01 PM To: Ofir Roth; siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? > On 05/12/12 3:06 PM, "Ofir Roth" wrote: >Hi, > >In regarding to the Andrew's statement below: >> I also got the impression that there was a body of opinion that the=20 >> version should NOT be automatically incremented on a per draft basis. > >I think that there is a concrete need for such support in versioning=20 >per draft - especially in the few first drafts where there were major=20 >changes between drafts. Are you asking about having metadata versions for the older versions (10 an= d below) of the draft ? I am afraid that may not be possible. From ver 11 we would have this versioning numbers assuming we agree on what is being= discussed in this thread. Ram =20 >=20 >The fact is that there are implementations out there which are not=20 >planned to be aligned with the formal/final RFC version. > >Thanks, >Ofir. > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >Behalf Of Hutton, Andrew >Sent: Tuesday, November 27, 2012 8:58 PM >To: siprec@ietf.org >Subject: Re: [siprec] Metadata version indicator consensus? > >Hi All, > >I noticed a typo in the first sentence it should have read: > >Having just read through the thread again with the possible exception=20 >of Mary I think that everyone who contributed to the discussion is in=20 >favor of some kind of version number for metadata. Does anyone disagree=20 >with that? > >Sorry about that I think the rest of the text is ok. > >Regards >Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: 27 November 2012 18:31 >> To: siprec@ietf.org >> Subject: [siprec] Metadata version indicator consensus? >>=20 >> Hi All, >>=20 >> Having just read through the thread again and with the possible=20 >> exception of Mary I don't think that everyone who contributed to the=20 >> discussion is in favour of some kind of version number for metadata. >> Does anyone disagree with that? >>=20 >> I also got the impression that there was a body of opinion that the=20 >> version should NOT be automatically incremented on a per draft basis. >>=20 >> So I think we may be able to get consensus to use the mechanism as=20 >> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail-=20 >> archive/web/siprec/current/msg03532.html. In which he stated: >>=20 >> "This led the XSF to use a protocol versioning scheme currently in=20 >> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and=20 >> increments with each protocol-breaking change. It meant that=20 >> different teams understood to what level another had implemented to,=20 >> and adoption of an I-D phase document to an RFC phase document meant=20 >> no churn simply because the XSF accepted the work". >>=20 >> So for SIPREC we would use something like=20 >> "urn:ietf:params:xml:ns:recording:0" starting with the next update to=20 >> the draft and then only update the version number if we doing=20 >> something that brakes the backwards compatibility. >>=20 >> Could people please let us know if they agree or disagree with this. >>=20 >> Regards >> Andy (SIPREC Co-Chair). >>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Dec 6 08:55:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B021F87B5 for ; Thu, 6 Dec 2012 08:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDnTm1-IZiSv for ; Thu, 6 Dec 2012 08:55:29 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0C21F8623 for ; Thu, 6 Dec 2012 08:55:29 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id YBCl1k0080EZKEL55GvV1t; Thu, 06 Dec 2012 16:55:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id YGvU1k00l3ZTu2S3MGvUly; Thu, 06 Dec 2012 16:55:29 +0000 Message-ID: <50C0CDFF.6020906@alum.mit.edu> Date: Thu, 06 Dec 2012 11:55:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: siprec@ietf.org References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> 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=1354812929; bh=WoIaea8PwBlVCWbYbI6v6WbBuA0sfsg2OKCuE8C3yKU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YCH7BJk24/Go9TYPrMs81D0Eswmytw0nFfPervQwiVOnAs2wx9szDbgq30Ov2VKeu veM9bRR54SJBl5JXQHBKTrXYE6J+Yl0SzDm7EvzvEie5h6Hm1w0s0NHWV5cvlbncaR m1G9EsmK8o2LPNYtfPs9r0WEErcHLLHPbY5y/jjsdWO7vjQKxA53f2Q27MIoBYbHTI aRr1Um89i5lESYpswjzMGf6VQT20xRKSZFK1swkS3uhzhWKVZNR3/yumNeaRn4A7AU DGSzJoAbA4cVEGNHpBPYHZVIkPQafH4cmdO0x1KCnQ6442s7ErxGIZnOHmmSmld1wh 10mP0+cOnjUcA== Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:55:30 -0000 On 12/6/12 7:30 AM, Ofir Roth wrote: > Hi Partha, > > Still, considering the fact that there are such implementations, I think it will be very helpful to have 0.x versions according to the draft numbers. >>From my experience with such implementations, it is very hard to determine the draft number by just looking in the metadata XML itself. If we change increment the version number in the schema urn each time there is a schema change, then you can search through draft versions for the one where that first appeared. It is a little harder than pulling the draft number out of the URN, but not much. The advantage of that over changing with each draft is that editorial changes that don't affect the schema also don't affect interoperability. Especially, if you implement draft-NN and then that goes to draft-NN+3 and then becomes an RFC without changing the schema then your implementation need not be revised to be compatible with the spec. Thanks, Paul > Thanks, > Ofir. > > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Wednesday, December 05, 2012 6:19 PM > To: Ofir Roth; 'Ram Mohan R (rmohanr)'; siprec@ietf.org > Subject: RE: [siprec] Metadata version indicator consensus? > > Ofir, > > It is not possible to change the published draft XML schema. IMO, it is not required to change the XML schema for each upcoming draft also. In case there is a change in the XML schema, the version shall be incremented. I agree with you that the initial version is not required to be "0", please let me know how abt starting the value with "1". > > Apart from this, >> >> The fact is that there are implementations out there which are not >> planned to be aligned with the formal/final RFC version. >> > > > Your above statement was my initial concern because the market leader implement the draft and claim for the (SIPREC) compliance which forces other vendors to implement the draft version as well as RFC version in the reality. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth > Sent: Wednesday, December 05, 2012 3:46 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > > Hi Ram, > > Why is it not possible? > > Thanks, > Ofir. > > > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Wednesday, December 05, 2012 12:01 PM > To: Ofir Roth; siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > >> On 05/12/12 3:06 PM, "Ofir Roth" wrote: > >> Hi, >> >> In regarding to the Andrew's statement below: >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >> >> I think that there is a concrete need for such support in versioning >> per draft - especially in the few first drafts where there were major >> changes between drafts. > > Are you asking about having metadata versions for the older versions (10 and > below) of the draft ? I am afraid that may not be possible. From ver > 11 we would have this versioning numbers assuming we agree on what is being discussed in this thread. > > Ram > >> >> The fact is that there are implementations out there which are not >> planned to be aligned with the formal/final RFC version. >> >> Thanks, >> Ofir. >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Tuesday, November 27, 2012 8:58 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indicator consensus? >> >> Hi All, >> >> I noticed a typo in the first sentence it should have read: >> >> Having just read through the thread again with the possible exception >> of Mary I think that everyone who contributed to the discussion is in >> favor of some kind of version number for metadata. Does anyone disagree >> with that? >> >> Sorry about that I think the rest of the text is ok. >> >> Regards >> Andy >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: 27 November 2012 18:31 >>> To: siprec@ietf.org >>> Subject: [siprec] Metadata version indicator consensus? >>> >>> Hi All, >>> >>> Having just read through the thread again and with the possible >>> exception of Mary I don't think that everyone who contributed to the >>> discussion is in favour of some kind of version number for metadata. >>> Does anyone disagree with that? >>> >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >>> >>> So I think we may be able to get consensus to use the mechanism as >>> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- >>> archive/web/siprec/current/msg03532.html. In which he stated: >>> >>> "This led the XSF to use a protocol versioning scheme currently in >>> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and >>> increments with each protocol-breaking change. It meant that >>> different teams understood to what level another had implemented to, >>> and adoption of an I-D phase document to an RFC phase document meant >>> no churn simply because the XSF accepted the work". >>> >>> So for SIPREC we would use something like >>> "urn:ietf:params:xml:ns:recording:0" starting with the next update to >>> the draft and then only update the version number if we doing >>> something that brakes the backwards compatibility. >>> >>> Could people please let us know if they agree or disagree with this. >>> >>> Regards >>> Andy (SIPREC Co-Chair). >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From internet-drafts@ietf.org Fri Dec 7 15:32:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB4F21F8798; Fri, 7 Dec 2012 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqwGAs-bqSQK; Fri, 7 Dec 2012 15:32:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409D021F8753; Fri, 7 Dec 2012 15:32:28 -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.36 Message-ID: <20121207233228.13204.79213.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2012 15:32:28 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-09.txt Pages : 42 Date : 2012-12-07 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eckelcu@cisco.com Fri Dec 7 15:34:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE76A21F86E8; Fri, 7 Dec 2012 15:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pPqabp89FKA; Fri, 7 Dec 2012 15:34:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CB4B221F89BF; Fri, 7 Dec 2012 15:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2916; q=dns/txt; s=iport; t=1354923280; x=1356132880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bVZerpzNIPUY9ufeqawwS7XY/S8/iMHTX5uvAZ15evk=; b=iKuk7K4w0NfurQfk7iVGpsSgmZ9a/oP+Vx1BzhKlbAdAB2T5XFiNaP+B 62tI7H+JOrdhfi4Ak8coDUxx4MPtfTk42B+3ScQwNIpF0t00dS4dzce4R 44kryWdTxbhcw0YTR4uxY8QAylu5/1VN9ie6RKvJs4j0bcIkO49V8r1XL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAB98wlCtJV2Y/2dsb2JhbABEg2u6UxZzgh4BAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAYgHAQcFwSCMPxuDR2EDlyGPLIJzgW01 X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150681744" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 07 Dec 2012 23:34:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7NYTDc030658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 23:34:29 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 17:34:29 -0600 From: "Charles Eckel (eckelcu)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt Thread-Index: AQHN1NMvFj7Vqi2tcEueG88Nw1jcTJgN/OTg Date: Fri, 7 Dec 2012 23:34:28 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046D553E@xmb-aln-x08.cisco.com> References: <20121207233228.13204.79213.idtracker@ietfa.amsl.com> In-Reply-To: <20121207233228.13204.79213.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:34:41 -0000 Changes in this update of the protocol draft: Updated section 8.3, "RTP Session Usage by SRC". Removed section 8.3.2, " S= RC using SSRC Multiplexing". The workgroup reached consensus at IETF 85 tha= t SSRC multiplexing is out of scope. The definition of it is left for CLUE/= RTCWEB. Added section 8.4, "RTP Session Usage by SRS". This section places requirem= ents on the SRS to support a minimum level of RTP session usages. The text = is based on that posted by Hadriel (http://www.ietf.org/mail-archive/web/si= prec/current/msg03508.html), with some modifications as discussed on the li= st. Reworked section 12, "Security Consideration", clarifying some text as dis= cussed on the list (http://www.ietf.org/mail-archive/web/siprec/current/msg= 03597.html), and also adding a note about the potential for the SRC to use = EKT. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Friday, December 07, 2012 3:32 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Recording Working Group of the IETF= . >=20 > Title : Session Recording Protocol > Author(s) : Leon Portman > Henry Lum > Charles Eckel > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-09.txt > Pages : 42 > Date : 2012-12-07 >=20 > Abstract: > This document specifies the use of the Session Initiation Protocol > (SIP), the Session Description Protocol (SDP), and the Real Time > Protocol (RTP) for delivering real-time media and metadata from a > Communication Session (CS) to a recording device. The Session > Recording Protocol specifies the use of SIP, SDP, and RTP to > establish a Recording Session (RS) between the Session Recording > Client (SRC), which is on the path of the CS, and a Session Recording > Server (SRS) at the recording device. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-09 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Fri Dec 7 15:39:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E02C21F8BC2 for ; Fri, 7 Dec 2012 15:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BsZ+nqSpCus for ; Fri, 7 Dec 2012 15:39:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 20E5521F86EA for ; Fri, 7 Dec 2012 15:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3590; q=dns/txt; s=iport; t=1354923546; x=1356133146; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nKvWnNmgvHS+4vhDhhNu0grBHx0QtMPhJtcwJaqS22g=; b=ayp+PWilldoSXmkeq0HiIb4brafvWNciNn7YsG6AZoi+Ntx4Qezx1Erx B9hqQI4ZNTKZg8iTR5GV4NdxKcj0UtvUUZN20/4D4QjZFMJl2GlAW1/Cz Yd4Yb3JVlTHSQpRFDTlL5WrcN+Y6Xedgh31S8pvPhluo36cALCrDzi+M7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAM98wlCtJV2c/2dsb2JhbABEg2u6UxZzgh4BAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIAYgHAQcFwSGMPxuDR2EDlyGKHoUOgnOBbTU X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150682625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 07 Dec 2012 23:39:05 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB7Nd5Q4001623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Dec 2012 23:39:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 17:39:05 -0600 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt Thread-Index: AQHN1NMvFj7Vqi2tcEueG88Nw1jcTJgN/OTggAABBUA= Date: Fri, 7 Dec 2012 23:39:04 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046D556C@xmb-aln-x08.cisco.com> References: <20121207233228.13204.79213.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828046D553E@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046D553E@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:39:07 -0000 Removing the internet-drafts and i-d-announce lists that I unintentionally = spammed. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Charles Eckel (eckelcu) > Sent: Friday, December 07, 2012 3:34 PM > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt >=20 > Changes in this update of the protocol draft: >=20 > Updated section 8.3, "RTP Session Usage by SRC". Removed section 8.3.2, " > SRC using SSRC Multiplexing". The workgroup reached consensus at IETF 85 > that SSRC multiplexing is out of scope. The definition of it is left for > CLUE/RTCWEB. >=20 > Added section 8.4, "RTP Session Usage by SRS". This section places > requirements on the SRS to support a minimum level of RTP session usages. > The text is based on that posted by Hadriel (http://www.ietf.org/mail- > archive/web/siprec/current/msg03508.html), with some modifications as > discussed on the list. >=20 > Reworked section 12, "Security Consideration", clarifying some text as > discussed on the list (http://www.ietf.org/mail- > archive/web/siprec/current/msg03597.html), and also adding a note about > the potential for the SRC to use EKT. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of internet-drafts@ietf.org > > Sent: Friday, December 07, 2012 3:32 PM > > To: i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the SIP Recording Working Group of the IE= TF. > > > > Title : Session Recording Protocol > > Author(s) : Leon Portman > > Henry Lum > > Charles Eckel > > Alan Johnston > > Andrew Hutton > > Filename : draft-ietf-siprec-protocol-09.txt > > Pages : 42 > > Date : 2012-12-07 > > > > Abstract: > > This document specifies the use of the Session Initiation Protocol > > (SIP), the Session Description Protocol (SDP), and the Real Time > > Protocol (RTP) for delivering real-time media and metadata from a > > Communication Session (CS) to a recording device. The Session > > Recording Protocol specifies the use of SIP, SDP, and RTP to > > establish a Recording Session (RS) between the Session Recording > > Client (SRC), which is on the path of the CS, and a Session Recordin= g > > Server (SRS) at the recording device. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-siprec-protocol-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-09 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Fri Dec 7 23:47:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817F21F8495 for ; Fri, 7 Dec 2012 23:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lZoMKQIDBk9 for ; Fri, 7 Dec 2012 23:47:05 -0800 (PST) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 369E921F8490 for ; Fri, 7 Dec 2012 23:47:04 -0800 (PST) Received: from userPC (unknown [122.179.92.100]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id C25758688A4; Sat, 8 Dec 2012 07:47:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1354952824; bh=KSCTNumYJEe+ITuXsKxg7eJ6x+mWSwG2TyOcdKxkGfA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=fpyn26NPzl503lyg9xi7qeIXwotiAW2vaHJDVEsiTmG0ijedyW/kt7Pls83f7xFsS jgVhIEw9hONT+VSl+ooVn8ByrCLKPChXn996lbuwV8/yGzXLzeB/9210x0hAAqpKIK fyf01VkJLdaGDyJPLvczzsPTHQgYNEyOrOJZfpOU= From: "Parthasarathi R" To: References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> <50C0CDFF.6020906@alum.mit.edu> In-Reply-To: <50C0CDFF.6020906@alum.mit.edu> Date: Sat, 8 Dec 2012 13:16:53 +0530 Message-ID: <000101cdd518$32f60dd0$98e22970$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3T0oC75JPeO+p0T82RY/IXRtkBggBQ1inw Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0208.50C2F078.005D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 07:47:06 -0000 Hi all, Based on the discussion in this mail thread, I propose the following metadata version indicator text to be added in the "namespace" section of draft-ietf-siprec-metadata draft: "The URN is as follows: urn:ietf:params:xml:ns:recording:1 The value '1' represent SIPREC metadata version. This version value helps SRS to know the exact metadata XML schema sent by SRC. The version value MUST be incremented by one in case there is a changed in metadata XML schema in the forthcoming draft revision or future updates. Also, the version number does not indicate the backward compatibility with the previous version." Please let me know in case any objection/suggestion to the above text. Thanks Partha PS: The initial value is chosen as "1" because couple of earlier implementation exists. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, December 06, 2012 10:25 PM To: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? On 12/6/12 7:30 AM, Ofir Roth wrote: > Hi Partha, > > Still, considering the fact that there are such implementations, I think it will be very helpful to have 0.x versions according to the draft numbers. >>From my experience with such implementations, it is very hard to determine the draft number by just looking in the metadata XML itself. If we change increment the version number in the schema urn each time there is a schema change, then you can search through draft versions for the one where that first appeared. It is a little harder than pulling the draft number out of the URN, but not much. The advantage of that over changing with each draft is that editorial changes that don't affect the schema also don't affect interoperability. Especially, if you implement draft-NN and then that goes to draft-NN+3 and then becomes an RFC without changing the schema then your implementation need not be revised to be compatible with the spec. Thanks, Paul > Thanks, > Ofir. > > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Wednesday, December 05, 2012 6:19 PM > To: Ofir Roth; 'Ram Mohan R (rmohanr)'; siprec@ietf.org > Subject: RE: [siprec] Metadata version indicator consensus? > > Ofir, > > It is not possible to change the published draft XML schema. IMO, it is not required to change the XML schema for each upcoming draft also. In case there is a change in the XML schema, the version shall be incremented. I agree with you that the initial version is not required to be "0", please let me know how abt starting the value with "1". > > Apart from this, >> >> The fact is that there are implementations out there which are not >> planned to be aligned with the formal/final RFC version. >> > > > Your above statement was my initial concern because the market leader implement the draft and claim for the (SIPREC) compliance which forces other vendors to implement the draft version as well as RFC version in the reality. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth > Sent: Wednesday, December 05, 2012 3:46 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > > Hi Ram, > > Why is it not possible? > > Thanks, > Ofir. > > > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Wednesday, December 05, 2012 12:01 PM > To: Ofir Roth; siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > >> On 05/12/12 3:06 PM, "Ofir Roth" wrote: > >> Hi, >> >> In regarding to the Andrew's statement below: >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >> >> I think that there is a concrete need for such support in versioning >> per draft - especially in the few first drafts where there were major >> changes between drafts. > > Are you asking about having metadata versions for the older versions (10 and > below) of the draft ? I am afraid that may not be possible. From ver > 11 we would have this versioning numbers assuming we agree on what is being discussed in this thread. > > Ram > >> >> The fact is that there are implementations out there which are not >> planned to be aligned with the formal/final RFC version. >> >> Thanks, >> Ofir. >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Tuesday, November 27, 2012 8:58 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indicator consensus? >> >> Hi All, >> >> I noticed a typo in the first sentence it should have read: >> >> Having just read through the thread again with the possible exception >> of Mary I think that everyone who contributed to the discussion is in >> favor of some kind of version number for metadata. Does anyone disagree >> with that? >> >> Sorry about that I think the rest of the text is ok. >> >> Regards >> Andy >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: 27 November 2012 18:31 >>> To: siprec@ietf.org >>> Subject: [siprec] Metadata version indicator consensus? >>> >>> Hi All, >>> >>> Having just read through the thread again and with the possible >>> exception of Mary I don't think that everyone who contributed to the >>> discussion is in favour of some kind of version number for metadata. >>> Does anyone disagree with that? >>> >>> I also got the impression that there was a body of opinion that the >>> version should NOT be automatically incremented on a per draft basis. >>> >>> So I think we may be able to get consensus to use the mechanism as >>> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- >>> archive/web/siprec/current/msg03532.html. In which he stated: >>> >>> "This led the XSF to use a protocol versioning scheme currently in >>> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and >>> increments with each protocol-breaking change. It meant that >>> different teams understood to what level another had implemented to, >>> and adoption of an I-D phase document to an RFC phase document meant >>> no churn simply because the XSF accepted the work". >>> >>> So for SIPREC we would use something like >>> "urn:ietf:params:xml:ns:recording:0" starting with the next update to >>> the draft and then only update the version number if we doing >>> something that brakes the backwards compatibility. >>> >>> Could people please let us know if they agree or disagree with this. >>> >>> Regards >>> Andy (SIPREC Co-Chair). >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Mon Dec 10 04:03:03 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CDE21F8E54 for ; Mon, 10 Dec 2012 04:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmyW3LHKnEiY for ; Mon, 10 Dec 2012 04:03:03 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0221F8E38 for ; Mon, 10 Dec 2012 04:03:03 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id AA7671EB8625; Mon, 10 Dec 2012 13:03:01 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 13:03:01 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: Ac3Mpe64dh/UOUN3S2CAgVO5Inr5FwBoii6AAiEd0cA= Date: Mon, 10 Dec 2012 12:02:58 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01389CC5@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013710D9@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 12:03:04 -0000 On 29 November 2012 16:42 Ram Mohan R Wrote: >=20 > In figure 4, for completeness sake it would be better to show RTP/RTCP > in > the line from UA-Application server to UA-B. I see everywhere else(all > other figures) we have > shown RTP/RTCP. >=20 [AndyH] - "RTP" and "RTP/RTCP" does appear to be used rather inconsistently= in Figure 4 and 5 these should probably be cleaned up before sending to th= e IESG. > One question: > In section 5 there is this statement at the end >=20 > "The crypto suites on the retrieval should > be no less strong than used on the RS, and may need to be stronger. > " > Wonder if its needed to specify such details (constraints) about > retrieval > methods when it is mentioned earlier in the document that it is out of > scope. >=20 I think we agreed to add this text in previous discussions although retriev= al is out of scope this is not normative text so is just a guide to make pe= ople think about this issues. Regards Andy From DAVE.HIGTON@nice.com Mon Dec 10 04:16:46 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5147E21F86F8 for ; Mon, 10 Dec 2012 04:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aU2xfoH6dvb for ; Mon, 10 Dec 2012 04:16:45 -0800 (PST) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id A533D21F866D for ; Mon, 10 Dec 2012 04:16:45 -0800 (PST) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Mon, 10 Dec 2012 12:16:44 +0000 Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Dec 2012 12:16:43 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::ec6d:6017:186e:e8f8]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Mon, 10 Dec 2012 12:16:43 +0000 From: "Dave Higton" To: Date: Mon, 10 Dec 2012 12:16:42 +0000 Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: AQHNzlB5VcvFa8jSy0ivJINJOLP445gSAvig Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B694056073DC7E@SOUEXC01.eu.nice.com> References: <9F33F40F6F2CD847824537F3C4E37DDF013710D9@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2012 12:16:43.0865 (UTC) FILETIME=[37A40490:01CDD6D0] Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 12:16:46 -0000 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Ram Mohan R (rmohanr) Sent: 29 November 2012 16:42 To: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture > I took a look at the latest revision. The document looks very good and = ready to go. One minor nits. > In figure 4, for completeness sake it would be better to show RTP/RTCP = in the line from UA-Application > server to UA-B. I see everywhere else(all other figures) we have shown = RTP/RTCP. The RFC for RTP includes RTCP without mentioning it explicitly in its = title, so perhaps cleaning all references up to say just "RTP" would seem appropriate. Dave NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From rmohanr@cisco.com Mon Dec 10 06:32:00 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC48A21F8439 for ; Mon, 10 Dec 2012 06:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5osb0b0fSmDh for ; Mon, 10 Dec 2012 06:32:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 40DAE21F8434 for ; Mon, 10 Dec 2012 06:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1159; q=dns/txt; s=iport; t=1355149920; x=1356359520; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=dM9Td3NnIXl60VD2zAoCntw915zaKbNTGFrtbOMMce8=; b=RHhSbsz9IKG8WYh/tlrxw2d7JtUYjvv1pQ9J1jb3oR0IoSmDz9EFyV8S kbPDxjYWqaZ5SckJ0Oo1AOt/ln8S+pRuEbn3PejTVKwUoWgS71hU8nh9k KRUvAY382NFqoynuLr5naOhdKiBHHgD656bnV0e0aZIUUcIATVu9Uyjpi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHXxxVCtJXHA/2dsb2JhbABFvnQWc4IeAQEBAwE6RA0BCBIGChRCFw4CBAESCIgDBrUXjD+DYmEDpk6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="151211725" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2012 14:31:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBAEVxSi016642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 14:31:59 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.177]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 08:31:59 -0600 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: AQHN1uMcJDinjUdJJUuEITV9NpZgAA== Date: Mon, 10 Dec 2012 14:31:58 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF01389CC5@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.77.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:32:01 -0000 > On 10/12/12 5:32 PM, "Hutton, Andrew" > wrote: >On 29 November 2012 16:42 Ram Mohan R Wrote: >>=20 >> In figure 4, for completeness sake it would be better to show RTP/RTCP >> in >> the line from UA-Application server to UA-B. I see everywhere else(all >> other figures) we have >> shown RTP/RTCP. >>=20 > >[AndyH] - "RTP" and "RTP/RTCP" does appear to be used rather >inconsistently in Figure 4 and 5 these should probably be cleaned up >before sending to the IESG. > > >> One question: >> In section 5 there is this statement at the end >>=20 >> "The crypto suites on the retrieval should >> be no less strong than used on the RS, and may need to be stronger. >> " >> Wonder if its needed to specify such details (constraints) about >> retrieval >> methods when it is mentioned earlier in the document that it is out of >> scope. >>=20 > >I think we agreed to add this text in previous discussions although >retrieval is out of scope this is not normative text so is just a guide >to make people think about this issues. Sure. I am ok with this. Ram > >Regards >Andy > From br@brianrosen.net Mon Dec 10 06:49:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3A21F84FC for ; Mon, 10 Dec 2012 06:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdA-S54PukHm for ; Mon, 10 Dec 2012 06:49:07 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id BA56B21F8504 for ; Mon, 10 Dec 2012 06:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=1rqQkkKQw4VeqwnbqYpXKCh8GYEdYRqHvirYrUF+HA0=; b=F0+PQLph3hFvIAZPN1OqE0BmEwmgJKB7xNmX8QMpGrk2ncxOA6dsCmpsgxd9+ag2P9ccuuVJVj57VaBsX//8xk1/cOLab6tuKlNrYGwXMCFsSnmwvkfZZY6eSo7KNfSU; Received: from neustargw.va.neustar.com ([209.173.53.233]:38370 helo=[192.168.133.176]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ti4fG-0003CK-Bs; Mon, 10 Dec 2012 09:49:02 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: <000101cdd518$32f60dd0$98e22970$@co.in> Date: Mon, 10 Dec 2012 09:48:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <482DDA50-1F74-423C-AC22-791D1E9235D7@brianrosen.net> References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> <50C0CDFF.6020906@alum.mit.edu> <000101cdd518$32f60dd0$98e22970$@co.in> To: Parthasarathi R X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:49:08 -0000 may I suggest: The value '1' represent SIPREC metadata version. This version value = allows the SRS to know the exact metadata XML schema sent by the SRC. This document = describes version 1. Implementations may not interoperate if the = version implemented by the sender is not known by the receiver. No = negotiation of versions is provided. There is no significance to the = version number although documents which update or obsolete this document = (possibly including drafts of such documents) should include a higher = version number if the metadata changes in a non-interoperable way. I don't think a MUST can be used to bind a future document writer. Brian On Dec 8, 2012, at 2:46 AM, Parthasarathi R = wrote: > The version value > MUST be incremented by one in case there is a changed in metadata XML = schema > in the forthcoming draft revision or future updates From partha@parthasarathi.co.in Mon Dec 10 09:24:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED38E21F856D for ; Mon, 10 Dec 2012 09:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnhyUJCTCDBI for ; Mon, 10 Dec 2012 09:24:59 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.230]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC121F8558 for ; Mon, 10 Dec 2012 09:24:59 -0800 (PST) Received: from userPC (unknown [122.179.111.254]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 5F84919081CB; Mon, 10 Dec 2012 17:24:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1355160298; bh=2VXn22crq4Nj2orjXTejaz5mMdPK2ZKByuMkr5APIh8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YBQSu/+ISQGKMSq5pPgE7kX5MQv/3/3eV9rxSGwKdSJONUAJK81K0ZiNTqUJUDo4U IKNm1H9X0EArn26s5AhP/gY1Byj6m+jIcDDSdWoCGFofl+B4L0atKfAUQlFAenmYvw 1VuGaAEcB8gfn8aIyoheb/J0Zw7ixxFUAwJ+xs0Q= From: "Parthasarathi R" To: "'Brian Rosen'" References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> <50C0CDFF.6020906@alum.mit.edu> <000101cdd518$32f60dd0$98e22970$@co.in> <482DDA50-1F74-423C-AC22-791D1E9235D7@brianrosen.net> In-Reply-To: <482DDA50-1F74-423C-AC22-791D1E9235D7@brianrosen.net> Date: Mon, 10 Dec 2012 22:54:52 +0530 Message-ID: <002401cdd6fb$46c89be0$d459d3a0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3W5YKQ8922/JwPRXeYyP5n9fKJQAAE23ZA Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0207.50C61AEA.0108, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:25:00 -0000 Brian, Thanks for your suggested text. In case it is not recommended to use "MUST" for future document writer, I'm fine. I have only one concern in the suggested text. The last statement words "in a non-interoperable way" seems to indicate some kind of backward-compatibility which has to be ensured in the draft for interoperable changes in XML schema. I agree with your suggestion except for the last 5 words and the updated text will look like: " The value '1' represent SIPREC metadata version. This version value allows the SRS to know the exact metadata XML schema sent by the SRC. This document describes version 1. Implementations may not interoperate if the version implemented by the sender is not known by the receiver. No negotiation of versions is provided. There is no significance to the version number although documents which update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata XML schema changes." I'm not very clear how to qualify whether the updated XML schema is backward compatible with earlier XML schema. Please let me know your opinion on the same. Also, I'm not sure whether lowercase "should" keyword is allowed within standard track document and I'll run IETF nits tool with the text to confirm my doubt. Thanks Partha -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, December 10, 2012 8:19 PM To: Parthasarathi R Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? may I suggest: The value '1' represent SIPREC metadata version. This version value allows the SRS to know the exact metadata XML schema sent by the SRC. This document describes version 1. Implementations may not interoperate if the version implemented by the sender is not known by the receiver. No negotiation of versions is provided. There is no significance to the version number although documents which update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata changes in a non-interoperable way. I don't think a MUST can be used to bind a future document writer. Brian On Dec 8, 2012, at 2:46 AM, Parthasarathi R wrote: > The version value > MUST be incremented by one in case there is a changed in metadata XML schema > in the forthcoming draft revision or future updates From br@brianrosen.net Mon Dec 10 09:29:16 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80C021F84CE for ; Mon, 10 Dec 2012 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02mMjuE5AxH0 for ; Mon, 10 Dec 2012 09:29:15 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6F21F8503 for ; Mon, 10 Dec 2012 09:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=r4uwZ++ni8prygaBiWJoYdloaRF9ES29eT7gMsSpND8=; b=pOdo2xoU+HaTpq0siMYJxseZLdzRMN7EkFyBqzGuTvMkI0F+1tGqq+VL7iMMzIH8FTZsqzEO+L2iDi4uwkMCwvNf67k229Nz5OWh1bJbtAjDfzcrsLdEea6ua+XY8fgf; Received: from neustargw.va.neustar.com ([209.173.53.233]:36454 helo=[192.168.133.176]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ti7AI-0005vo-EB; Mon, 10 Dec 2012 12:29:14 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: <002401cdd6fb$46c89be0$d459d3a0$@co.in> Date: Mon, 10 Dec 2012 12:29:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> <50C0CDFF.6020906@alum.mit.edu> <000101cdd518$32f60dd0$98e22970$@co.in> <482DDA50-1F74-423C-AC22-791D1E9235D7@brianrosen.net> <002401cdd6fb$46c89be0$d459d3a0$@co.in> To: Parthasarathi R X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:29:17 -0000 I'm happy with the reword. =20 I do think you can use "should" where we are not defining protocol = behavior. I should think so anyway :) Brian On Dec 10, 2012, at 12:24 PM, Parthasarathi R = wrote: > Brian, >=20 > Thanks for your suggested text. In case it is not recommended to use = "MUST" > for future document writer, I'm fine. I have only one concern in the > suggested text. The last statement words "in a non-interoperable way" = seems > to indicate some kind of backward-compatibility which has to be = ensured in > the draft for interoperable changes in XML schema. I agree with your > suggestion except for the last 5 words and the updated text will look = like: >=20 > " The value '1' represent SIPREC metadata version. This version value = allows > the SRS to know the exact metadata XML schema sent by the SRC. This = document > describes version 1. Implementations may not interoperate if the = version > implemented by the sender is not known by the receiver. No = negotiation of > versions is provided. There is no significance to the version number > although documents which update or obsolete this document (possibly > including drafts of such documents) should include a higher version = number > if the metadata XML schema changes." >=20 > I'm not very clear how to qualify whether the updated XML schema is = backward > compatible with earlier XML schema. Please let me know your opinion on = the > same. >=20 > Also, I'm not sure whether lowercase "should" keyword is allowed = within > standard track document and I'll run IETF nits tool with the text to = confirm > my doubt. >=20 > Thanks > Partha=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, December 10, 2012 8:19 PM > To: Parthasarathi R > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? >=20 > may I suggest: >=20 > The value '1' represent SIPREC metadata version. This version value = allows > the > SRS to know the exact metadata XML schema sent by the SRC. This = document > describes version 1. Implementations may not interoperate if the = version > implemented by the sender is not known by the receiver. No = negotiation of > versions is provided. There is no significance to the version number > although documents which update or obsolete this document (possibly > including drafts of such documents) should include a higher version = number > if the metadata changes in a non-interoperable way. >=20 >=20 >=20 >=20 > I don't think a MUST can be used to bind a future document writer. >=20 > Brian >=20 > On Dec 8, 2012, at 2:46 AM, Parthasarathi R = > wrote: >=20 >> The version value >> MUST be incremented by one in case there is a changed in metadata XML > schema >> in the forthcoming draft revision or future updates >=20 From partha@parthasarathi.co.in Mon Dec 10 09:45:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A3921F84ED for ; Mon, 10 Dec 2012 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHFA4j9zBxmX for ; Mon, 10 Dec 2012 09:45:29 -0800 (PST) Received: from outbound-us3.mailhostbox.com (unknown [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id 83D8A21F84F3 for ; Mon, 10 Dec 2012 09:45:29 -0800 (PST) Received: from userPC (unknown [122.179.111.254]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 89DF18685B9; Mon, 10 Dec 2012 17:45:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1355161528; bh=E/TIDfuogqrhN8J5No6yDgwbOpCkfK4rec1Qu3aNSGY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U1y7AEn4awQGIHqC9Q7ITbpJSrlkQeyqo1dwk9JO+xjkjiM4Gd86HbS/7Eaqs6elK QxKZn4x+6XpV8R5PapYzzU0CTuam4aYz50nTVpxVv8bCJFbDaoslJxtqAjB3wd8b3v KNgoUMgGtzplyaZLaT4fTSbESy/KLQe1mFlsueQU= From: "Parthasarathi R" To: "'Brian Rosen'" , References: <000301cdd304$4fcb0ed0$ef612c70$@co.in> <50C0CDFF.6020906@alum.mit.edu> <000101cdd518$32f60dd0$98e22970$@co.in> <482DDA50-1F74-423C-AC22-791D1E9235D7@brianrosen.net> <002401cdd6fb$46c89be0$d459d3a0$@co.in> In-Reply-To: Date: Mon, 10 Dec 2012 23:15:23 +0530 Message-ID: <002501cdd6fe$24081880$6c184980$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3W++AwqvZqLodDShOsXZhmY+nSAQAAWqcA Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0201.50C61FB8.0153, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:45:30 -0000 Brian, Thanks for the quick closure. Hi all, Could you please let us know any objection/suggestion to the below proposed text in a week time. Thanks Partha -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, December 10, 2012 10:59 PM To: Parthasarathi R Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indicator consensus? I'm happy with the reword. I do think you can use "should" where we are not defining protocol behavior. I should think so anyway :) Brian On Dec 10, 2012, at 12:24 PM, Parthasarathi R wrote: > Brian, > > Thanks for your suggested text. In case it is not recommended to use "MUST" > for future document writer, I'm fine. I have only one concern in the > suggested text. The last statement words "in a non-interoperable way" seems > to indicate some kind of backward-compatibility which has to be ensured in > the draft for interoperable changes in XML schema. I agree with your > suggestion except for the last 5 words and the updated text will look like: > > " The value '1' represent SIPREC metadata version. This version value allows > the SRS to know the exact metadata XML schema sent by the SRC. This document > describes version 1. Implementations may not interoperate if the version > implemented by the sender is not known by the receiver. No negotiation of > versions is provided. There is no significance to the version number > although documents which update or obsolete this document (possibly > including drafts of such documents) should include a higher version number > if the metadata XML schema changes." > > I'm not very clear how to qualify whether the updated XML schema is backward > compatible with earlier XML schema. Please let me know your opinion on the > same. > > Also, I'm not sure whether lowercase "should" keyword is allowed within > standard track document and I'll run IETF nits tool with the text to confirm > my doubt. > > Thanks > Partha > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, December 10, 2012 8:19 PM > To: Parthasarathi R > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? > > may I suggest: > > The value '1' represent SIPREC metadata version. This version value allows > the > SRS to know the exact metadata XML schema sent by the SRC. This document > describes version 1. Implementations may not interoperate if the version > implemented by the sender is not known by the receiver. No negotiation of > versions is provided. There is no significance to the version number > although documents which update or obsolete this document (possibly > including drafts of such documents) should include a higher version number > if the metadata changes in a non-interoperable way. > > > > > I don't think a MUST can be used to bind a future document writer. > > Brian > > On Dec 8, 2012, at 2:46 AM, Parthasarathi R > wrote: > >> The version value >> MUST be incremented by one in case there is a changed in metadata XML > schema >> in the forthcoming draft revision or future updates > From rmohanr@cisco.com Mon Dec 10 21:03:19 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C021F86B9 for ; Mon, 10 Dec 2012 21:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbd0sboPJUzd for ; Mon, 10 Dec 2012 21:03:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE1821F86A2 for ; Mon, 10 Dec 2012 21:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3707; q=dns/txt; s=iport; t=1355202198; x=1356411798; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=setpLQXi7u8VkM8AZEARRJ0pzuqv7ihEkB5KiAqG+Kc=; b=g0sAKigJFy8JXYTOEin3MU51xZWB6RWk52q+xjgBRiCsPZXscAE33ayg yq+vRk2YpiLo10EWNc4sT/qFUi5ljrHDuFStOYh7PB6AvpP1VLRZItREg +S1me1vmn1190Syh/sdgmbx0/gOGf2AK0i8VzSKNhHPSpL0RZcY1r+Vlx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPy9xlCtJV2Z/2dsb2JhbABFvm8Wc4IeAQEBAwEBAQE3NBAHBgEIEQQBAQEKFAkuCxQJCAIEARIIiAMGDKhFkDAEjD+DYmEDpk6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151301646" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 11 Dec 2012 05:03:18 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBB53H82003900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 05:03:17 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.177]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 23:03:17 -0600 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "'Brian Rosen'" , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHN11zUo0NO8bnKMkSqRzD7twg07A== Date: Tue, 11 Dec 2012 05:03:17 +0000 Message-ID: In-Reply-To: <002501cdd6fe$24081880$6c184980$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <16E0978DFA3F1B4C88A6CBCA3DE89C8D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:03:19 -0000 I am fine with the below text. Ram > On 10/12/12 11:15 PM, "Parthasarathi R" >wrote: >Brian, > >Thanks for the quick closure. > >Hi all, > >Could you please let us know any objection/suggestion to the below >proposed >text in a week time. > >Thanks >Partha > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, December 10, 2012 10:59 PM >To: Parthasarathi R >Cc: siprec@ietf.org >Subject: Re: [siprec] Metadata version indicator consensus? > >I'm happy with the reword. > >I do think you can use "should" where we are not defining protocol >behavior. > >I should think so anyway :) > >Brian >On Dec 10, 2012, at 12:24 PM, Parthasarathi R >wrote: > >> Brian, >>=20 >> Thanks for your suggested text. In case it is not recommended to use >"MUST" >> for future document writer, I'm fine. I have only one concern in the >> suggested text. The last statement words "in a non-interoperable way" >seems >> to indicate some kind of backward-compatibility which has to be ensured >>in >> the draft for interoperable changes in XML schema. I agree with your >> suggestion except for the last 5 words and the updated text will look >like: >>=20 >> " The value '1' represent SIPREC metadata version. This version value >allows >> the SRS to know the exact metadata XML schema sent by the SRC. This >document >> describes version 1. Implementations may not interoperate if the >>version >> implemented by the sender is not known by the receiver. No negotiation >>of >> versions is provided. There is no significance to the version number >> although documents which update or obsolete this document (possibly >> including drafts of such documents) should include a higher version >>number >> if the metadata XML schema changes." >>=20 >> I'm not very clear how to qualify whether the updated XML schema is >backward >> compatible with earlier XML schema. Please let me know your opinion on >>the >> same. >>=20 >> Also, I'm not sure whether lowercase "should" keyword is allowed within >> standard track document and I'll run IETF nits tool with the text to >confirm >> my doubt. >>=20 >> Thanks >> Partha=20 >>=20 >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, December 10, 2012 8:19 PM >> To: Parthasarathi R >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indicator consensus? >>=20 >> may I suggest: >>=20 >> The value '1' represent SIPREC metadata version. This version value >>allows >> the >> SRS to know the exact metadata XML schema sent by the SRC. This document >> describes version 1. Implementations may not interoperate if the >>version >> implemented by the sender is not known by the receiver. No negotiation >>of >> versions is provided. There is no significance to the version number >> although documents which update or obsolete this document (possibly >> including drafts of such documents) should include a higher version >>number >> if the metadata changes in a non-interoperable way. >>=20 >>=20 >>=20 >>=20 >> I don't think a MUST can be used to bind a future document writer. >>=20 >> Brian >>=20 >> On Dec 8, 2012, at 2:46 AM, Parthasarathi R >> wrote: >>=20 >>> The version value >>> MUST be incremented by one in case there is a changed in metadata XML >> schema >>> in the forthcoming draft revision or future updates >>=20 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Tue Dec 11 04:09:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2326F21F8782 for ; Tue, 11 Dec 2012 04:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sLATYRk7pWO for ; Tue, 11 Dec 2012 04:09:58 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B942221F877C for ; Tue, 11 Dec 2012 04:09:57 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5B25123F0526; Tue, 11 Dec 2012 13:09:56 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 13:09:56 +0100 From: "Hutton, Andrew" To: "simon.farrow@stancilcorp.com" Thread-Topic: [siprec] Metadata Thread-Index: AQHN0s9co0NO8bnKMkSqRzD7twg07JgKhRlAgAkF2eA= Date: Tue, 11 Dec 2012 12:09:51 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0138C1B5@MCHP04MSX.global-ad.net> References: <5930422A50B54579887730EB836079A9@VOXSTORSERVER> In-Reply-To: <5930422A50B54579887730EB836079A9@VOXSTORSERVER> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF0138C1B5MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 12:09:59 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF0138C1B5MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for doing that great input. Regards Andy (SIPREC Co-Chair). From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Simon Farrow Sent: 05 December 2012 18:36 To: 'Ram Mohan R (rmohanr)'; siprec@ietf.org Subject: [siprec] Metadata Ram I copied the schema from section 8 from the draft-ieft-siprec-metadata-10.t= xt file (copy included in the text file siprec-metadata-10.txt). I got some= namespace errors I ran xsd.exe over it. I modified it so xsd.exe now works= and I have included it (siprec-metadata-10-SF.txt) as attachment. The salient points are The tns was missing on recording (and other types) type e.g. A couple of xs: were missing from datetime. I appreciate there are a couple of ways of achieving the same results but I= have included mine as a starting point in creating a standardized schema. Simon Farrow Stancil Corporation 2644 South Croddy Way Santa Ana CA 92704 http://www.stancilcorp.com simon.farrow@stancilcorp.com 714-546-2002 ext 4311 --_000_9F33F40F6F2CD847824537F3C4E37DDF0138C1B5MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Simon,

 <= /p>

Thanks for doing that gre= at input.

 <= /p>

Regards=

Andy (SIPREC Co-Chair).

 <= /p>

 <= /p>

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Simon Farrow
Sent: 05 December 2012 18:36
To: 'Ram Mohan R (rmohanr)'; siprec@ietf.org
Subject: [siprec] Metadata

 

Ram=

I copied the schema from section 8 from the draft-ieft-siprec-metadata-10.t= xt file (copy included in the text file siprec-metadata-10.txt). I got some= namespace errors I ran xsd.exe over it. I modified it so xsd.exe now works= and I have included it (siprec-metadata-10-SF.txt) as attachment.

The salient points are

The= tns was missing on recording (and other types) type e.g. <xs:element na= me=3D"recording" type=3D"tns:recording&quo= t;/>

A c= ouple of xs: were missing from datetime.

I appreciate there are a couple of ways of achieving the same results but I= have included mine as a starting point in creating a standardized sch= ema.


Simon Farrow
Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704
http://www.stancilcorp.com
simon.farrow@stancilcorp.c= om
714-546-2002 ext 4311
 

--_000_9F33F40F6F2CD847824537F3C4E37DDF0138C1B5MCHP04MSXglobal_-- From andrew.hutton@siemens-enterprise.com Tue Dec 11 04:31:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B438E21F8647 for ; Tue, 11 Dec 2012 04:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zZztLJmRtsh for ; Tue, 11 Dec 2012 04:31:40 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93421F8661 for ; Tue, 11 Dec 2012 04:31:40 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 59A161EB8428; Tue, 11 Dec 2012 13:31:37 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 13:31:37 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Parthasarathi R , 'Brian Rosen' , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHN11zUo0NO8bnKMkSqRzD7twg07JgTiBMA Date: Tue, 11 Dec 2012 12:31:33 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0138C1F9@MCHP04MSX.global-ad.net> References: <002501cdd6fe$24081880$6c184980$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indicator consensus? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 12:31:41 -0000 I am also ok with the latest text. Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: 11 December 2012 05:03 > To: Parthasarathi R; 'Brian Rosen'; siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? >=20 > I am fine with the below text. >=20 > Ram >=20 > > On 10/12/12 11:15 PM, "Parthasarathi R" > >wrote: >=20 > >Brian, > > > >Thanks for the quick closure. > > > >Hi all, > > > >Could you please let us know any objection/suggestion to the below > >proposed > >text in a week time. > > > >Thanks > >Partha > > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: Monday, December 10, 2012 10:59 PM > >To: Parthasarathi R > >Cc: siprec@ietf.org > >Subject: Re: [siprec] Metadata version indicator consensus? > > > >I'm happy with the reword. > > > >I do think you can use "should" where we are not defining protocol > >behavior. > > > >I should think so anyway :) > > > >Brian > >On Dec 10, 2012, at 12:24 PM, Parthasarathi R > > >wrote: > > > >> Brian, > >> > >> Thanks for your suggested text. In case it is not recommended to use > >"MUST" > >> for future document writer, I'm fine. I have only one concern in the > >> suggested text. The last statement words "in a non-interoperable > way" > >seems > >> to indicate some kind of backward-compatibility which has to be > ensured > >>in > >> the draft for interoperable changes in XML schema. I agree with your > >> suggestion except for the last 5 words and the updated text will > look > >like: > >> > >> " The value '1' represent SIPREC metadata version. This version > value > >allows > >> the SRS to know the exact metadata XML schema sent by the SRC. This > >document > >> describes version 1. Implementations may not interoperate if the > >>version > >> implemented by the sender is not known by the receiver. No > negotiation > >>of > >> versions is provided. There is no significance to the version > number > >> although documents which update or obsolete this document (possibly > >> including drafts of such documents) should include a higher version > >>number > >> if the metadata XML schema changes." > >> > >> I'm not very clear how to qualify whether the updated XML schema is > >backward > >> compatible with earlier XML schema. Please let me know your opinion > on > >>the > >> same. > >> > >> Also, I'm not sure whether lowercase "should" keyword is allowed > within > >> standard track document and I'll run IETF nits tool with the text to > >confirm > >> my doubt. > >> > >> Thanks > >> Partha > >> > >> > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Monday, December 10, 2012 8:19 PM > >> To: Parthasarathi R > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Metadata version indicator consensus? > >> > >> may I suggest: > >> > >> The value '1' represent SIPREC metadata version. This version value > >>allows > >> the > >> SRS to know the exact metadata XML schema sent by the SRC. This > document > >> describes version 1. Implementations may not interoperate if the > >>version > >> implemented by the sender is not known by the receiver. No > negotiation > >>of > >> versions is provided. There is no significance to the version > number > >> although documents which update or obsolete this document (possibly > >> including drafts of such documents) should include a higher version > >>number > >> if the metadata changes in a non-interoperable way. > >> > >> > >> > >> > >> I don't think a MUST can be used to bind a future document writer. > >> > >> Brian > >> > >> On Dec 8, 2012, at 2:46 AM, Parthasarathi R > > >> wrote: > >> > >>> The version value > >>> MUST be incremented by one in case there is a changed in metadata > XML > >> schema > >>> in the forthcoming draft revision or future updates > >> > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Dec 11 19:10:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2FA21F8858 for ; Tue, 11 Dec 2012 19:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73v6pRNjbHvK for ; Tue, 11 Dec 2012 19:10:24 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D300121F8842 for ; Tue, 11 Dec 2012 19:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21698; q=dns/txt; s=iport; t=1355281824; x=1356491424; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=TUloWpKqAaf5yUqj//6GRZCS+F4zT31qMjcfZ7FEok8=; b=RTtH55NO6w1kUtw48vRtbRK9vEXX8eDLTQJsb7uudtU4NwFYI0yVPzkz a65rHkMU6dgRHjmI/KYZN/pgQGvRn3e1Yk1gER8uTOeOo/bIn7ShnTfpA HUF+IUf40DBhtlA93euDQCm8g+YsP7dJvMPeJALIh6QFtg7+tMB419xI6 8=; X-Files: siprec-metadata-10-SF.txt, siprec-metadata-10.txt : 6580, 6533 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEP1x1CtJXHB/2dsb2JhbABCA75wFnOCHgEBAQMBJy4WDgUNAQgRBAEBCx0JMBQJCAIEAQ0FCAaHfQYMrVSOJYxKG3qCTWEDjwOXTIJmDYFmBxcGGA X-IronPort-AV: E=Sophos;i="4.84,264,1355097600"; d="txt'?scan'208";a="151971089" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 12 Dec 2012 03:10:22 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBC3AMqN010741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 03:10:22 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.177]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 21:10:22 -0600 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "simon.farrow@stancilcorp.com" , "siprec@ietf.org" Thread-Topic: [siprec] Metadata Thread-Index: AQHN2BY4MH82pNUlekq2HgNWliXyrg== Date: Wed, 12 Dec 2012 03:10:21 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0138C1B5@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.59] Content-Type: multipart/mixed; boundary="_003_E92E67B176B8B64D8D3A8F5E44E9D8F414B789xmbalnx05ciscocom_" MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 03:10:41 -0000 --_003_E92E67B176B8B64D8D3A8F5E44E9D8F414B789xmbalnx05ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <1A9555E198D63046B4084B1EB59CA7C2@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for your inputs and for validating the fixing the nits. All, Here are the changes proposed by Simon. Please let me know if any one has concerns.=20 Note: As I am not an XML expert I cross checked these modifications with Joe Hildebrand and Peter Saint-Andre here in Cisco to understand the impact. Their feedback is " as long as the element name + namespace URI is known to not collide with anything else that group has done, it's fine to put them in the same namespace" and since there are no collisions here we should be fine. I have also copied them here in this mail to help us with any questions this WG has. Gist of the changes proposed by Simon: Replaced by The types of elements (e.g dataMode, group, session, stream, participant) are all defined as type=3D"tns:". In the earlier version it was type=3D"element_name". =20 Please let me know if any one has concerns in the above changes. Otherwise I will incorporate these in the next revision of the draft. Regards, Ram PS: Attached the original schema (siprec-metadata-10) as well as modified one(siprec-metadata-10-SF) > On 11/12/12 5:39 PM, "Hutton, Andrew" > wrote: >Hi Simon, >=20 >Thanks for doing that great input. >=20 >Regards >Andy (SIPREC Co-Chair). >=20 >=20 >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >On Behalf Of Simon Farrow >Sent: 05 December 2012 18:36 >To: 'Ram Mohan R (rmohanr)'; siprec@ietf.org >Subject: [siprec] Metadata > > >=20 >Ram > >I copied the schema from section 8 from the >draft-ieft-siprec-metadata-10.txt file (copy included in the text file >siprec-metadata-10.txt). I got some namespace errors I ran xsd.exe over >it. I modified it so xsd.exe now works and I have included it >(siprec-metadata-10-SF.txt) > as attachment. > >The salient points are >The tns was missing on recording (and other types) type e.g. name=3D"recording" type=3D"tns:recording"/> >A couple of xs: were missing from datetime. > >I appreciate there are a couple of ways of achieving the same results but >I have included mine as a starting point in creating a standardized >schema. > > >Simon Farrow >Stancil Corporation >2644 South Croddy Way >Santa Ana >CA 92704 >http://www.stancilcorp.com >simon.farrow@stancilcorp.com >714-546-2002 ext 4311 > =20 > > > --_003_E92E67B176B8B64D8D3A8F5E44E9D8F414B789xmbalnx05ciscocom_ Content-Type: text/plain; name="siprec-metadata-10-SF.txt" Content-Description: siprec-metadata-10-SF.txt Content-Disposition: attachment; filename="siprec-metadata-10-SF.txt"; size=6580; creation-date="Wed, 12 Dec 2012 03:10:21 GMT"; modification-date="Wed, 12 Dec 2012 03:10:21 GMT" Content-ID: <769B7D4F22C0694EAD36400B8B5C4830@cisco.com> Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NICAgPHhzOnNjaGVtYSB0YXJn ZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmVjb3JkaW5nIg0gICAgeG1sbnM6 eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIg0gICAgeG1sbnM6dG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnJlY29yZGluZyINICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVh bGlmaWVkIg0gICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVkIj4NICAgPCEtLSBU aGlzIGltcG9ydCBicmluZ3MgaW4gdGhlIFhNTCBsYW5ndWFnZSBhdHRyaWJ1dGUgeG1sOmxhbmct LT4NICAgPHhzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25h bWVzcGFjZSIvPg0gICA8eHM6ZWxlbWVudCBuYW1lPSJyZWNvcmRpbmciIHR5cGU9InRuczpyZWNv cmRpbmciLz4NICAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InJlY29yZGluZyI+DSAgICAgICA8eHM6 c2VxdWVuY2U+DSAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGF0YW1vZGUiIHR5cGU9InRu czpkYXRhTW9kZSINICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0gICAgICAgICA8eHM6 ZWxlbWVudCBuYW1lPSJncm91cCIgdHlwZT0idG5zOmdyb3VwIg0gICAgICAgICAgICAgICAgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0gICAgICAgICAgIDx4czplbGVtZW50 IG5hbWU9InNlc3Npb24iIHR5cGU9InRuczpzZXNzaW9uIg0gICAgICAgICAgICAgICAgbWluT2Nj dXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0gICAgICAgICAgIDx4czplbGVtZW50IG5h bWU9InBhcnRpY2lwYW50IiB0eXBlPSJ0bnM6cGFydGljaXBhbnQiDSAgICAgICAgICAgICAgICBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DSAgICAgICAgICAgPHhzOmVsZW1l bnQgbmFtZT0ic3RyZWFtIiB0eXBlPSJ0bnM6c3RyZWFtIg0gICAgICAgICAgICAgICBtaW5PY2N1 cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DSAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1l PSJzZXNzaW9ucmVjb3JkaW5nYXNzb2MiDSAgICAgICAgICAgICAgIHR5cGU9InRuczpzZXNzaW9u cmVjb3JkaW5nYXNzb2MiDSAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1 bmJvdW5kZWQiLz4NICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InBhcnRpY2lwYW50c2Vzc2lv bmFzc29jIg0gICAgICAgICAgICAgICB0eXBlPSJ0bnM6cGFydGljaXBhbnRzZXNzaW9uYXNzb2Mi DSAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NICAg ICAgICAgIDx4czplbGVtZW50IG5hbWU9InBhcnRpY2lwYW50c3RyZWFtYXNzb2MiDSAgICAgICAg ICAgICAgIHR5cGU9InRuczpwYXJ0aWNpcGFudHN0cmVhbWFzc29jIg0gICAgICAgICAgICAgICBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DSAgICAgICAgICA8eHM6YW55IG5h bWVzcGFjZT0nIyNvdGhlcicNICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAg ICAgICAgICAgICAgIG1heE9jY3Vycz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJv Y2Vzc0NvbnRlbnRzPSdsYXgnLz4NICAgICAgIDwveHM6c2VxdWVuY2U+DSAgIDwveHM6Y29tcGxl eFR5cGU+DSAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJncm91cCI+DSAgICAgICA8eHM6c2VxdWVu Y2U+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9ImFzc29jaWF0ZS10aW1lIiB0eXBlPSJ4czpk YXRlVGltZSINICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICAgIDx4czplbGVtZW50 IG5hbWU9ImRpc2Fzc29jaWF0ZS10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSINICAgICAgICAgICAg bWluT2NjdXJzPSIwIi8+DSAgICAgICAgPHhzOmFueSBuYW1lc3BhY2U9JyMjb3RoZXInDSAgICAg ICAgICAgICAgICAgICBtaW5PY2N1cnM9JzAnDSAgICAgICAgICAgICAgICAgICBtYXhPY2N1cnM9 J3VuYm91bmRlZCcNICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250ZW50cz0nbGF4Jy8+DSAg ICAgICA8L3hzOnNlcXVlbmNlPg0gICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJncm91cF9pZCIg dHlwZT0ieHM6YmFzZTY0QmluYXJ5Ig0gICAgICAgICAgICB1c2U9InJlcXVpcmVkIi8+DSAgIDwv eHM6Y29tcGxleFR5cGU+DSAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJzZXNzaW9uIj4NICAgICAg IDx4czpzZXF1ZW5jZT4NICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVhc29uIiB0eXBlPSJ4 czpzdHJpbmciDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NICAgICAgICAgPHhzOmVs ZW1lbnQgbmFtZT0iZ3JvdXAtcmVmIiB0eXBlPSJ4czpiYXNlNjRCaW5hcnkiDSAgICAgICAgICAg ICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0gICAgICAgICA8eHM6ZWxlbWVudCBu YW1lPSJzdGFydC10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSINICAgICAgICAgICAgICAgIG1pbk9j Y3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InN0b3At dGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUiDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0iMSIvPg0gICAgICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicNICAg ICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9jY3Vy cz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgnLz4N ICAgICAgIDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InNlc3Npb25f aWQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0g ICA8L3hzOmNvbXBsZXhUeXBlPg0gICA8eHM6Y29tcGxleFR5cGUgbmFtZT0ic2Vzc2lvbnJlY29y ZGluZ2Fzc29jIj4NICAgICAgIDx4czpzZXF1ZW5jZT4NICAgICAgICAgPHhzOmVsZW1lbnQgbmFt ZT0iYXNzb2NpYXRlLXRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIg0gICAgICAgICAgICAgICAgbWlu T2NjdXJzPSIwIi8+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9ImRpc2Fzc29jaWF0ZS10aW1l IiB0eXBlPSJ4czpkYXRlVGltZSINICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0gICAg ICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicNICAgICAgICAgICAgICAgICAgIG1pbk9j Y3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9jY3Vycz0ndW5ib3VuZGVkJw0gICAgICAg ICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgnLz4NICAgICAgIDwveHM6c2VxdWVuY2U+ DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InNlc3Npb25faWQiIHR5cGU9InhzOmJhc2U2NEJp bmFyeSINICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0gICA8L3hzOmNvbXBsZXhUeXBlPg0g ICA8eHM6Y29tcGxleFR5cGUgbmFtZT0icGFydGljaXBhbnQiPg0gICAgICAgPHhzOnNlcXVlbmNl Pg0gICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9Im5hbWVJRCIgdHlwZT0idG5zOm5hbWVJRCIN ICAgICAgICAgICAgIG1heE9jY3Vycz0iMSIvPg0gICAgICAgIDx4czphbnkgbmFtZXNwYWNlPScj I290aGVyJw0gICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPScwJw0gICAgICAgICAgICAgICAg ICAgbWF4T2NjdXJzPSd1bmJvdW5kZWQnDSAgICAgICAgICAgICAgICAgICBwcm9jZXNzQ29udGVu dHM9J2xheCcvPg0gICAgICAgPC94czpzZXF1ZW5jZT4NICAgICAgIDx4czphdHRyaWJ1dGUgbmFt ZT0icGFydGljaXBhbnRfaWQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAgICAgdXNl PSJyZXF1aXJlZCIvPg08L3hzOmNvbXBsZXhUeXBlPg0gICA8eHM6Y29tcGxleFR5cGUgbmFtZT0i cGFydGljaXBhbnRzZXNzaW9uYXNzb2MiPg0gICAgICAgPHhzOnNlcXVlbmNlPg0gICAgICAgPHhz OmVsZW1lbnQgbmFtZT0iYXNzb2NpYXRlLXRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIg0gICAgICAg ICAgICAgICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXNhc3Nv Y2lhdGUtdGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUiDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9 IjAiLz4NICAgICAgICAgPHhzOmFueSBuYW1lc3BhY2U9JyMjb3RoZXInDSAgICAgICAgICAgICAg ICAgICBtaW5PY2N1cnM9JzAnDSAgICAgICAgICAgICAgICAgICBtYXhPY2N1cnM9J3VuYm91bmRl ZCcNICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250ZW50cz0nbGF4Jy8+DSAgICAgICA8L3hz OnNlcXVlbmNlPg0gICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJwYXJ0aWNpcGFudF9pZCIgdHlw ZT0ieHM6YmFzZTY0QmluYXJ5Ig0gICAgICAgICAgICB1c2U9InJlcXVpcmVkIi8+DSAgICAgICA8 eHM6YXR0cmlidXRlIG5hbWU9InNlc3Npb25faWQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINICAg ICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0gICA8L3hzOmNvbXBsZXhUeXBlPg0gICA8eHM6Y29t cGxleFR5cGUgbmFtZT0icGFydGljaXBhbnRzdHJlYW1hc3NvYyI+DSAgICAgICA8eHM6c2VxdWVu Y2U+DSAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ic2VuZCIgdHlwZT0ieHM6YmFzZTY0Qmlu YXJ5Ig0gICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0g ICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InJlY3YiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSIN ICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NICAgICAg ICAgICAgIDx4czplbGVtZW50IG5hbWU9ImFzc29jaWF0ZS10aW1lIiB0eXBlPSJ4czpkYXRlVGlt ZSINICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0gICAgICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iZGlzYXNzb2NpYXRlLXRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIg0gICAgICAgICAgICAg ICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhl cicNICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1h eE9jY3Vycz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSds YXgnLz4NICAgICAgIDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InBh cnRpY2lwYW50X2lkIiB0eXBlPSJ4czpiYXNlNjRCaW5hcnkiDSAgICAgICAgICAgIHVzZT0icmVx dWlyZWQiLz4NICAgPC94czpjb21wbGV4VHlwZT4NICAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InN0 cmVhbSI+DSAgICAgICA8eHM6c2VxdWVuY2U+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9Imxh YmVsIiB0eXBlPSJ4czpzdHJpbmciDSAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0iMSIvPg0gICAgICAgICAgPHhzOmFueSBuYW1lc3BhY2U9JyMjb3RoZXInDSAgICAgICAgICAg ICAgICAgICBtaW5PY2N1cnM9JzAnDSAgICAgICAgICAgICAgICAgICBtYXhPY2N1cnM9J3VuYm91 bmRlZCcNICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250ZW50cz0nbGF4Jy8+DSAgICAgICA8 L3hzOnNlcXVlbmNlPg0gICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJzdHJlYW1faWQiIHR5cGU9 InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0gICAgICAgPHhz OmF0dHJpYnV0ZSBuYW1lPSJzZXNzaW9uX2lkIiB0eXBlPSJ4czpiYXNlNjRCaW5hcnkiLz4NICAg PC94czpjb21wbGV4VHlwZT4NICAgICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJkYXRhTW9kZSI+DSAg ICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0gICAgICAgICAgICA8eHM6 ZW51bWVyYXRpb24gdmFsdWU9ImNvbXBsZXRlIi8+DSAgICAgICAgICAgICAgICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJwYXJ0aWFsIi8+DSAgICAgICAgIDwveHM6cmVzdHJpY3Rpb24+DSAg IDwveHM6c2ltcGxlVHlwZT4NICAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9Im5hbWVJRCI+DSAgICA8 eHM6c2VxdWVuY2U+DSAgICAgIDx4czplbGVtZW50IG5hbWU9Im5hbWUiIHR5cGUgPSJ0bnM6bmFt ZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NICAgIDwveHM6c2VxdWVuY2U+DSAgICA8 eHM6YXR0cmlidXRlIG5hbWU9ImFvciIgdHlwZT0ieHM6YW55VVJJIiB1c2U9InJlcXVpcmVkIi8+ DSAgPC94czpjb21wbGV4VHlwZT4NIDx4czpjb21wbGV4VHlwZSBuYW1lPSJuYW1lIj4NICAgPHhz OnNpbXBsZUNvbnRlbnQ+DSAgICAgICAgPHhzOmV4dGVuc2lvbiBiYXNlPSJ4czpzdHJpbmciPg0g ICAgICAgICA8eHM6YXR0cmlidXRlIHJlZj0ieG1sOmxhbmciIHVzZT0ib3B0aW9uYWwiLz4NICAg ICAgICA8L3hzOmV4dGVuc2lvbj4NICAgICAgIDwveHM6c2ltcGxlQ29udGVudD4NICA8L3hzOmNv bXBsZXhUeXBlPg0gIDwveHM6c2NoZW1hPg== --_003_E92E67B176B8B64D8D3A8F5E44E9D8F414B789xmbalnx05ciscocom_ Content-Type: text/plain; name="siprec-metadata-10.txt" Content-Description: siprec-metadata-10.txt Content-Disposition: attachment; filename="siprec-metadata-10.txt"; size=6533; creation-date="Wed, 12 Dec 2012 03:10:21 GMT"; modification-date="Wed, 12 Dec 2012 03:10:21 GMT" Content-ID: Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NICAgPHhzOnNjaGVtYSB0YXJn ZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmVjb3JkaW5nIg0gICAgeG1sbnM6 dG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnJlY29yZGluZyINICAgIHhtbG5zOnhzPSJodHRw Oi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSINICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVh bGlmaWVkIg0gICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVkIj4NICAgPCEtLSBU aGlzIGltcG9ydCBicmluZ3MgaW4gdGhlIFhNTCBsYW5ndWFnZSBhdHRyaWJ1dGUgeG1sOmxhbmct LT4NICAgPHhzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25h bWVzcGFjZSIvPg0gICA8eHM6ZWxlbWVudCBuYW1lPSJyZWNvcmRpbmciIHR5cGU9InJlY29yZGlu ZyIvPg0gICA8eHM6Y29tcGxleFR5cGUgbmFtZT0icmVjb3JkaW5nIj4NICAgICAgIDx4czpzZXF1 ZW5jZT4NICAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkYXRhbW9kZSIgdHlwZT0iZGF0YU1v ZGUiDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NICAgICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iZ3JvdXAiIHR5cGU9Imdyb3VwIg0gICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9InVuYm91bmRlZCIvPg0gICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InNlc3Np b24iIHR5cGU9InNlc3Npb24iDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0idW5ib3VuZGVkIi8+DSAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icGFydGljaXBhbnQi IHR5cGU9InBhcnRpY2lwYW50Ig0gICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCIvPg0gICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InN0cmVhbSIgdHlw ZT0ic3RyZWFtIg0gICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3Vu ZGVkIi8+DSAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzZXNzaW9ucmVjb3JkaW5nYXNzb2Mi DSAgICAgICAgICAgICAgIHR5cGU9InNlc3Npb25yZWNvcmRpbmdhc3NvYyINICAgICAgICAgICAg ICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0gICAgICAgICAgPHhzOmVs ZW1lbnQgbmFtZT0icGFydGljaXBhbnRzZXNzaW9uYXNzb2MiDSAgICAgICAgICAgICAgIHR5cGU9 InBhcnRpY2lwYW50c2Vzc2lvbmFzc29jIg0gICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0idW5ib3VuZGVkIi8+DSAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJwYXJ0aWNp cGFudHN0cmVhbWFzc29jIg0gICAgICAgICAgICAgICB0eXBlPSJwYXJ0aWNpcGFudHN0cmVhbWFz c29jIg0gICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ DSAgICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicNICAgICAgICAgICAgICAgICAg IG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9jY3Vycz0ndW5ib3VuZGVkJw0g ICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgnLz4NICAgICAgIDwveHM6c2Vx dWVuY2U+DSAgIDwveHM6Y29tcGxleFR5cGU+DSAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJncm91 cCI+DSAgICAgICA8eHM6c2VxdWVuY2U+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9ImFzc29j aWF0ZS10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSINICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+ DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9ImRpc2Fzc29jaWF0ZS10aW1lIiB0eXBlPSJ4czpk YXRlVGltZSINICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICAgPHhzOmFueSBuYW1l c3BhY2U9JyMjb3RoZXInDSAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9JzAnDSAgICAgICAg ICAgICAgICAgICBtYXhPY2N1cnM9J3VuYm91bmRlZCcNICAgICAgICAgICAgICAgICAgIHByb2Nl c3NDb250ZW50cz0nbGF4Jy8+DSAgICAgICA8L3hzOnNlcXVlbmNlPg0gICAgICAgPHhzOmF0dHJp YnV0ZSBuYW1lPSJncm91cF9pZCIgdHlwZT0ieHM6YmFzZTY0QmluYXJ5Ig0gICAgICAgICAgICB1 c2U9InJlcXVpcmVkIi8+DSAgIDwveHM6Y29tcGxleFR5cGU+DSAgIDx4czpjb21wbGV4VHlwZSBu YW1lPSJzZXNzaW9uIj4NICAgICAgIDx4czpzZXF1ZW5jZT4NICAgICAgICAgPHhzOmVsZW1lbnQg bmFtZT0icmVhc29uIiB0eXBlPSJ4czpzdHJpbmciDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9 IjAiLz4NICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZ3JvdXAtcmVmIiB0eXBlPSJ4czpiYXNl NjRCaW5hcnkiDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0g ICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzdGFydC10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSIN ICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DSAgICAgICAgIDx4 czplbGVtZW50IG5hbWU9InN0b3AtdGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUiDSAgICAgICAgICAg ICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0gICAgICAgICAgICA8eHM6YW55IG5h bWVzcGFjZT0nIyNvdGhlcicNICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAg ICAgICAgICAgICAgIG1heE9jY3Vycz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJv Y2Vzc0NvbnRlbnRzPSdsYXgnLz4NICAgICAgIDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0 cmlidXRlIG5hbWU9InNlc3Npb25faWQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAg ICAgdXNlPSJyZXF1aXJlZCIvPg0gICA8L3hzOmNvbXBsZXhUeXBlPg0gICA8eHM6Y29tcGxleFR5 cGUgbmFtZT0ic2Vzc2lvbnJlY29yZGluZ2Fzc29jIj4NICAgICAgIDx4czpzZXF1ZW5jZT4NICAg ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iYXNzb2NpYXRlLXRpbWUiIHR5cGU9ImRhdGVUaW1lIg0g ICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICAgIDx4czplbGVtZW50IG5hbWU9 ImRpc2Fzc29jaWF0ZS10aW1lIiB0eXBlPSJkYXRlVGltZSINICAgICAgICAgICAgICAgIG1pbk9j Y3Vycz0iMCIvPg0gICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicNICAgICAgICAg ICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9jY3Vycz0ndW5i b3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgnLz4NICAgICAg IDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InNlc3Npb25faWQiIHR5 cGU9InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0gICA8L3hz OmNvbXBsZXhUeXBlPg0gICA8eHM6Y29tcGxleFR5cGUgbmFtZT0icGFydGljaXBhbnQiPg0gICAg ICAgPHhzOnNlcXVlbmNlPg0gICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9Im5hbWVJRCIgdHlw ZT0ibmFtZUlEIg0gICAgICAgICAgICAgbWF4T2NjdXJzPSIxIi8+DSAgICAgICAgPHhzOmFueSBu YW1lc3BhY2U9JyMjb3RoZXInDSAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9JzAnDSAgICAg ICAgICAgICAgICAgICBtYXhPY2N1cnM9J3VuYm91bmRlZCcNICAgICAgICAgICAgICAgICAgIHBy b2Nlc3NDb250ZW50cz0nbGF4Jy8+DSAgICAgICA8L3hzOnNlcXVlbmNlPg0gICAgICAgPHhzOmF0 dHJpYnV0ZSBuYW1lPSJwYXJ0aWNpcGFudF9pZCIgdHlwZT0ieHM6YmFzZTY0QmluYXJ5Ig0gICAg ICAgICAgICB1c2U9InJlcXVpcmVkIi8+DTwveHM6Y29tcGxleFR5cGU+DSAgIDx4czpjb21wbGV4 VHlwZSBuYW1lPSJwYXJ0aWNpcGFudHNlc3Npb25hc3NvYyI+DSAgICAgICA8eHM6c2VxdWVuY2U+ DSAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJhc3NvY2lhdGUtdGltZSIgdHlwZT0ieHM6ZGF0ZVRp bWUiDSAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NICAgICAgIDx4czplbGVtZW50IG5h bWU9ImRpc2Fzc29jaWF0ZS10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSINICAgICAgICAgICAgICAg IG1pbk9jY3Vycz0iMCIvPg0gICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicNICAg ICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9jY3Vy cz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgnLz4N ICAgICAgIDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InBhcnRpY2lw YW50X2lkIiB0eXBlPSJ4czpiYXNlNjRCaW5hcnkiDSAgICAgICAgICAgIHVzZT0icmVxdWlyZWQi Lz4NICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0ic2Vzc2lvbl9pZCIgdHlwZT0ieHM6YmFzZTY0 QmluYXJ5Ig0gICAgICAgICAgICB1c2U9InJlcXVpcmVkIi8+DSAgIDwveHM6Y29tcGxleFR5cGU+ DSAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJwYXJ0aWNpcGFudHN0cmVhbWFzc29jIj4NICAgICAg IDx4czpzZXF1ZW5jZT4NICAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzZW5kIiB0eXBlPSJ4 czpiYXNlNjRCaW5hcnkiDSAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5i b3VuZGVkIi8+DSAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVjdiIgdHlwZT0ieHM6YmFz ZTY0QmluYXJ5Ig0gICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRl ZCIvPg0gICAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iYXNzb2NpYXRlLXRpbWUiIHR5cGU9 InhzOmRhdGVUaW1lIg0gICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+DSAgICAgICAgICA8 eHM6ZWxlbWVudCBuYW1lPSJkaXNhc3NvY2lhdGUtdGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUiDSAg ICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NICAgICAgICAgICAgIDx4czphbnkgbmFtZXNw YWNlPScjI290aGVyJw0gICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPScwJw0gICAgICAgICAg ICAgICAgICAgbWF4T2NjdXJzPSd1bmJvdW5kZWQnDSAgICAgICAgICAgICAgICAgICBwcm9jZXNz Q29udGVudHM9J2xheCcvPg0gICAgICAgPC94czpzZXF1ZW5jZT4NICAgICAgIDx4czphdHRyaWJ1 dGUgbmFtZT0icGFydGljaXBhbnRfaWQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINICAgICAgICAg ICAgdXNlPSJyZXF1aXJlZCIvPg0gICA8L3hzOmNvbXBsZXhUeXBlPg0gICA8eHM6Y29tcGxleFR5 cGUgbmFtZT0ic3RyZWFtIj4NICAgICAgIDx4czpzZXF1ZW5jZT4NICAgICAgICAgPHhzOmVsZW1l bnQgbmFtZT0ibGFiZWwiIHR5cGU9InhzOnN0cmluZyINICAgICAgICAgICAgIG1pbk9jY3Vycz0i MCIgbWF4T2NjdXJzPSIxIi8+DSAgICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0nIyNvdGhlcicN ICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0nMCcNICAgICAgICAgICAgICAgICAgIG1heE9j Y3Vycz0ndW5ib3VuZGVkJw0gICAgICAgICAgICAgICAgICAgcHJvY2Vzc0NvbnRlbnRzPSdsYXgn Lz4NICAgICAgIDwveHM6c2VxdWVuY2U+DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InN0cmVh bV9pZCIgdHlwZT0ieHM6YmFzZTY0QmluYXJ5Ig0gICAgICAgICAgICB1c2U9InJlcXVpcmVkIi8+ DSAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InNlc3Npb25faWQiIHR5cGU9InhzOmJhc2U2NEJp bmFyeSIvPg0gICA8L3hzOmNvbXBsZXhUeXBlPg0gICAgIDx4czpzaW1wbGVUeXBlIG5hbWU9ImRh dGFNb2RlIj4NICAgICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DSAgICAg ICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iY29tcGxldGUiLz4NICAgICAgICAgICAgICAg ICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9InBhcnRpYWwiLz4NICAgICAgICAgPC94czpyZXN0 cmljdGlvbj4NICAgPC94czpzaW1wbGVUeXBlPg0NICAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9Im5h bWVJRCI+DSAgICA8eHM6c2VxdWVuY2U+DSAgICAgIDx4czplbGVtZW50IG5hbWU9Im5hbWUiIHR5 cGUgPSJuYW1lIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0gICAgPC94czpzZXF1ZW5j ZT4NICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iYW9yIiB0eXBlPSJ4czphbnlVUkkiIHVzZT0icmVx dWlyZWQiLz4NICA8L3hzOmNvbXBsZXhUeXBlPg0NIDx4czpjb21wbGV4VHlwZSBuYW1lPSJuYW1l Ij4NICAgPHhzOnNpbXBsZUNvbnRlbnQ+DSAgICAgICAgPHhzOmV4dGVuc2lvbiBiYXNlPSJ4czpz dHJpbmciPg0gICAgICAgICA8eHM6YXR0cmlidXRlIHJlZj0ieG1sOmxhbmciIHVzZT0ib3B0aW9u YWwiLz4NICAgICAgICA8L3hzOmV4dGVuc2lvbj4NICAgICAgIDwveHM6c2ltcGxlQ29udGVudD4N ICA8L3hzOmNvbXBsZXhUeXBlPg0gIDwveHM6c2NoZW1hPg0= --_003_E92E67B176B8B64D8D3A8F5E44E9D8F414B789xmbalnx05ciscocom_-- From partha@parthasarathi.co.in Wed Dec 12 09:51:54 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B0A21F8A4B for ; Wed, 12 Dec 2012 09:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDuCo+RcXN+X for ; Wed, 12 Dec 2012 09:51:39 -0800 (PST) Received: from outbound-us3.mailhostbox.com (unknown [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2666B21F8A45 for ; Wed, 12 Dec 2012 09:51:29 -0800 (PST) Received: from userPC (unknown [122.166.141.60]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 8744C8687D5; Wed, 12 Dec 2012 17:51:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1355334685; bh=0Sp+/Hy36KeERGqc1WIXaZ1czdYw4qPRtmvfYzD4eoU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=cn0J/aM011a1UCsVlq4tV02tnRxjNDqSsNcFI7Ow8m4iBw5/psjSlEtpJo+nMQ+VO iY5BbWyq8MV+kuFX/PWLy/p7C4qC8Vt/yMrOV9RpVEH4Gj17O1P4iOO1V5A/dXYKkw D6Ln+B8lMYJSWDemt5z0TslzFF7hzrY0cQbxFf0c= From: "Parthasarathi R" To: "'Ofir Roth'" , References: In-Reply-To: Date: Wed, 12 Dec 2012 23:21:18 +0530 Message-ID: <001e01cdd891$4c182240$e44866c0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CDD8BF.65D05E40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3CYSm52tsPv4kmSliQkSP55TZcVwWL6OLg Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0203.50C8C41D.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] draft-ram-siprec-callflows-02 - review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:51:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01CDD8BF.65D05E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ofir, Sorry for the delay response. Thanks a lot for your detailed review. All your reviews comments in the below are accepted and the proposed changes in the comments will be incorporated in the next revision. Please let us know any other comments in the callflow. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, November 14, 2012 6:00 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-callflows-02 - review Hi, I have reviewed "draft-ram-siprec-callflows-02" and have some comments: 1. dataMode element name is not compliant with metadata schema V8/9 - should be datamode. 2. Participantsessionassoc in the initial metadata (simple call) is missing session ID (the same for the first transfer scenario). 3. Section 3.3/resume - " The snapshot will look pretty much same as above with just the SDP" - metadata should also include two of the "send" streams (audio/video) to indicate that the streams are open on both channels and not only SDP change as stated above (similar to the initial complete metadata snapshot). 4. Section 3.6 - the last stream is redundant (EiXGlc+4TruqqoDaNE76ag==) - not in use and can be removed from the metadata. Thanks, Ofir. ------=_NextPart_000_001F_01CDD8BF.65D05E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

Sorry for the delay = response. Thanks a lot for your detailed review.

 

All your reviews = comments in the below are accepted and the proposed changes in the comments will be incorporated in the next revision.

 

Please let us know = any other comments in the callflow.

 

Thanks

Partha

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Wednesday, November 14, 2012 6:00 PM
To: siprec@ietf.org
Subject: [siprec] draft-ram-siprec-callflows-02 - = review

 

Hi,

 

I have reviewed = "draft-ram-siprec-callflows-02" and have some comments:

 

1.       dataMode element = name is not compliant with metadata schema V8/9 – should be = datamode.

2.       Participantsessionassoc = in the initial metadata (simple call) is missing session ID (the same for the = first transfer scenario).

3.       Section 3.3/resume = – " The snapshot will look pretty much same as above with just the SDP" – metadata should also include two of the "send" streams (audio/video) to indicate that the streams are open on both channels and = not only SDP change as stated above (similar to the initial complete = metadata snapshot).

4.       Section 3.6 – the = last stream is redundant (EiXGlc+4TruqqoDaNE76ag=3D=3D) – not in use = and can be removed from the metadata.

 

Thanks,
Ofir.

------=_NextPart_000_001F_01CDD8BF.65D05E40-- From andrew.hutton@siemens-enterprise.com Mon Dec 17 06:51:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3E21F8B0F for ; Mon, 17 Dec 2012 06:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ3p-CmGUObt for ; Mon, 17 Dec 2012 06:51:47 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E76BC21F8B0D for ; Mon, 17 Dec 2012 06:51:44 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 564691EB8499 for ; Mon, 17 Dec 2012 15:51:43 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Mon, 17 Dec 2012 15:51:43 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: WGLC on draft-ietf-siprec-architecture - Ends Thread-Index: AQHN3GYHQRvDAIkF4keCb+SyZgcGPw== Date: Mon, 17 Dec 2012 14:51:32 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01395590@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013710D9@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013710D9@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture - Ends X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:51:50 -0000 Hi All, The WGLC period for draft-ietf-siprec-architecture-07 has finished. There was only one change to the draft proposed during the WGLC which was a= small editorial comment regarding the use of "RTP" and "RTP/RTCP" in the d= iagrams which we should of course clean up.=20 A few more posts indicating support for the draft progressing would have be= en nice but we have had no major open issues for a while now and since this= was the 2nd WGLC anyway the chairs believe that we can go ahead and send t= he document to the IESG. Regards Andy (SIPREC Co-Chair). From partha@parthasarathi.co.in Mon Dec 17 17:33:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D3021F84ED for ; Mon, 17 Dec 2012 17:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttFxjUcGy3tJ for ; Mon, 17 Dec 2012 17:33:31 -0800 (PST) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id D787321F84E9 for ; Mon, 17 Dec 2012 17:33:30 -0800 (PST) Received: from userPC (unknown [122.179.45.41]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 1DC5B3E1D33; Tue, 18 Dec 2012 01:33:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1355794410; bh=xF1bkchvz3a8wf+lIfqKgm9b9DuB65Ady8ptNo99GgA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=nk7qaNY9BMh+Ct1OpuFVz2lnU7YQGDXTw819IxW9TIUZfS+XY+G/szI8TeCehCJqP 1csSS3Ij3hB0fGkyOZVEIkPYxcVwbd3BnwtP/9DImBddJOSBRwDmzgLhVTr+H70vhS QIiasoM5yngxUmnoWtdWzzgqlseEjHLdoq9ir0xo= From: "Parthasarathi R" To: "'Ofir Roth'" , References: In-Reply-To: Date: Tue, 18 Dec 2012 07:03:17 +0530 Message-ID: <002701cddcbf$aa7f34e0$ff7d9ea0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CDDCED.C43770E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2zynxdRKOUTh63RHKy7nJybQgSoAOb3pugBfc4CsA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0206.50CFC7E9.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Metadata V8 - Consult Transfer Scenario X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 01:33:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01CDDCED.C43770E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ofir, =20 Thanks for the call transfer metadata XML messages. My comments in the = metadata is as follows: =20 1) In case of Call Hold, participantstreamassoc with send direction = also has to be shown. The updated partial update for call Hold will look = like this: =20 =EF=BB=BF partial RkhVRE1NUk9SQ1pLT0tIUA=3D=3D RkhVRE1NUk9SQ1pLT0tIUA=3D=3D =20 2) Also, here the stream association looks like = =E2=80=9Cbob=E2=80=9D puts music on hold (sendonly) to the = =E2=80=9Calice=E2=80=9D but the title mentions as = =E2=80=9CAlice=E2=80=9D held the call. The change has to be done in the = text or stream direction? 3) In case of Alice consult with Joe, there should no new = associated time for group as the group is associated with the recording = session already. Even group element is not required to be passed. = Group-ref should be sufficient. In Bob & Joe are talking metadata: 4) Joe is not associated with session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D 5) Alice is not disassociated with session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D 6) Stream 1 & 2 are not disassociated from session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D 7) Participantsessionassoc =E2=80=9CREFEWFRBT1FVSVpDTFVTUQ=3D=3D = =E2=80=9C is associated with = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D initially itself and = there is no need to associated again 8) We need to discuss whether Bob & Joe session has to be separate = from the original session. =20 I=E2=80=99m providing this comments to start the discussion. The other = alternative approach with =E2=80=9Ccomplete=E2=80=9D metadata for the = conversation between Alice & Joe, Bob & Joe shall be discussed later = based on further discussion. =20 Thanks Partha =20 =20 =20 =20 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Ofir Roth Sent: Wednesday, November 14, 2012 1:03 PM To: siprec@ietf.org Subject: Re: [siprec] Metadata V8 - Consult Transfer Scenario =20 Hi, =20 I did not get any feedback about the consult transfer scenario.=20 Is it still needed?=20 =20 Thanks, Ofir. =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Ofir Roth Sent: Saturday, October 27, 2012 12:42 AM To: siprec@ietf.org Subject: [siprec] Metadata V8 - Consult Transfer Scenario =20 Hi, =20 I have created a simple metadata consult transfer scenario (attached).=20 =20 The scenario is simple consult transfer scenario: 1. Alice calls to Bob, Bob answer (first metadata update) =20 2. Alice hold the call with Bob (second metadata update) 3. Alice consults with Joe (third metadata update) 4. Bob and Joe are talking (fourth metadata update) =20 Will be happy to get comments on the metadata call flow.=20 Note: I have dropped the SDP from the example for the sake of = simplicity. Once confirmed as a valid metadata flow, I will update it = with the SDP. =20 Thanks, Ofir Roth. ------=_NextPart_000_0028_01CDDCED.C43770E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

Thanks for the call = transfer metadata XML messages. My comments in the metadata is as = follows:

 

1)      In case of = Call Hold, participantstreamassoc with send direction also has to be shown. = The updated partial update for call Hold will look like = this:

 

<!-- Alice held = the call -->

=EF=BB=BF<?xml version=3D"1.0" = encoding=3D"utf-8"?>

<recording = xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:xsd=3D"http://www.w3.org/2001/XMLSchem= a" xmlns=3D"urn:ietf:params:xml:ns:recording">

=C2=A0 <datamode>partial</datamode>

=C2=A0 = <participantstreamassoc participant_id=3D"WkNJR0hBQVdYUlpLQUtHQw=3D=3D"><= /span>

=C2=A0=C2=A0=C2=A0 <recv>RkhVRE1NUk9SQ1pLT0tIUA=3D=3D</recv>

=C2=A0 </participantstreamassoc>

<participantstreamassoc participant_id=3D"REFEWFRBT1FVSVpDTFVTUQ=3D=3D"><= /span>

=C2=A0=C2=A0=C2=A0 <send>RkhVRE1NUk9SQ1pLT0tIUA=3D=3D</send>

=C2=A0 </participantstreamassoc>

</recording>

 

2)      Also, here = the stream association looks like =E2=80=9Cbob=E2=80=9D puts music on hold = (sendonly) to the =E2=80=9Calice=E2=80=9D but the title mentions as = =E2=80=9CAlice=E2=80=9D held the call. The change has to be done in the text or stream direction?

3)      In case of = Alice consult with Joe, there should no new associated time for group as the = group is associated with the recording session already. Even group element is not required to be passed. Group-ref should be = sufficient.

In Bob & Joe are = talking metadata:

4)      Joe is not associated with session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D

5)      Alice is = not disassociated with session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D

6)      Stream 1 = & 2 are not disassociated from session = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D

7)      Participantsessionassoc =C2=A0=E2=80=9CREFEWFRBT1FVSVpDTFVTUQ=3D=3D =E2=80=9C is associated with = =E2=80=9CSlBGUk5BVVZOTFBQU05ITA=3D=3D=E2=80=9D initially itself and there is no need to associated again

8)      We need to = discuss whether Bob & Joe session has to be separate from the original = session.

 

I=E2=80=99m providing = this comments to start the discussion. The other alternative approach with = =E2=80=9Ccomplete=E2=80=9D metadata for the conversation between Alice & Joe, Bob & Joe shall be = discussed later based on further discussion.

 

Thanks

Partha

 

 

 

 

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Wednesday, November 14, 2012 1:03 PM
To: siprec@ietf.org
Subject: Re: [siprec] Metadata V8 - Consult Transfer = Scenario

 

Hi,

 

I did not get any = feedback about the consult transfer scenario.

Is it still needed? =

 

Thanks,

Ofir.

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Saturday, October 27, 2012 12:42 AM
To: siprec@ietf.org
Subject: [siprec] Metadata V8 - Consult Transfer = Scenario

 

Hi,

 

I have created a simple metadata consult transfer = scenario (attached).

 

The scenario is simple consult transfer = scenario:

1.       Alice calls to Bob, Bob answer (first metadata = update)  

2.       Alice hold the call with Bob (second metadata = update)

3.       Alice consults with Joe (third metadata = update)

4.       Bob and Joe are talking (fourth metadata = update)

 

Will be happy to get comments on the metadata call = flow.

Note: I have dropped the SDP from the example for = the sake of simplicity. Once confirmed as a valid metadata flow, I will update it = with the SDP.

 

Thanks,
Ofir Roth.

------=_NextPart_000_0028_01CDDCED.C43770E0--