From DAVE.HIGTON@nice.com Thu Nov 1 02:56:55 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 93F6321F8585 for ; Thu, 1 Nov 2012 02:56:55 -0700 (PDT) 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 igDLiI2vyECE for ; Thu, 1 Nov 2012 02:56:55 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9321F8528 for ; Thu, 1 Nov 2012 02:56:53 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Thu, 1 Nov 2012 09:56:52 +0000 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 09:56:52 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Thu, 1 Nov 2012 09:56:51 +0000 From: "Dave Higton" To: "Charles Eckel \(eckelcu\)" , Date: Thu, 1 Nov 2012 09:56:51 +0000 Thread-Topic: support for multiple m-lines Content-Class: urn:content-classes:message Importance: normal Priority: normal Thread-Index: Ac22vj5wBR3g0hdZTjWqjoea7ubQ9QBWKiDA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B694055EE15CB4@SOUEXC01.eu.nice.com> References: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> 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: 01 Nov 2012 09:56:52.0347 (UTC) FILETIME=[37CBBCB0:01CDB817] Subject: Re: [siprec] support for multiple m-lines 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, 01 Nov 2012 09:56:55 -0000 It is not the business of the SIPREC protocol document to specify how = many streams a system must be capable of recording. That is dependent = on the end user's system requirements. Capabilities should be = determined and negotiated as part of a contract between supplier and = customer. Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Charles Eckel (eckelcu) Sent: 30 October 2012 16:47 To: siprec@ietf.org Subject: [siprec] support for multiple m-lines At IETF 84, we had some discussion about an SRC using multiple m-lines. = As a simple example, when recording an audio only point to point call, = an SRC may offer 2 audio m-lines to the SRS, using one m-line for each = participant audio stream. The current text in the protocol draft is as follows: When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated. The consensus from the room at the time was to add a requirement for the = SRS to support a minimum number of m-lines. Here are some options: a) SRS MUST support at least two audio m-lines (sufficient for audio = only point to point call without any mixing or multiplexing) b) SRS MUST support at least two audio m-lines and two video m-lines = (sufficient for audio/video point to point call without any mixing or = multiplexing) c) SRS MUST support at least two audio m-lines and three video m-lines = (sufficient for audio/video point to point call without any mixing or = multiplexing, plus a shared content video channel) =20 If we address recording of conferences without mixing or multiplexing, = this number of m-lines grows quickly. For the purpose of the SIPREC protocol document, do people favor adding = an SRS requirement for a, b, or c, or something else. Thanks, Charles _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec 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 eckelcu@cisco.com Fri Nov 2 06:41:23 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 E043E21F8A81 for ; Fri, 2 Nov 2012 06:41:23 -0700 (PDT) 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 lpvOJXTi4yQW for ; Fri, 2 Nov 2012 06:41:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A225721F8A76 for ; Fri, 2 Nov 2012 06:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5801; q=dns/txt; s=iport; t=1351863682; x=1353073282; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Qw8k1MX7fOEha5/asxX/jvV/b6HvgTAgRw5+U/UHxC0=; b=gMZkq1z4rTpFyMmjkietCSaUvlAFQlTmzLsACvobwLG0ewV3stCRAEez +xchUozCoooF6xi0d+kahFcZp/Vjac9WWjQxB5vaSfvx3OSbN/sag9IHS dqRLcE80kSFaj+T115S75a0pQNNZY4ObVeKMw2Li6jHQENVdbc3GInZE9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADTMk1CtJV2Z/2dsb2JhbABEwzWBCIIeAQEBBAEBAQ8BJxoUBhcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCBqHaAubY6AHBIwBFAaFQGEDpFKBa4JvgVsJFx4 X-IronPort-AV: E=Sophos;i="4.80,699,1344211200"; d="scan'208";a="138175556" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2012 13:41:22 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA2DfLaV018662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 13:41:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 08:41:20 -0500 From: "Charles Eckel (eckelcu)" To: Dave Higton , "siprec@ietf.org" Thread-Topic: support for multiple m-lines Thread-Index: Ac22vj5wBR3g0hdZTjWqjoea7ubQ9QBWKiDAADnbwyA= Date: Fri, 2 Nov 2012 13:41:19 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828101189@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> <9B0B6FB9606F4D4AB133C5E9A203B694055EE15CB4@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B694055EE15CB4@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.83] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--51.886100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] support for multiple m-lines 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, 02 Nov 2012 13:41:24 -0000 Personally I share a similar option as Paul and Dave. Here is what the prot= ocol draft currently says: When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated. The reason I started this thread was because there was some concern express= ed regarding this approach at IETF 84. Here is the corresponding section of= the meeting minutes: Protocol document - RTP Usage (Charles) Picture - SRC using multiple m-lines: If SRS does not support, it rejects one or more m-lines, and SRC might choo= se another option. Discussion: Hadriel: Is the question that if it just doesn't support multiple m-lines, = so it just doesn't do anything. Isn't this related to earlier topic that SR= S must support both. I object. .. Hadriel: suggest that "Minimally must support multiple m-lines up to x numb= er of audio and video." Paul: SIP 101. If you offer multiple m-lines, then the recipient can decide= what to take. Sender can decide then if it wants to send something else. D= on't think we can say anything about this. Maybe the best thing to do is to= publish some examples with "reasonable, common" cases. Charles: what you said is what the draft says. It shows how it works for tw= o. Hadriel: We have a chance to improve interop. Most basic case will have two= audio m-lines, thus should add something for minimal support (e.g., 2 m-li= nes). Conclusion: agree with Hadriel. Text will be crafted. I am happy to drop this and leave the text as is, but perhaps we want to re= visit our discussion on this topic from IETF 84 at IETF 85. Cheers, Charles > -----Original Message----- > From: Dave Higton [mailto:DAVE.HIGTON@nice.com] > Sent: Thursday, November 01, 2012 5:57 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: support for multiple m-lines >=20 > It is not the business of the SIPREC protocol document to specify how man= y > streams a system must be capable of recording. That is dependent on the > end user's system requirements. Capabilities should be determined and > negotiated as part of a contract between supplier and customer. >=20 > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Charles Eckel (eckelcu) > Sent: 30 October 2012 16:47 > To: siprec@ietf.org > Subject: [siprec] support for multiple m-lines >=20 > At IETF 84, we had some discussion about an SRC using multiple m-lines. A= s > a simple example, when recording an audio only point to point call, an SR= C > may offer 2 audio m-lines to the SRS, using one m-line for each participa= nt > audio stream. > The current text in the protocol draft is as follows: >=20 > When using multiple m-lines, an SRC includes each m-line in an SDP > offer to the SRS. The SDP answer from the SRS MUST include all > m-lines, with any rejected m-lines indicated with a zero port, per > [RFC3264]. Having received the answer, the SRC starts sending media > to the SRS as indicated in the answer. Alternatively, if the SRC > deems the level of support indicated in the answer to be > unacceptable, it may initiate another SDP offer/answer exchange in > which an alternative RTP session usage is negotiated. >=20 > The consensus from the room at the time was to add a requirement for the > SRS to support a minimum number of m-lines. Here are some options: >=20 > a) SRS MUST support at least two audio m-lines (sufficient for audio only > point to point call without any mixing or multiplexing) > b) SRS MUST support at least two audio m-lines and two video m-lines > (sufficient for audio/video point to point call without any mixing or > multiplexing) > c) SRS MUST support at least two audio m-lines and three video m-lines > (sufficient for audio/video point to point call without any mixing or > multiplexing, plus a shared content video channel) >=20 > If we address recording of conferences without mixing or multiplexing, th= is > number of m-lines grows quickly. > For the purpose of the SIPREC protocol document, do people favor adding > an SRS requirement for a, b, or c, or something else. >=20 > Thanks, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > NICE Systems UK Limited ("NICE") is registered in England under company > number, 3403044. The registered office of NICE is at Tollbar Way, Hedge E= nd, > Southampton, Hampshire SO30 2ZP. >=20 > 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. >=20 > Monitoring: NICE may monitor incoming and outgoing e-mails. >=20 > Viruses: Although we have taken steps toward ensuring that this e-mail an= d > attachments are free from any virus, we advise that in keeping with good > computing practice the recipient should ensure they are actually virus fr= ee. From Henry.Lum@genesyslab.com Fri Nov 2 07:47:45 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 C709F1F0C49 for ; Fri, 2 Nov 2012 07:47:45 -0700 (PDT) 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 c4mZ3zR0EFte for ; Fri, 2 Nov 2012 07:47:45 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 339361F0C42 for ; Fri, 2 Nov 2012 07:47:45 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id qA2Elec3007048; Fri, 2 Nov 2012 07:47:41 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Nov 2012 07:47:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Nov 2012 07:47:17 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7409614474@NAHALD.us.int.genesyslab.com> In-Reply-To: <5090719D.3070404@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] support for multiple m-lines Thread-Index: Ac22/zjszV+myiilSe2pcu5VWIPzdwCCD6Pw References: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> <5090719D.3070404@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 02 Nov 2012 14:47:18.0862 (UTC) FILETIME=[F538A6E0:01CDB908] Subject: Re: [siprec] support for multiple m-lines 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, 02 Nov 2012 14:47:45 -0000 I agree that we cannot require SRS to support certain media types simply because the product does not want to. I also can't say how practical it is to impose any implementation limit on the number of streams to accept. If the SRC cannot perform mixing and the SRS is unwilling to accept more than one media stream, then it's simply a capability mismatch. The protocol is doing the right thing to allow both sides to properly negotiate and deal with such failure. Similarly, in a CS, if the caller and callee don't support the same media codecs then the SDP negotiation would fail and both sides can deal with the failure. Perhaps we can put some words around this to describe potential side effects and possible failure handling, but I don't think there is much we can mandate in the protocol for these types of scenarios. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: October-30-12 8:32 PM > To: siprec@ietf.org > Subject: Re: [siprec] support for multiple m-lines >=20 > On 10/30/12 12:47 PM, Charles Eckel (eckelcu) wrote: > > At IETF 84, we had some discussion about an SRC using multiple m-lines. As a > simple example, when recording an audio only point to point call, an SRC may > offer 2 audio m-lines to the SRS, using one m-line for each participant audio > stream. > > The current text in the protocol draft is as follows: > > > > When using multiple m-lines, an SRC includes each m-line in an SDP > > offer to the SRS. The SDP answer from the SRS MUST include all > > m-lines, with any rejected m-lines indicated with a zero port, per > > [RFC3264]. Having received the answer, the SRC starts sending media > > to the SRS as indicated in the answer. Alternatively, if the SRC > > deems the level of support indicated in the answer to be > > unacceptable, it may initiate another SDP offer/answer exchange in > > which an alternative RTP session usage is negotiated. > > > > The consensus from the room at the time was to add a requirement for the SRS > to support a minimum number of m-lines. Here are some options: > > > > a) SRS MUST support at least two audio m-lines (sufficient for audio only > point to point call without any mixing or multiplexing) > > b) SRS MUST support at least two audio m-lines and two video m-lines > (sufficient for audio/video point to point call without any mixing or > multiplexing) > > c) SRS MUST support at least two audio m-lines and three video m-lines > (sufficient for audio/video point to point call without any mixing or > multiplexing, plus a shared content video channel) > > > > If we address recording of conferences without mixing or multiplexing, this > number of m-lines grows quickly. > > For the purpose of the SIPREC protocol document, do people favor adding an > SRS requirement for a, b, or c, or something else. >=20 > I'm not sure there is anything useful that we can say. >=20 > You talk about conferences as perhaps needing more m-lines. But there is > also the case of an SRC that wants to record multiple independent CSs > over the same RS. >=20 > Regarding audio vs. video - I don't think we should require video > support, because some plausible products may not want to support it. I > suppose it is also possible to imagine a recorder product that is > intended only to record video (e.g. surveillance) and not audio. >=20 > Clearly there is a problem if the SRS can't record at least the media it > supports for at least one CS. (Or CS-group?) >=20 > For an SRC that is able to record multiple CSs in a single RS, I suppose > we can assume that it will expect there to be *some* limit to how many, > and so it might need to be prepared for rejection of an offer with too > many m-lines. In that case it can have a fallback procedure of > establishing another RS. >=20 > But for a single CS, I the only fallback would be from unmixed streams > to mixed streams. And I suspect many SRCs won't be flexible enough to > make that change. >=20 > So, while it would be nice to have some minimum to implement limit, in > practice I think it might be impractical to impose one. I think this > might be one of those "quality of implementation" issues. At most I > think we might say that an SRS SHOULD be capable of accepting a separate > stream for each participant, for each medium the SRS supports, for as > many CSs and participants as it claims to support. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Nov 2 09:53: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 A063021F86B3 for ; Fri, 2 Nov 2012 09:53:40 -0700 (PDT) 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=[AWL=0.000, 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 LEkQ5e4o1227 for ; Fri, 2 Nov 2012 09:53:40 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E54B721F86A9 for ; Fri, 2 Nov 2012 09:53:39 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 48FC923F055D for ; Fri, 2 Nov 2012 17:53:38 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 17:53:25 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Help the NomCom Thread-Index: AQHNuDCQRpGaudYaIEynp05iSb6qFJfWxKBw Date: Fri, 2 Nov 2012 16:53:23 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01320340@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [siprec] Help the NomCom 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, 02 Nov 2012 16:53:40 -0000 VGhlIElFVEYgTm9taW5hdGlvbnMgQ29tbWl0dGVlIChOb21Db20pIGNvbnRpbnVlcyB0byBzZWVr IGlucHV0IGZyb20NCnRoZSBJRVRGIENvbW11bml0eS4gVGhlIE5vbUNvbSB3b3VsZCBncmVhdGx5 IGFwcHJlY2lhdGUgYW55IGhlbHAgeW91DQpjb3VsZCBwcm92aWRlIGluIG1ha2luZyBtZW1iZXJz IG9mIHlvdXIgd29ya2luZyBncm91cCBhd2FyZSBvZiB3YXlzIGluDQp3aGljaCB0aGV5IGNhbiBw cm92aWRlIHZhbHVhYmxlIGZlZWRiYWNrIHRvIHRoZSBOb21Db20uDQoNCkluIG9yZGVyIHRvIGVu c3VyZSB0aGF0IHlvdXIgaW5wdXQgaXMgcmVjZWl2ZWQgaW4gdGltZSB0byBiZSB1c2VmdWwsIHRo ZSANCk5vbUNvbSBuZWVkcyB0byByZWNlaXZlIGNvbW11bml0eSBmZWVkYmFjayBvbiBvciBiZWZv cmUgU3VuZGF5LCBOb3ZlbWJlciAxMS4NCg0KVGhlIGZpbmFsIGxpc3Qgb2YgY2FuZGlkYXRlcyAo YXMgcGVyIFJGQyA1NjgwKSB0aGF0IHRoZSBOb21Db20gaXMgDQpjb25zaWRlcmluZyBmb3Igb3Bl biBwb3NpdGlvbnMgY2FuIGJlIGZvdW5kIGF0OiANCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3Vw L25vbWNvbS8yMDEyL2lucHV0Lw0KDQpUaGUgTm9tQ29tIHdpbGwgYmUgaG9sZGluZyBvZmZpY2Ug aG91cnMgZHVyaW5nIElFVEYgODUsIE1vbmRheS0NClRodXJzZGF5IGZyb20gMTowMHBtIHRvIDM6 MDBwbSBpbiBSb29tIDMwNS4gVGhlIE5vbUNvbSB3ZWxjb21lcyANCmNvbW1lbnRzIG9uIHNwZWNp ZmljIGluZGl2aWR1YWxzLCBhcyB3ZWxsIGFzIGdlbmVyYWwgZmVlZGJhY2sgcmVsYXRlZCB0byAN CmFueSBvZiB0aGUgcG9zaXRpb25zIHRoYXQgTm9tQ29tIGlzIGNvbnNpZGVyaW5nLg0KDQpOb3Rl OiBBIGxpc3Qgb2YgbGVhZGVyc2hpcCBwb3NpdGlvbnMgdGhhdCB0aGUgTm9tQ29tIGlzIGNvbnNp ZGVyaW5nIGNhbiBiZSANCmZvdW5kIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21j b20vMjAxMi8NCg0KSWYgdGhlIE5vbUNvbSBvZmZpY2UgaG91cnMgYXJlIGluY29udmVuaWVudCBm b3IgeW91IG9yIGlmIHlvdSBjYW5ub3QgDQphdHRlbmQgSUVURiA4NSwgdGhlIE5vbUNvbSBpcyBo YXBweSB0byB0YWtlIGNvbW11bml0eSBpbnB1dCB2aWEgZW1haWwgDQp0byBub21jb20xMiBhdCBp ZXRmLm9yZy4gQWRkaXRpb25hbGx5LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIGFycmFuZ2UgYSAN Cm1lZXRpbmcgb3V0c2lkZSBvZiBvZmZpY2UgaG91cnMsIGp1c3Qgc2VuZCB1cyBlbWFpbCBhbmQg d2UgY2FuIHNldCANCnNvbWV0aGluZyB1cC4NCg0KQ29tbWVudHMgb24gc3BlY2lmaWMgY2FuZGlk YXRlcyBjYW4gYWxzbyBiZSBwcm92aWRlZCB0byB0aGUgTm9tQ29tDQp2aWEgdGhlIHdlYiBmZWVk YmFjayB0b29sOiANCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8yMDEyL2lucHV0 Lw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCwNCi0gTWF0dCBMZXBpbnNraQ0KICBub21jb20t Y2hhaXIgYXQgaWV0Zi5vcmcNCg== From eckelcu@cisco.com Sat Nov 3 10:02: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 6F66721F9C34 for ; Sat, 3 Nov 2012 10:02:03 -0700 (PDT) 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 LqhKFzH6uDNj for ; Sat, 3 Nov 2012 10:02:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 332CB21F9ADF for ; Sat, 3 Nov 2012 10:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5093; q=dns/txt; s=iport; t=1351962122; x=1353171722; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IAOHY0ZstpWtromMHuj6AIS4kozc70Hu7HwshVKbSJo=; b=MrBWiO2Tfw9NKO+CGTkyH5+17YnvNMFAQG+UqeFvth7wvZNBqZYBPUoc DRdPO7XCZAiRQKJrkeY1TtRXsxpAS2d4iPKQc862XpjRYWstkFTWaGqBl ADwpNK8wfOCFNeb4hdSONK82gbAFBl0cGhOzrdMeGRdtH4jI0aYDk0ZXi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC9NlVCtJV2Z/2dsb2JhbABEwzWBCIIeAQEBBAEBAQ8BJzQJDgQCAQgRBAEBCxQJBycLFAgBCAEBBAESCAEZh2gLmV2fTYwBhVthA5cXjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138469999" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 17:02:01 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA3H21JK009021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 17:02:01 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 12:02:00 -0500 From: "Charles Eckel (eckelcu)" To: Parthasarathi R , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Thread-Index: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+QAlkjWwA= Date: Sat, 3 Nov 2012 17:02:00 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> References: <008901cdb07e$78ff0840$6afd18c0$@co.in> In-Reply-To: <008901cdb07e$78ff0840$6afd18c0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--61.032600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.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: Sat, 03 Nov 2012 17:02:03 -0000 Hi draft authors,=20 I read the draft and have a few comments to share. 1) abstract s/model defined the metadata draft/model defined in the metadata draft 2) overview s/not normative on any aspect of SIP/not normative on any aspect of SIPREC 3) Section 3.1 reads, "The following example provides all the tuples ..." IMO, this sounds as if it provides an exhaustive list; however, I do not th= ink that is the intent. Rather, I think it provides an example of metadata = that may be included in a typical metadata body. It would be good to be cle= an on the intent so that the example is read in the proper from of mind. 4) Section 3.1. It would be helpful to explain the call scenario to which t= he metadata example applies. For example, it appears to be a two party cal= l with 4 streams per participant, 2 in each direction (e.g. one for audio a= nd one for video). Alternatively, you can remove this example as it appears= to be a duplicate of the next example (in section 4). 5) Section 4.2 s/Media Streams sent by each participant is received all/Media streams sent= by each participant are received by the s/snippets of SDP is shown/snippets of SDP are shown 6) Section 4.3, example 2, it would be better if you remain consistent with= the participant names (i.e. A/B or Ram/Partha. 7) F4, it would be helpful to explain the inactive and sendonly SDP attribu= tes by adding text explaining that during the hold, A stops sending streams= (inactive), while B continues sending (sendonly). 8) Section 4.4, metadata Is the idea that the streams remain the same and only the participant chang= es? If so, state that. It is hard to tell by visual inspection whether the = stream id is an exact match of perhaps has some small change. Also, I was e= xpecting to see metadata saying the Ram left and providing a disassociation= time. Instead, this is provided only the end of the call. Is that done jus= t in case Ram returns before the end of the call. In any case, it would be = good to state the reasoning so that it is clear why the metadata is as it i= s. 9) Section 4.6, F1 Why does stream =3D=3D stream? Also, how do you indicate when= each person is talking? Is it accomplished using CNAME and SSRC? Cheers, Charles=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Parthasarathi R > Sent: Monday, October 22, 2012 1:56 PM > To: siprec@ietf.org > Subject: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt >=20 > Hi all, >=20 > draft-ram-siprec-callflows-02 is published with the following update: >=20 > 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > 2) Removed Metadata Example section > 3) Incorporated Ofir Rath review comments >=20 > The current open issue in the drafts > 1) Incorporating RS SIP messages with metadata XML messages for all > callflow > 2) Callflows provided by Ofir Rath has to be discussed and added. >=20 > Could you please provide your valuable comments on > draft-ram-siprec-callflows-02. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 22, 2012 11:02 PM > To: partha@parthasarathi.co.in > Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > Subject: New Version Notification for draft-ram-siprec-callflows-02.txt >=20 >=20 > A new version of I-D, draft-ram-siprec-callflows-02.txt > has been successfully submitted by Parthasarathi Ravindran and posted to > the > IETF repository. >=20 > Filename: draft-ram-siprec-callflows > Revision: 02 > Title: Session Initiation Protocol (SIP) Recording Call Flows > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-ram-siprec-cal= lflows- > 02.txt > Status: http://datatracker.ietf.org/doc/draft-ram-siprec-callflo= ws > Htmlized: http://tools.ietf.org/html/draft-ram-siprec-callflows-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-call= flows-02 >=20 > Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document lists call flows that has snapshot > of metadata sent from SRC to SRS, the metadata format for which is > described in [I-D.ietf-siprec-metadata] . This is purely an > informational document that is written to support the model defined > the metadata draft. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Tue Nov 6 01:35: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 A781B21F879B; Tue, 6 Nov 2012 01:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 5Pmfx1t-M64f; Tue, 6 Nov 2012 01:35:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8C21F87A3; Tue, 6 Nov 2012 01:35:08 -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.35 Message-ID: <20121106093508.2336.89219.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 01:35:08 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-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: Tue, 06 Nov 2012 09:35:08 -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 Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-09.txt Pages : 48 Date : 2012-11-06 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Tue Nov 6 01:39:32 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 B3CC221F880A for ; Tue, 6 Nov 2012 01:39:32 -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 5FChhBm-+V-N for ; Tue, 6 Nov 2012 01:39:27 -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 CC8BD21F8683 for ; Tue, 6 Nov 2012 01:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1949; q=dns/txt; s=iport; t=1352194767; x=1353404367; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FpQd/E5kelHX7WomWAWNytrt+5t4KPw9v3jj6okdCi0=; b=Ov++Ql2XspSkf1f7MzQgitPO/9Glet2UUAqgTBja6sTTAQBzzGANcG8z yKrtm5XG08Gopl16xFT7plE4r7t3reEgHP2T1w5NEywlPSpKM0cxaIjTL kdI8EEc0PvFDwGuQqA8yKeP+abUEDAf77JosVPSyX04AArWWXD60/NyC5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO/ZmFCtJV2Y/2dsb2JhbABEwy+BCIIeAQEBAwEBAQEPASc0EA0BCCIUNwslAgQTCAEZh2IGC5lXgSuPZJBIjB2FWmEDlxeNPYFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,721,1344211200"; d="scan'208";a="139269288" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 06 Nov 2012 09:39:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA69dRa3018234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Nov 2012 09:39:27 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 03:39:26 -0600 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-09.txt Thread-Index: AQHNvAKcx1rfKmMPJ0eJVbF5ZWg7yg== Date: Tue, 6 Nov 2012 09:39:25 +0000 Message-ID: In-Reply-To: <20121106093508.2336.89219.idtracker@ietfa.amsl.com> 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.49] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--38.320400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <77EDEC1C6308E749975827DA871528DA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-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: Tue, 06 Nov 2012 09:39:32 -0000 This revision fixes the nits (which were agreed upon but missed to be added to the document) pointed by Ofir Roth some time back Look at http://www.ietf.org/mail-archive/web/siprec/current/msg03481.html for details. Thanks, Authors > On 06/11/12 3:05 PM, "internet-drafts@ietf.org" > wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-09.txt > Pages : 48 > Date : 2012-11-06 > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-siprec-metadata-09 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-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 > From ietf-ipr@ietf.org Tue Nov 6 14:42:21 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 147A121F8BBF; Tue, 6 Nov 2012 14:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 jYf85xIfrVyM; Tue, 6 Nov 2012 14:42:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCD21F8A60; Tue, 6 Nov 2012 14:42:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: leon.portman@nice.com, alan.b.johnston@gmail.com, henry.lum@genesyslab.com, andrew.hutton@siemens-enterprise.com, eckelcu@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 14:42:20 -0800 Cc: andyh@siemens-enterprise.com, siprec@ietf.org, ipr-announce@ietf.org Subject: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 06 Nov 2012 22:42:21 -0000 Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles Eckel: An IPR disclosure that pertains to your Internet-Draft entitled "Session Recording Protocol" (draft-ietf-siprec-protocol) was submitted to the IETF Secretariat on 2012-11-06 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1912/). The = title of the IPR disclosure is "Avaya Inc.'s Statement about IPR related to draft- ietf-siprec-protocol-08.""); The IETF Secretariat From partha@parthasarathi.co.in Wed Nov 7 09:34:51 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 2A37C21F8BDC for ; Wed, 7 Nov 2012 09:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.291, 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 WvZUP23vQij6 for ; Wed, 7 Nov 2012 09:34:50 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 41AC921F8BB5 for ; Wed, 7 Nov 2012 09:34:50 -0800 (PST) Received: from userPC (unknown [122.179.28.144]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 230E4190884E; Wed, 7 Nov 2012 17:34:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1352309689; bh=x/VG0O+B0DwiTyKZzYcRdi6rVgmIDXQ26Kr9CfUDT/0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P2sNkG+FbbIZwFoOiDQorhZ/J5ohQECidSbgzeLHB0BUFGzIHihpabZEwvc8cNfN7 /aP58K6GHYXserEsQaBNuZ6mXQnPTOH17ekMHCmiccfqmMioQmzse/gs6+PdZ6inlT ivDepC/N0B6c4K13GFXNJ33rhkoQXB33gA3LCnr8= From: "Parthasarathi R" To: "'Charles Eckel \(eckelcu\)'" , References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> Date: Wed, 7 Nov 2012 23:04:40 +0530 Message-ID: <003201cdbd0e$2d5ca310$8815e930$@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: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+QAlkjWwAAypQxQA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0204.509A9BB9.00E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.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: Wed, 07 Nov 2012 17:34:51 -0000 Hi Charles, Thanks a lot for your review. Please read inline. Thanks Partha -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: Saturday, November 03, 2012 10:32 PM To: Parthasarathi R; siprec@ietf.org Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Hi draft authors, I read the draft and have a few comments to share. 1) abstract s/model defined the metadata draft/model defined in the metadata draft 2) overview s/not normative on any aspect of SIP/not normative on any aspect of SIPREC I'll updated in the next revision 3) Section 3.1 reads, "The following example provides all the tuples ..." IMO, this sounds as if it provides an exhaustive list; however, I do not think that is the intent. Rather, I think it provides an example of metadata that may be included in a typical metadata body. It would be good to be clean on the intent so that the example is read in the proper from of mind. Text will be updated to indicate the typical metadata body in the next revision. 4) Section 3.1. It would be helpful to explain the call scenario to which the metadata example applies. For example, it appears to be a two party call with 4 streams per participant, 2 in each direction (e.g. one for audio and one for video). Alternatively, you can remove this example as it appears to be a duplicate of the next example (in section 4). Could you explain this comment as Section 4 is security consideration in -02 draft. My guess is that your comment is based on -01 draft. 5) Section 4.2 s/Media Streams sent by each participant is received all/Media streams sent by each participant are received by the s/snippets of SDP is shown/snippets of SDP are shown 6) Section 4.3, example 2, it would be better if you remain consistent with the participant names (i.e. A/B or Ram/Partha. 7) F4, it would be helpful to explain the inactive and sendonly SDP attributes by adding text explaining that during the hold, A stops sending streams (inactive), while B continues sending (sendonly). 5, 6, 7 comments will be incorporated in the next revision 8) Section 4.4, metadata Is the idea that the streams remain the same and only the participant changes? If so, state that. It is hard to tell by visual inspection whether the stream id is an exact match of perhaps has some small change. Also, I was expecting to see metadata saying the Ram left and providing a disassociation time. Instead, this is provided only the end of the call. Is that done just in case Ram returns before the end of the call. In any case, it would be good to state the reasoning so that it is clear why the metadata is as it is. 9) Section 4.6, F1 Why does stream == stream? Because it is mixed stream. There is no way to distinguish the directionality of the individual participants. Also, how do you indicate when each person is talking? It is possible that the information may be lost at SRC itself Is it accomplished using CNAME and SSRC? I'm not sure whether CNAME & SSRC will help for mixed stream Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Parthasarathi R > Sent: Monday, October 22, 2012 1:56 PM > To: siprec@ietf.org > Subject: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt > > Hi all, > > draft-ram-siprec-callflows-02 is published with the following update: > > 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > 2) Removed Metadata Example section > 3) Incorporated Ofir Rath review comments > > The current open issue in the drafts > 1) Incorporating RS SIP messages with metadata XML messages for all > callflow > 2) Callflows provided by Ofir Rath has to be discussed and added. > > Could you please provide your valuable comments on > draft-ram-siprec-callflows-02. > > Thanks > Partha > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 22, 2012 11:02 PM > To: partha@parthasarathi.co.in > Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > Subject: New Version Notification for draft-ram-siprec-callflows-02.txt > > > A new version of I-D, draft-ram-siprec-callflows-02.txt > has been successfully submitted by Parthasarathi Ravindran and posted to > the > IETF repository. > > Filename: draft-ram-siprec-callflows > Revision: 02 > Title: Session Initiation Protocol (SIP) Recording Call Flows > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > 02.txt > Status: http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > Htmlized: http://tools.ietf.org/html/draft-ram-siprec-callflows-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ram-siprec-callflows-02 > > Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document lists call flows that has snapshot > of metadata sent from SRC to SRS, the metadata format for which is > described in [I-D.ietf-siprec-metadata] . This is purely an > informational document that is written to support the model defined > the metadata draft. > > > > > The IETF Secretariat > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Wed Nov 7 09:53:12 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 058CA21F8A72 for ; Wed, 7 Nov 2012 09:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.412 X-Spam-Level: X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=1.188, 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 2a+xzkGY4LRR for ; Wed, 7 Nov 2012 09:53:10 -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 B62AA21F8792 for ; Wed, 7 Nov 2012 09:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7063; q=dns/txt; s=iport; t=1352310790; x=1353520390; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xTwn7PiVCutbHFduuNiMZgJ5j3MdsF2fPWZ2Cpkn2aM=; b=EtGrSlXZ8rlMPynS3erJ4jlhWHgHFiJw6HdXAi2BOSVga50j70p3B3y6 IF0rwk2dPj3Jhu4eagl2ORJE0QWn09R0BFjhTlj1GNXDyNLRWTFcUDSSl a3x/bBN96ollaGqUaMpla2FDy9N0EofNaKYuBF6MFFyuez5n6trbrQWDk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANmemlCtJXG+/2dsb2JhbABEw2GBCIIeAQEBAwEBAQEPASc0CQcHBAIBCBEEAQELFAkHJwsUCAEIAQEEARIIARmHYgYLnD6gMowNhWZhA5cXjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139606979" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2012 17:53:10 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA7HrAhs001576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 17:53:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 11:53:09 -0600 From: "Charles Eckel (eckelcu)" To: Parthasarathi R , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt Thread-Index: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+QAlkjWwAAypQxQAABAqcw Date: Wed, 7 Nov 2012 17:53:09 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882811E8AA@xmb-aln-x08.cisco.com> References: <008901cdb07e$78ff0840$6afd18c0$@co.in> <92B7E61ADAC1BB4F941F943788C088281041F4@xmb-aln-x08.cisco.com> <003201cdbd0e$2d5ca310$8815e930$@co.in> In-Reply-To: <003201cdbd0e$2d5ca310$8815e930$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--83.563500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.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: Wed, 07 Nov 2012 17:53:12 -0000 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Wednesday, November 07, 2012 12:35 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification for draft-ram-siprec- > callflows-02.txt >=20 > Hi Charles, >=20 > Thanks a lot for your review. Please read inline. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: Saturday, November 03, 2012 10:32 PM > To: Parthasarathi R; siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification for > draft-ram-siprec-callflows-02.txt >=20 > Hi draft authors, >=20 > I read the draft and have a few comments to share. >=20 > 1) abstract > s/model defined the metadata draft/model defined in the metadata draft >=20 > 2) overview > s/not normative on any aspect of SIP/not normative on any aspect of SIPRE= C >=20 > I'll updated in the next revision >=20 > 3) Section 3.1 reads, "The following example provides all the tuples ..." > IMO, this sounds as if it provides an exhaustive list; however, I do not > think that is the intent. Rather, I think it provides an example of metad= ata > that may be included in a typical metadata body. It would be good to be > clean on the intent so that the example is read in the proper from of min= d. >=20 > Text will be updated to indicate the typical metadata body in th= e > next revision. >=20 > 4) Section 3.1. It would be helpful to explain the call scenario to which > the metadata example applies. For example, it appears to be a two party > call with 4 streams per participant, 2 in each direction (e.g. one for au= dio > and one for video). Alternatively, you can remove this example as it appe= ars > to be a duplicate of the next example (in section 4). > Could you explain this comment as Section 4 is security > consideration in -02 draft. My guess is that your comment is based on -01 > draft. Yes, you are correct. Sorry about that. And yes, the way the -02 drafts add= resses it works for me. =20 > 5) Section 4.2 > s/Media Streams sent by each participant is received all/Media streams se= nt > by each participant are received by the > s/snippets of SDP is shown/snippets of SDP are shown >=20 > 6) Section 4.3, example 2, it would be better if you remain consistent wi= th > the participant names (i.e. A/B or Ram/Partha. >=20 > 7) F4, it would be helpful to explain the inactive and sendonly SDP > attributes by adding text explaining that during the hold, A stops sendin= g > streams (inactive), while B continues sending (sendonly). >=20 > 5, 6, 7 comments will be incorporated in the next revision > >=20 > 8) Section 4.4, metadata > Is the idea that the streams remain the same and only the participant > changes? If so, state that. It is hard to tell by visual inspection wheth= er > the stream id is an exact match of perhaps has some small change. Also, I > was expecting to see metadata saying the Ram left and providing a > disassociation time. Instead, this is provided only the end of the call. = Is > that done just in case Ram returns before the end of the call. In any cas= e, > it would be good to state the reasoning so that it is clear why the metad= ata > is as it is. >=20 > 9) Section 4.6, F1 > Why does stream =3D=3D stream? >=20 > Because it is mixed stream. There is no way to distinguish the > directionality of the individual participants. >=20 > Also, how do you indicate when each person is talking? > It is possible that the information may be lost at SRC itself > This is troubling to me, but perhaps I am the only one that cares. I also t= end to think I do not understand the turret case well enough at this point.= Maybe someone here at IETF 85 this week can set me straight. Cheers, Charles > Is it accomplished using CNAME and SSRC? > I'm not sure whether CNAME & SSRC will help for mixed stream > >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Parthasarathi R > > Sent: Monday, October 22, 2012 1:56 PM > > To: siprec@ietf.org > > Subject: [siprec] FW: New Version Notification for draft-ram-siprec- > > callflows-02.txt > > > > Hi all, > > > > draft-ram-siprec-callflows-02 is published with the following update: > > > > 1) Updated the callflow as per draft-ietf-siprec-metadata-08 > > 2) Removed Metadata Example section > > 3) Incorporated Ofir Rath review comments > > > > The current open issue in the drafts > > 1) Incorporating RS SIP messages with metadata XML messages for all > > callflow > > 2) Callflows provided by Ofir Rath has to be discussed and added. > > > > Could you please provide your valuable comments on > > draft-ram-siprec-callflows-02. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, October 22, 2012 11:02 PM > > To: partha@parthasarathi.co.in > > Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu > > Subject: New Version Notification for draft-ram-siprec-callflows-02.txt > > > > > > A new version of I-D, draft-ram-siprec-callflows-02.txt > > has been successfully submitted by Parthasarathi Ravindran and posted t= o > > the > > IETF repository. > > > > Filename: draft-ram-siprec-callflows > > Revision: 02 > > Title: Session Initiation Protocol (SIP) Recording Call > Flows > > Creation date: 2012-10-22 > > WG ID: Individual Submission > > Number of pages: 18 > > URL: > http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows- > > 02.txt > > Status: > http://datatracker.ietf.org/doc/draft-ram-siprec-callflows > > Htmlized: http://tools.ietf.org/html/draft-ram-siprec-callflows-= 02 > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-02 > > > > Abstract: > > Session recording is a critical requirement in many communications > > environments such as call centers and financial trading. In some of > > these environments, all calls must be recorded for regulatory, > > compliance, and consumer protection reasons. Recording of a session > > is typically performed by sending a copy of a media stream to a > > recording device. This document lists call flows that has snapshot > > of metadata sent from SRC to SRS, the metadata format for which is > > described in [I-D.ietf-siprec-metadata] . This is purely an > > informational document that is written to support the model defined > > the metadata draft. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 13:22: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 9930421F8A46 for ; Thu, 8 Nov 2012 13:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 2HkSi1f7gUHQ for ; Thu, 8 Nov 2012 13:22:07 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id F33A621F86A1 for ; Thu, 8 Nov 2012 13:22:06 -0800 (PST) X-ASG-Debug-ID: 1352409725-03fc2136a66da620001-sFFYAS Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id edp2C3eCPPqmtJ6n (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 08 Nov 2012 16:22:05 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 16:22:05 -0500 From: Hadriel Kaplan To: "siprec@ietf.org Recording) WG" Thread-Topic: Proposed text for MTI required for interop X-ASG-Orig-Subj: Proposed text for MTI required for interop Thread-Index: AQHNvfcZuj6jQBwGQEu5xVrSGPPLbQ== Date: Thu, 8 Nov 2012 21:22:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C8BB68E9D87664BA6767349D0AFAA8F@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352409725 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113665 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 21:22:07 -0000 Proposed/drafty text for interop minimum to implement: An SRS that supports recording audio CS MUST support the SRC to use separat= e audio-type m-lines in SDP, one per CS media direction; likewise an SRC th= at supports audio CS MUST support using separate audio-type m-lines in SDP = to the SRS, one per CS media direction. An SRS supporting video CS recordi= ng MUST support the SRC to use separate video-type m-lines in SDP, one m-li= ne per CS media direction; likewise an SRC that supports video CS MUST supp= ort using separate video-type m-lines in SDP to the SRS, one per CS media d= irection. Therefore, for an SRS supporting a typical audio call, the SRS h= as to at least support receiving two audio-type m-lines; for an SRS support= ing a typical audio and video call, it has to support at least receiving fo= ur total m-lines in the SDP: two audio-type m-lines and two video-type m-li= nes. Note that these requirements allow a video-only capable SRS without audio r= ecording support, as well as allow an SRS to be implemented that only suppo= rts recording one direction of one stream in a CS - for example an SRS desi= gned to record security monitoring cameras that only send (not receive) vid= eo without any audio. These requirements were not written to prevent other= models being implemented and used instead, such as using a single m-line a= nd mixing the separate audio streams together; rather the requirements were= written to provide a common base mode to implement, for interoperability. = Implementations may support other modes as well, but have to at least supp= ort the above ones so that they interoperate in the basic mode. -hadriel From br@brianrosen.net Thu Nov 8 13:32: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 F035C21F8604 for ; Thu, 8 Nov 2012 13:32:03 -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=[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 a1xA-VLjHq8d for ; Thu, 8 Nov 2012 13:32:03 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6A21F84F8 for ; Thu, 8 Nov 2012 13:32:02 -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=zCs3msHDiKm4z1CguIT7Mib0Z4W/lI26cbf0SrrfVz4=; b=f8BNumIAlxpudWs9eMuNhL0lAWnsEqAhyxXM/2MYY+4hxwY8SOEwyY3Frl6H21ndosTMHHjkrckm1WB3Ac6MySZox6/TC7EwkAzwlnvo348XW0YEU/Bg5lHljyTnqDQQ; Received: from [209.173.57.233] (port=11420 helo=[192.168.130.76]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TWZhh-0002OB-Gk; Thu, 08 Nov 2012 16:32:01 -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: <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> Date: Thu, 8 Nov 2012 16:31:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> To: Charles Eckel (eckelcu) 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 indication 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, 08 Nov 2012 21:32:04 -0000 In the meeting today, this subject was raised again. There is a nuance that was discussed, which was coming up with a way to = know versions of the metadata prior to publication. Namespaces for XML in the IETF tend to look like: urn:ietf:params:xml:ns:foo I would propose that we have the namespace here be: urn:ietf:params:xml:ns:recording: I propose that drafts have the =3D 0. so, for example: urn:ietf:params:xml:ns:recording:0.09 I propose that the text have an RFC editor note to replace the version = with "1.0" when the RFC is published Brian On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) = wrote: > [Channeling recommendation from Matt] >=20 > In the XMPP Standards Foundation (XSF), we started to include = versioning into the XML namespace: >=20 > urn:xmpp:{protocol-shortname}:{version} >=20 > For instance, Message Carbons (specified in XEP-0280) uses the = namespace "urn:xmpp:carbons:2". >=20 > Now, the version number doesn't update with each revision of the = specification. Instead, it updates with any change that is not = compatible with the previous protocol version. Also, once the XEP moves = from "Experimental" (roughly analogous to internet-drafts; many changes = possible) to "Draft" (roughly analogous to RFC; changes are very = minimal, mostly clarifications), the protocol version is *NOT CHANGED*. >=20 > This seems to be working out well for us; it means that anyone that's = up to date from the experimental phase is current when we go = draft/recommended-to-implement. >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf >> Of Paul Kyzivat >> Sent: Thursday, October 25, 2012 10:09 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indication >>=20 >> I forgot: another alternative is a mime type parameter. >>=20 >> Thanks, >> Paul >>=20 >> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >>> I appreciate the problem here. There are a variety of ways to solve = it. >>>=20 >>> The obvious one would be to keep changing the content-type, by >> embedding >>> a version number in the mime-type name itself. This could present = some >>> logistical difficulties as we transition from draft to RFC. I guess = it >>> might also not be approved by mime gurus. It has the advantage that = you >>> won't accidentally try to parse a syntax you aren't prepared for. >>>=20 >>> Another way is to change the xmlns urn for each draft. As long as = every >>> version starts with the element that will be sufficient = to >>> disambiguate without getting into parsing trouble. >>>=20 >>> Another would be to add another (optional?) attribute to the = >>> element. >>>=20 >>> I don't know enough about XML to have a strong preference among = these. >>>=20 >>> But it may be a little late for this. How many more changes to the >>> schema do we expect before RFC? >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >>>> Hi Ofir, >>>>=20 >>>> This issues was raised earlier by Hadriel. I agree that it is good = to >>>> have "version" element inside recording element to indicate the = current >>>> version of the SIPREC metadata. This helps in case the metadata is >>>> extended from 1.0 to 2.0 by the update of RFC. >>>>=20 >>>> I'm not very sure whether it is accepted in IETF draft to update = the >>>> version of XML schema for each revision of the draft. For example, = the >>>> current version for the metadata draft will be 0.8 and the next = revision >>>> of the draft will be updated as 0.9. Let us look more comments for = the >>>> generic approach to solve this issue. >>>>=20 >>>> Thanks >>>>=20 >>>> Partha >>>>=20 >>>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >>>> Behalf Of *Ofir Roth >>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >>>> *To:* siprec@ietf.org >>>> *Subject:* [siprec] Metadata version indication >>>>=20 >>>> Hi, >>>>=20 >>>> =46rom our experience in SIPREC implementations, we often come = across >>>> vendors that use different versions of the SIPREC metadata versions >>>> (which are not necessarily aligned with the latest version of = metadata). >>>>=20 >>>> AFAIK, there is no way to indicate the metadata version as part of = the >>>> XML/SIP headers. >>>>=20 >>>> I think that having such indication will be very useful for SIPREC >>>> implementers as they can reject or handle the metadata according to >>>> their ability to use those versions. >>>>=20 >>>> I will appreciate your comment on that. >>>>=20 >>>> Thanks, >>>> Ofir Roth. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=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 krehor@cisco.com Thu Nov 8 13:34: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 B3A5321F89D2 for ; Thu, 8 Nov 2012 13:34:44 -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 ThPOcRp8+9dF for ; Thu, 8 Nov 2012 13:34:43 -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 C6A3221F85E8 for ; Thu, 8 Nov 2012 13:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2807; q=dns/txt; s=iport; t=1352410483; x=1353620083; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wUvwkZV9eP4RIgzyKAhA/1GegZEYSChd60ghJdpA2sw=; b=VMecBQ0fQ1VfhM4nmZctWXBtXJGF0s1o8NV1jrLZ5T2VpFB1aX6YZS3n uHjYnsglwZ2LnSsZC7XPN5tO+qOSicW5+PHy6uZ6ySi4KAw35PTpj1Tvi wO34ijietVAM4buNn9pV4xIQl6+WeslIKlrXW5pwrRD6YzrcGQjrUJ48g Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABIknFCtJXG+/2dsb2JhbABEw0GBCIIgAQQBAQEPAVUGHQEIDhRLCyUCBAESCBqHaAucDaAkBJF4YQOkU4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="140348323" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2012 21:34:43 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8LYh4l031469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 21:34:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:34:42 -0600 From: "Ken Rehor (krehor)" To: Hadriel Kaplan , "siprec@ietf.org Recording) WG" Thread-Topic: [siprec] Proposed text for MTI required for interop Thread-Index: AQHNvfcZuj6jQBwGQEu5xVrSGPPLbZfgQ34A Date: Thu, 8 Nov 2012 21:34:42 +0000 Message-ID: <9A740EB0DAB93C45A43D8EC2B61A18F8150CB90D@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.148.124] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--42.123400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4083EF69921312468C1500FD468DC9AE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 21:34:44 -0000 This is close but is too specific about a one-to-one mapping of RS stream to CS stream. There are scenarios where that might not happen. Here are a few scenarios/use cases to consider: One audio =AD voice messaging, mixed conference / trader CS, mixed 2-party = CS Two audio =AD channel separated 2-party CS Multiple audio - multi=ADparticipant conference / trader CS One video =AD video surveillance Multiple video =AD video surveillance One audio, one video =AD video messaging, mixed conference CS, mixed audio conference CS with active-speaker video (metadata may or may not need to keep up with change of active speaker) Two audio, one video =8B channel separated audio from 2-party CS with active-speaker video Two audio, two video =8B channel separated audio 2-party CS (one audio, on= e video per participant) N audio, M video =8B multi-camera CS Ken On 11/8/12 1:22 PM, "Hadriel Kaplan" wrote: >Proposed/drafty text for interop minimum to implement: > >An SRS that supports recording audio CS MUST support the SRC to use >separate audio-type m-lines in SDP, one per CS media direction; likewise >an SRC that supports audio CS MUST support using separate audio-type >m-lines in SDP to the SRS, one per CS media direction. An SRS supporting >video CS recording MUST support the SRC to use separate video-type >m-lines in SDP, one m-line per CS media direction; likewise an SRC that >supports video CS MUST support using separate video-type m-lines in SDP >to the SRS, one per CS media direction. Therefore, for an SRS supporting >a typical audio call, the SRS has to at least support receiving two >audio-type m-lines; for an SRS supporting a typical audio and video call, >it has to support at least receiving four total m-lines in the SDP: two >audio-type m-lines and two video-type m-lines. > >Note that these requirements allow a video-only capable SRS without audio >recording support, as well as allow an SRS to be implemented that only >supports recording one direction of one stream in a CS - for example an >SRS designed to record security monitoring cameras that only send (not >receive) video without any audio. These requirements were not written to >prevent other models being implemented and used instead, such as using a >single m-line and mixing the separate audio streams together; rather the >requirements were written to provide a common base mode to implement, for >interoperability. Implementations may support other modes as well, but >have to at least support the above ones so that they interoperate in the >basic mode. > >-hadriel > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 13:41: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 41F3821F86D4 for ; Thu, 8 Nov 2012 13:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_52=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 0TUh31cSi34O for ; Thu, 8 Nov 2012 13:41:43 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8617621F86AD for ; Thu, 8 Nov 2012 13:41:43 -0800 (PST) X-ASG-Debug-ID: 1352410902-03fc201610b7f80001-sFFYAS Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id QvJJxxlplgbvtDtt (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Nov 2012 16:41:42 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 16:41:42 -0500 From: Hadriel Kaplan To: "Ken Rehor (krehor)" Thread-Topic: [siprec] Proposed text for MTI required for interop X-ASG-Orig-Subj: Re: [siprec] Proposed text for MTI required for interop Thread-Index: AQHNvfnXtTJXrE2vKEeZtf13EGfwDA== Date: Thu, 8 Nov 2012 21:41:41 +0000 Message-ID: <118EB2E8-66B3-4C7B-AE64-212721ED077B@acmepacket.com> References: <9A740EB0DAB93C45A43D8EC2B61A18F8150CB90D@xmb-aln-x09.cisco.com> In-Reply-To: <9A740EB0DAB93C45A43D8EC2B61A18F8150CB90D@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7A11FE636FE3D143922BC10FFE18BC9E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352410902 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113667 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "siprec@ietf.org Recording\) WG" Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 21:41:44 -0000 I *think* (but could easily be wrong) that the text I proposed covers all t= hose in the normative requirement portion - i.s., in the lines that say MUS= T. Because it says "per CS media direction". So if there's only one CS me= dia flow/direction, there's only one m-line; if there're 100 media flows, t= here could be 100 m-lines. If the media is _already_ mixed when it reaches= the SRC, it's one media direction/flow to it so only needs one m-line (per= direction). No? -hadriel On Nov 8, 2012, at 4:34 PM, "Ken Rehor (krehor)" wrote: > This is close but is too specific about a one-to-one mapping of RS stream > to CS stream. There are scenarios where that might not happen. Here are a > few scenarios/use cases to consider: >=20 >=20 > One audio =AD voice messaging, mixed conference / trader CS, mixed 2-part= y CS > Two audio =AD channel separated 2-party CS > Multiple audio - multi=ADparticipant conference / trader CS >=20 > One video =AD video surveillance > Multiple video =AD video surveillance >=20 > One audio, one video =AD video messaging, mixed conference CS, mixed audi= o > conference CS with active-speaker video (metadata may or may not need to > keep up with change of active speaker) > Two audio, one video =8B channel separated audio from 2-party CS with > active-speaker video >=20 > Two audio, two video =8B channel separated audio 2-party CS (one audio, = one > video per participant) >=20 > N audio, M video =8B multi-camera CS >=20 >=20 > Ken >=20 >=20 >=20 >=20 > On 11/8/12 1:22 PM, "Hadriel Kaplan" wrote: >=20 >> Proposed/drafty text for interop minimum to implement: >>=20 >> An SRS that supports recording audio CS MUST support the SRC to use >> separate audio-type m-lines in SDP, one per CS media direction; likewise >> an SRC that supports audio CS MUST support using separate audio-type >> m-lines in SDP to the SRS, one per CS media direction. An SRS supportin= g >> video CS recording MUST support the SRC to use separate video-type >> m-lines in SDP, one m-line per CS media direction; likewise an SRC that >> supports video CS MUST support using separate video-type m-lines in SDP >> to the SRS, one per CS media direction. Therefore, for an SRS supportin= g >> a typical audio call, the SRS has to at least support receiving two >> audio-type m-lines; for an SRS supporting a typical audio and video call= , >> it has to support at least receiving four total m-lines in the SDP: two >> audio-type m-lines and two video-type m-lines. >>=20 >> Note that these requirements allow a video-only capable SRS without audi= o >> recording support, as well as allow an SRS to be implemented that only >> supports recording one direction of one stream in a CS - for example an >> SRS designed to record security monitoring cameras that only send (not >> receive) video without any audio. These requirements were not written t= o >> prevent other models being implemented and used instead, such as using a >> single m-line and mixing the separate audio streams together; rather the >> requirements were written to provide a common base mode to implement, fo= r >> interoperability. Implementations may support other modes as well, but >> have to at least support the above ones so that they interoperate in the >> basic mode. >>=20 >> -hadriel >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >=20 From krehor@cisco.com Thu Nov 8 14:00: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 84FAB21F8836 for ; Thu, 8 Nov 2012 14:00:59 -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_52=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 iarbkRmAzJJ9 for ; Thu, 8 Nov 2012 14:00:58 -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 6EEA921F880A for ; Thu, 8 Nov 2012 14:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5300; q=dns/txt; s=iport; t=1352412058; x=1353621658; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z0HfqWK9AbAt++zcohcBTzsz2okKm+kLw2xbkovlL2w=; b=EqtIouuCoFYbEcUePNupvtk/cmUyTG2ZU6RKBe3kKBNiP5Ow3Xz3oEgX EXLtTIMBvTiiJWNeAGVO6ZokNNC59vaAyLj3K/bSLARcTe0o0EvdCSVGN bvvQcfitqds8yTkeHsPrBJMD2FJiKf6MdE0NtZmkpRISFN/f+DRomAFTG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN0qnFCtJV2a/2dsb2JhbABEhhi8OnGBCIIeAQEBBAEBAQ8BEBE0BgsSAQgOCgICBiACBCULFRACBA4FCBqHaAucFo0lkn0EgSCKcoU0MmEDpFOBa4JvgVsFOQ X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="137320700" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2012 22:00:58 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8M0vKD022422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 22:00:57 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 16:00:57 -0600 From: "Ken Rehor (krehor)" To: Hadriel Kaplan Thread-Topic: [siprec] Proposed text for MTI required for interop Thread-Index: AQHNvfcZuj6jQBwGQEu5xVrSGPPLbZfgQ34AgACY1oD//26AgA== Date: Thu, 8 Nov 2012 22:00:56 +0000 Message-ID: <9A740EB0DAB93C45A43D8EC2B61A18F8150CB950@xmb-aln-x09.cisco.com> In-Reply-To: <118EB2E8-66B3-4C7B-AE64-212721ED077B@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.148.124] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--49.767800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <6A62EB9F9EAD264193D9D995BB42AAF8@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "siprec@ietf.org Recording\) WG" Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 22:00:59 -0000 T2ggSSBzZWUuIEkgd2FzIHJlYWRpbmcgInBlciBDUyBtZWRpYSBkaXJlY3Rpb24iIGFzIHRoZSBh dWRpbyBmcm9tIGVhY2gNCnBhcnRpY2lwYW50LCB0aGVyZWZvcmUgbmVlZGluZyBvbmUgcmVjb3Jk aW5nIHN0cmVhbSBmb3IgZWFjaCBwYXJ0aWNpcGFudC4NCg0KS2VuDQoNCg0KT24gMTEvOC8xMiAx OjQxIFBNLCAiSGFkcmllbCBLYXBsYW4iIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPiB3cm90ZToN Cg0KPg0KPkkgKnRoaW5rKiAoYnV0IGNvdWxkIGVhc2lseSBiZSB3cm9uZykgdGhhdCB0aGUgdGV4 dCBJIHByb3Bvc2VkIGNvdmVycyBhbGwNCj50aG9zZSBpbiB0aGUgbm9ybWF0aXZlIHJlcXVpcmVt ZW50IHBvcnRpb24gLSBpLnMuLCBpbiB0aGUgbGluZXMgdGhhdCBzYXkNCj5NVVNULiAgQmVjYXVz ZSBpdCBzYXlzICJwZXIgQ1MgbWVkaWEgZGlyZWN0aW9uIi4gIFNvIGlmIHRoZXJlJ3Mgb25seSBv bmUNCj5DUyBtZWRpYSBmbG93L2RpcmVjdGlvbiwgdGhlcmUncyBvbmx5IG9uZSBtLWxpbmU7IGlm IHRoZXJlJ3JlIDEwMCBtZWRpYQ0KPmZsb3dzLCB0aGVyZSBjb3VsZCBiZSAxMDAgbS1saW5lcy4g IElmIHRoZSBtZWRpYSBpcyBfYWxyZWFkeV8gbWl4ZWQgd2hlbg0KPml0IHJlYWNoZXMgdGhlIFNS QywgaXQncyBvbmUgbWVkaWEgZGlyZWN0aW9uL2Zsb3cgdG8gaXQgc28gb25seSBuZWVkcyBvbmUN Cj5tLWxpbmUgKHBlciBkaXJlY3Rpb24pLg0KPg0KPk5vPw0KPg0KPi1oYWRyaWVsDQo+DQo+DQo+ T24gTm92IDgsIDIwMTIsIGF0IDQ6MzQgUE0sICJLZW4gUmVob3IgKGtyZWhvcikiIDxrcmVob3JA Y2lzY28uY29tPg0KPiB3cm90ZToNCj4NCj4+IFRoaXMgaXMgY2xvc2UgYnV0IGlzIHRvbyBzcGVj aWZpYyBhYm91dCBhIG9uZS10by1vbmUgbWFwcGluZyBvZiBSUw0KPj5zdHJlYW0NCj4+IHRvIENT IHN0cmVhbS4gVGhlcmUgYXJlIHNjZW5hcmlvcyB3aGVyZSB0aGF0IG1pZ2h0IG5vdCBoYXBwZW4u IEhlcmUgYXJlDQo+PmENCj4+IGZldyBzY2VuYXJpb3MvdXNlIGNhc2VzIHRvIGNvbnNpZGVyOg0K Pj4gDQo+PiANCj4+IE9uZSBhdWRpbyDCrSB2b2ljZSBtZXNzYWdpbmcsIG1peGVkIGNvbmZlcmVu Y2UgLyB0cmFkZXIgQ1MsIG1peGVkDQo+PjItcGFydHkgQ1MNCj4+IFR3byBhdWRpbyDCrSBjaGFu bmVsIHNlcGFyYXRlZCAyLXBhcnR5IENTDQo+PiBNdWx0aXBsZSBhdWRpbyAtIG11bHRpwq1wYXJ0 aWNpcGFudCBjb25mZXJlbmNlIC8gdHJhZGVyIENTDQo+PiANCj4+IE9uZSB2aWRlbyDCrSB2aWRl byBzdXJ2ZWlsbGFuY2UNCj4+IE11bHRpcGxlIHZpZGVvIMKtIHZpZGVvIHN1cnZlaWxsYW5jZQ0K Pj4gDQo+PiBPbmUgYXVkaW8sIG9uZSB2aWRlbyDCrSB2aWRlbyBtZXNzYWdpbmcsIG1peGVkIGNv bmZlcmVuY2UgQ1MsIG1peGVkIGF1ZGlvDQo+PiBjb25mZXJlbmNlIENTIHdpdGggYWN0aXZlLXNw ZWFrZXIgdmlkZW8gKG1ldGFkYXRhIG1heSBvciBtYXkgbm90IG5lZWQgdG8NCj4+IGtlZXAgdXAg d2l0aCBjaGFuZ2Ugb2YgYWN0aXZlIHNwZWFrZXIpDQo+PiBUd28gYXVkaW8sIG9uZSB2aWRlbyDi gLkgY2hhbm5lbCBzZXBhcmF0ZWQgYXVkaW8gZnJvbSAyLXBhcnR5IENTIHdpdGgNCj4+IGFjdGl2 ZS1zcGVha2VyIHZpZGVvDQo+PiANCj4+IFR3byBhdWRpbywgdHdvIHZpZGVvIOKAuSBjaGFubmVs IHNlcGFyYXRlZCBhdWRpbyAyLXBhcnR5IENTICAob25lIGF1ZGlvLA0KPj5vbmUNCj4+IHZpZGVv IHBlciBwYXJ0aWNpcGFudCkNCj4+IA0KPj4gTiBhdWRpbywgTSB2aWRlbyDigLkgbXVsdGktY2Ft ZXJhIENTDQo+PiANCj4+IA0KPj4gS2VuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIDExLzgv MTIgMToyMiBQTSwgIkhhZHJpZWwgS2FwbGFuIiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4gd3Jv dGU6DQo+PiANCj4+PiBQcm9wb3NlZC9kcmFmdHkgdGV4dCBmb3IgaW50ZXJvcCBtaW5pbXVtIHRv IGltcGxlbWVudDoNCj4+PiANCj4+PiBBbiBTUlMgdGhhdCBzdXBwb3J0cyByZWNvcmRpbmcgYXVk aW8gQ1MgTVVTVCBzdXBwb3J0IHRoZSBTUkMgdG8gdXNlDQo+Pj4gc2VwYXJhdGUgYXVkaW8tdHlw ZSBtLWxpbmVzIGluIFNEUCwgb25lIHBlciBDUyBtZWRpYSBkaXJlY3Rpb247DQo+Pj5saWtld2lz ZQ0KPj4+IGFuIFNSQyB0aGF0IHN1cHBvcnRzIGF1ZGlvIENTIE1VU1Qgc3VwcG9ydCB1c2luZyBz ZXBhcmF0ZSBhdWRpby10eXBlDQo+Pj4gbS1saW5lcyBpbiBTRFAgdG8gdGhlIFNSUywgb25lIHBl ciBDUyBtZWRpYSBkaXJlY3Rpb24uICBBbiBTUlMNCj4+PnN1cHBvcnRpbmcNCj4+PiB2aWRlbyBD UyByZWNvcmRpbmcgTVVTVCBzdXBwb3J0IHRoZSBTUkMgdG8gdXNlIHNlcGFyYXRlIHZpZGVvLXR5 cGUNCj4+PiBtLWxpbmVzIGluIFNEUCwgb25lIG0tbGluZSBwZXIgQ1MgbWVkaWEgZGlyZWN0aW9u OyBsaWtld2lzZSBhbiBTUkMgdGhhdA0KPj4+IHN1cHBvcnRzIHZpZGVvIENTIE1VU1Qgc3VwcG9y dCB1c2luZyBzZXBhcmF0ZSB2aWRlby10eXBlIG0tbGluZXMgaW4gU0RQDQo+Pj4gdG8gdGhlIFNS Uywgb25lIHBlciBDUyBtZWRpYSBkaXJlY3Rpb24uICBUaGVyZWZvcmUsIGZvciBhbiBTUlMNCj4+ PnN1cHBvcnRpbmcNCj4+PiBhIHR5cGljYWwgYXVkaW8gY2FsbCwgdGhlIFNSUyBoYXMgdG8gYXQg bGVhc3Qgc3VwcG9ydCByZWNlaXZpbmcgdHdvDQo+Pj4gYXVkaW8tdHlwZSBtLWxpbmVzOyBmb3Ig YW4gU1JTIHN1cHBvcnRpbmcgYSB0eXBpY2FsIGF1ZGlvIGFuZCB2aWRlbw0KPj4+Y2FsbCwNCj4+ PiBpdCBoYXMgdG8gc3VwcG9ydCBhdCBsZWFzdCByZWNlaXZpbmcgZm91ciB0b3RhbCBtLWxpbmVz IGluIHRoZSBTRFA6IHR3bw0KPj4+IGF1ZGlvLXR5cGUgbS1saW5lcyBhbmQgdHdvIHZpZGVvLXR5 cGUgbS1saW5lcy4NCj4+PiANCj4+PiBOb3RlIHRoYXQgdGhlc2UgcmVxdWlyZW1lbnRzIGFsbG93 IGEgdmlkZW8tb25seSBjYXBhYmxlIFNSUyB3aXRob3V0DQo+Pj5hdWRpbw0KPj4+IHJlY29yZGlu ZyBzdXBwb3J0LCBhcyB3ZWxsIGFzIGFsbG93IGFuIFNSUyB0byBiZSBpbXBsZW1lbnRlZCB0aGF0 IG9ubHkNCj4+PiBzdXBwb3J0cyByZWNvcmRpbmcgb25lIGRpcmVjdGlvbiBvZiBvbmUgc3RyZWFt IGluIGEgQ1MgLSBmb3IgZXhhbXBsZSBhbg0KPj4+IFNSUyBkZXNpZ25lZCB0byByZWNvcmQgc2Vj dXJpdHkgbW9uaXRvcmluZyBjYW1lcmFzIHRoYXQgb25seSBzZW5kIChub3QNCj4+PiByZWNlaXZl KSB2aWRlbyB3aXRob3V0IGFueSBhdWRpby4gIFRoZXNlIHJlcXVpcmVtZW50cyB3ZXJlIG5vdCB3 cml0dGVuDQo+Pj50bw0KPj4+IHByZXZlbnQgb3RoZXIgbW9kZWxzIGJlaW5nIGltcGxlbWVudGVk IGFuZCB1c2VkIGluc3RlYWQsIHN1Y2ggYXMgdXNpbmcNCj4+PmENCj4+PiBzaW5nbGUgbS1saW5l IGFuZCBtaXhpbmcgdGhlIHNlcGFyYXRlIGF1ZGlvIHN0cmVhbXMgdG9nZXRoZXI7IHJhdGhlcg0K Pj4+dGhlDQo+Pj4gcmVxdWlyZW1lbnRzIHdlcmUgd3JpdHRlbiB0byBwcm92aWRlIGEgY29tbW9u IGJhc2UgbW9kZSB0byBpbXBsZW1lbnQsDQo+Pj5mb3INCj4+PiBpbnRlcm9wZXJhYmlsaXR5LiAg SW1wbGVtZW50YXRpb25zIG1heSBzdXBwb3J0IG90aGVyIG1vZGVzIGFzIHdlbGwsIGJ1dA0KPj4+ IGhhdmUgdG8gYXQgbGVhc3Qgc3VwcG9ydCB0aGUgYWJvdmUgb25lcyBzbyB0aGF0IHRoZXkgaW50 ZXJvcGVyYXRlIGluDQo+Pj50aGUNCj4+PiBiYXNpYyBtb2RlLg0KPj4+IA0KPj4+IC1oYWRyaWVs DQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBzaXByZWMgbWFpbGluZyBsaXN0DQo+Pj4gc2lwcmVjQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCj4+IA0KPg0KDQo= From pkyzivat@alum.mit.edu Thu Nov 8 14:31:31 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 D10D221F89E5 for ; Thu, 8 Nov 2012 14:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 9R5O8IkJx5pv for ; Thu, 8 Nov 2012 14:31:31 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 562A621F88B4 for ; Thu, 8 Nov 2012 14:31:31 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta01.emeryville.ca.mail.comcast.net with comcast id M5yp1k00G0EPchoA1AXWxr; Thu, 08 Nov 2012 22:31:30 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:e472:4eae:61f7:a7f0]) by omta01.emeryville.ca.mail.comcast.net with comcast id MAXW1k0072S6Fr38MAXWga; Thu, 08 Nov 2012 22:31:30 +0000 Message-ID: <509C32C1.9020100@alum.mit.edu> Date: Thu, 08 Nov 2012 17:31:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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 Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 22:31:32 -0000 Hadriel, Why should we put any limits on the SRC. It is in the driver seat regarding whether to mix or not. And so there is no need for it to support the mode it doesn't use. And consider a conference focus SRC. It may not be capable of sending unmixed media to the recorder. (If it did, it might have to send 100 streams.) Thanks, Paul On 11/8/12 4:22 PM, Hadriel Kaplan wrote: > Proposed/drafty text for interop minimum to implement: > > An SRS that supports recording audio CS MUST support the SRC to use separate audio-type m-lines in SDP, one per CS media direction; likewise an SRC that supports audio CS MUST support using separate audio-type m-lines in SDP to the SRS, one per CS media direction. An SRS supporting video CS recording MUST support the SRC to use separate video-type m-lines in SDP, one m-line per CS media direction; likewise an SRC that supports video CS MUST support using separate video-type m-lines in SDP to the SRS, one per CS media direction. Therefore, for an SRS supporting a typical audio call, the SRS has to at least support receiving two audio-type m-lines; for an SRS supporting a typical audio and video call, it has to support at least receiving four total m-lines in the SDP: two audio-type m-lines and two video-type m-lines. > > Note that these requirements allow a video-only capable SRS without audio recording support, as well as allow an SRS to be implemented that only supports recording one direction of one stream in a CS - for example an SRS designed to record security monitoring cameras that only send (not receive) video without any audio. These requirements were not written to prevent other models being implemented and used instead, such as using a single m-line and mixing the separate audio streams together; rather the requirements were written to provide a common base mode to implement, for interoperability. Implementations may support other modes as well, but have to at least support the above ones so that they interoperate in the basic mode. > > -hadriel > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 14:54:55 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 8842121F85BF for ; Thu, 8 Nov 2012 14:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 SQQNgO8P5DBm for ; Thu, 8 Nov 2012 14:54:54 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6821F84BF for ; Thu, 8 Nov 2012 14:54:54 -0800 (PST) X-ASG-Debug-ID: 1352415290-03fc201610be680001-sFFYAS Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id 34QRG2yK6i6CYlin (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Nov 2012 17:54:50 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 17:54:37 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [siprec] Proposed text for MTI required for interop X-ASG-Orig-Subj: Re: [siprec] Proposed text for MTI required for interop Thread-Index: AQHNvgQGS0VhVuy9N0CkNcRkKS4klQ== Date: Thu, 8 Nov 2012 22:54:36 +0000 Message-ID: <4091EAD3-8E35-486C-A448-B46C8C284299@acmepacket.com> References: <509C32C1.9020100@alum.mit.edu> In-Reply-To: <509C32C1.9020100@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DDE589D1FB47E4787F970C8A826855E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352415290 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113671 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "" Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 22:54:55 -0000 Because then we'd have to have a MUST for the SRS to support BOTH modes ins= tead, no? (which by the way I don't mind/care either way) -hadriel On Nov 8, 2012, at 5:31 PM, Paul Kyzivat wrote: > Hadriel, >=20 > Why should we put any limits on the SRC. It is in the driver seat regardi= ng whether to mix or not. And so there is no need for it to support the mod= e it doesn't use. And consider a conference focus SRC. It may not be capabl= e of sending unmixed media to the recorder. (If it did, it might have to se= nd 100 streams.) >=20 > Thanks, > Paul=09 >=20 > On 11/8/12 4:22 PM, Hadriel Kaplan wrote: >> Proposed/drafty text for interop minimum to implement: >>=20 >> An SRS that supports recording audio CS MUST support the SRC to use sepa= rate audio-type m-lines in SDP, one per CS media direction; likewise an SRC= that supports audio CS MUST support using separate audio-type m-lines in S= DP to the SRS, one per CS media direction. An SRS supporting video CS reco= rding MUST support the SRC to use separate video-type m-lines in SDP, one m= -line per CS media direction; likewise an SRC that supports video CS MUST s= upport using separate video-type m-lines in SDP to the SRS, one per CS medi= a direction. Therefore, for an SRS supporting a typical audio call, the SR= S has to at least support receiving two audio-type m-lines; for an SRS supp= orting a typical audio and video call, it has to support at least receiving= four total m-lines in the SDP: two audio-type m-lines and two video-type m= -lines. >>=20 >> Note that these requirements allow a video-only capable SRS without audi= o recording support, as well as allow an SRS to be implemented that only su= pports recording one direction of one stream in a CS - for example an SRS d= esigned to record security monitoring cameras that only send (not receive) = video without any audio. These requirements were not written to prevent ot= her models being implemented and used instead, such as using a single m-lin= e and mixing the separate audio streams together; rather the requirements w= ere written to provide a common base mode to implement, for interoperabilit= y. Implementations may support other modes as well, but have to at least s= upport the above ones so that they interoperate in the basic mode. >>=20 >> -hadriel >>=20 >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Thu Nov 8 15:18: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 7AF8721F88B4 for ; Thu, 8 Nov 2012 15:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 mjHtB+zzXlcc for ; Thu, 8 Nov 2012 15:18:03 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id EEFCB21F87E3 for ; Thu, 8 Nov 2012 15:18:02 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta06.emeryville.ca.mail.comcast.net with comcast id M9Gp1k0041zF43QA6BHxAG; Thu, 08 Nov 2012 23:17:57 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:e472:4eae:61f7:a7f0]) by omta24.emeryville.ca.mail.comcast.net with comcast id MBHw1k00l2S6Fr38kBHxAR; Thu, 08 Nov 2012 23:17:57 +0000 Message-ID: <509C3DA4.5050400@alum.mit.edu> Date: Thu, 08 Nov 2012 18:17:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <509C32C1.9020100@alum.mit.edu> <4091EAD3-8E35-486C-A448-B46C8C284299@acmepacket.com> In-Reply-To: <4091EAD3-8E35-486C-A448-B46C8C284299@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [siprec] Proposed text for MTI required for interop 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, 08 Nov 2012 23:18:03 -0000 On 11/8/12 5:54 PM, Hadriel Kaplan wrote: > > Because then we'd have to have a MUST for the SRS to support BOTH modes instead, no? (which by the way I don't mind/care either way) Yes. Isn't that a no-brainer? Thanks, Paul > -hadriel > > > On Nov 8, 2012, at 5:31 PM, Paul Kyzivat wrote: > >> Hadriel, >> >> Why should we put any limits on the SRC. It is in the driver seat regarding whether to mix or not. And so there is no need for it to support the mode it doesn't use. And consider a conference focus SRC. It may not be capable of sending unmixed media to the recorder. (If it did, it might have to send 100 streams.) >> >> Thanks, >> Paul >> >> On 11/8/12 4:22 PM, Hadriel Kaplan wrote: >>> Proposed/drafty text for interop minimum to implement: >>> >>> An SRS that supports recording audio CS MUST support the SRC to use separate audio-type m-lines in SDP, one per CS media direction; likewise an SRC that supports audio CS MUST support using separate audio-type m-lines in SDP to the SRS, one per CS media direction. An SRS supporting video CS recording MUST support the SRC to use separate video-type m-lines in SDP, one m-line per CS media direction; likewise an SRC that supports video CS MUST support using separate video-type m-lines in SDP to the SRS, one per CS media direction. Therefore, for an SRS supporting a typical audio call, the SRS has to at least support receiving two audio-type m-lines; for an SRS supporting a typical audio and video call, it has to support at least receiving four total m-lines in the SDP: two audio-type m-lines and two video-type m-lines. >>> >>> Note that these requirements allow a video-only capable SRS without audio recording support, as well as allow an SRS to be implemented that only supports recording one direction of one stream in a CS - for example an SRS designed to record security monitoring cameras that only send (not receive) video without any audio. These requirements were not written to prevent other models being implemented and used instead, such as using a single m-line and mixing the separate audio streams together; rather the requirements were written to provide a common base mode to implement, for interoperability. Implementations may support other modes as well, but have to at least support the above ones so that they interoperate in the basic mode. >>> >>> -hadriel >>> >>> _______________________________________________ >>> 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 btv1==660ae118dd8==HKaplan@acmepacket.com Thu Nov 8 20:25: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 6306511E80B8 for ; Thu, 8 Nov 2012 20:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Zf0Qg4-dCBbo for ; Thu, 8 Nov 2012 20:25:12 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id A338811E809B for ; Thu, 8 Nov 2012 20:25:12 -0800 (PST) X-ASG-Debug-ID: 1352435110-03fc2136a66f0dd0001-sFFYAS Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id T7mpc6F9A5Af0KBm (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Nov 2012 23:25:10 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 23:25:10 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [siprec] Proposed text for MTI required for interop X-ASG-Orig-Subj: Re: [siprec] Proposed text for MTI required for interop Thread-Index: AQHNvjI0QLLDoNQaQ0+fC4b2rwFgjw== Date: Fri, 9 Nov 2012 04:25:10 +0000 Message-ID: <57865998-6736-44A8-B762-31179ACBCDF1@acmepacket.com> References: <509C32C1.9020100@alum.mit.edu> <4091EAD3-8E35-486C-A448-B46C8C284299@acmepacket.com> <509C3DA4.5050400@alum.mit.edu> In-Reply-To: <509C3DA4.5050400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1BC6ED2ECDA46A498107B9E5187D7D11@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352435110 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113693 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for MTI required for interop 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, 09 Nov 2012 04:40:38 -0000 I dunno and don't care either way - either's fine with me, whatever the gro= up wants. :) -hadriel On Nov 8, 2012, at 6:17 PM, Paul Kyzivat wrote: > On 11/8/12 5:54 PM, Hadriel Kaplan wrote: >>=20 >> Because then we'd have to have a MUST for the SRS to support BOTH modes = instead, no? (which by the way I don't mind/care either way) >=20 > Yes. Isn't that a no-brainer? >=20 > Thanks, > Paul >=20 >> -hadriel >>=20 >>=20 >> On Nov 8, 2012, at 5:31 PM, Paul Kyzivat wrote: >>=20 >>> Hadriel, >>>=20 >>> Why should we put any limits on the SRC. It is in the driver seat regar= ding whether to mix or not. And so there is no need for it to support the m= ode it doesn't use. And consider a conference focus SRC. It may not be capa= ble of sending unmixed media to the recorder. (If it did, it might have to = send 100 streams.) >>>=20 >>> Thanks, >>> Paul=09 >>>=20 >>> On 11/8/12 4:22 PM, Hadriel Kaplan wrote: >>>> Proposed/drafty text for interop minimum to implement: >>>>=20 >>>> An SRS that supports recording audio CS MUST support the SRC to use se= parate audio-type m-lines in SDP, one per CS media direction; likewise an S= RC that supports audio CS MUST support using separate audio-type m-lines in= SDP to the SRS, one per CS media direction. An SRS supporting video CS re= cording MUST support the SRC to use separate video-type m-lines in SDP, one= m-line per CS media direction; likewise an SRC that supports video CS MUST= support using separate video-type m-lines in SDP to the SRS, one per CS me= dia direction. Therefore, for an SRS supporting a typical audio call, the = SRS has to at least support receiving two audio-type m-lines; for an SRS su= pporting a typical audio and video call, it has to support at least receivi= ng four total m-lines in the SDP: two audio-type m-lines and two video-type= m-lines. >>>>=20 >>>> Note that these requirements allow a video-only capable SRS without au= dio recording support, as well as allow an SRS to be implemented that only = supports recording one direction of one stream in a CS - for example an SRS= designed to record security monitoring cameras that only send (not receive= ) video without any audio. These requirements were not written to prevent = other models being implemented and used instead, such as using a single m-l= ine and mixing the separate audio streams together; rather the requirements= were written to provide a common base mode to implement, for interoperabil= ity. Implementations may support other modes as well, but have to at least= support the above ones so that they interoperate in the basic mode. >>>>=20 >>>> -hadriel >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Fri Nov 9 06:04: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 37B4A21F868F for ; Fri, 9 Nov 2012 06:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 up9XXbmGkIG5 for ; Fri, 9 Nov 2012 06:04:12 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 94DA521F868E for ; Fri, 9 Nov 2012 06:04:11 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id MR9y1k00P0QkzPwA1S4B9v; Fri, 09 Nov 2012 14:04:11 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:7175:9aca:6d94:9ee1]) by omta02.emeryville.ca.mail.comcast.net with comcast id MS491k00U4DCB5Q8NS4Aw0; Fri, 09 Nov 2012 14:04:10 +0000 Message-ID: <509D0D59.6070703@alum.mit.edu> Date: Fri, 09 Nov 2012 09:04:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian Rosen References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 09 Nov 2012 14:04:13 -0000 On 11/8/12 4:31 PM, Brian Rosen wrote: > In the meeting today, this subject was raised again. > > There is a nuance that was discussed, which was coming up with a way to know versions of the metadata prior to publication. > > Namespaces for XML in the IETF tend to look like: > urn:ietf:params:xml:ns:foo > > I would propose that we have the namespace here be: > urn:ietf:params:xml:ns:recording: > > I propose that drafts have the = 0. > so, for example: urn:ietf:params:xml:ns:recording:0.09 > I propose that the text have an RFC editor note to replace the version with "1.0" when the RFC is published Having the version coupled to the version of the draft is attractive in its simplicity. But it is a bit messy when there are versions of the metatdata that don't change the schema. But that hardly ever happens, so maybe it doesn't matter. With this scheme we will have to think of something else beyond V1.0. But I suppose we will then have a bis draft then and we can use the same scheme with that. So yes, this WFM. Thanks, Paul > Brian > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) wrote: > >> [Channeling recommendation from Matt] >> >> In the XMPP Standards Foundation (XSF), we started to include versioning into the XML namespace: >> >> urn:xmpp:{protocol-shortname}:{version} >> >> For instance, Message Carbons (specified in XEP-0280) uses the namespace "urn:xmpp:carbons:2". >> >> Now, the version number doesn't update with each revision of the specification. Instead, it updates with any change that is not compatible with the previous protocol version. Also, once the XEP moves from "Experimental" (roughly analogous to internet-drafts; many changes possible) to "Draft" (roughly analogous to RFC; changes are very minimal, mostly clarifications), the protocol version is *NOT CHANGED*. >> >> This seems to be working out well for us; it means that anyone that's up to date from the experimental phase is current when we go draft/recommended-to-implement. >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Thursday, October 25, 2012 10:09 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Metadata version indication >>> >>> I forgot: another alternative is a mime type parameter. >>> >>> Thanks, >>> Paul >>> >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >>>> I appreciate the problem here. There are a variety of ways to solve it. >>>> >>>> The obvious one would be to keep changing the content-type, by >>> embedding >>>> a version number in the mime-type name itself. This could present some >>>> logistical difficulties as we transition from draft to RFC. I guess it >>>> might also not be approved by mime gurus. It has the advantage that you >>>> won't accidentally try to parse a syntax you aren't prepared for. >>>> >>>> Another way is to change the xmlns urn for each draft. As long as every >>>> version starts with the element that will be sufficient to >>>> disambiguate without getting into parsing trouble. >>>> >>>> Another would be to add another (optional?) attribute to the >>>> element. >>>> >>>> I don't know enough about XML to have a strong preference among these. >>>> >>>> But it may be a little late for this. How many more changes to the >>>> schema do we expect before RFC? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >>>>> Hi Ofir, >>>>> >>>>> This issues was raised earlier by Hadriel. I agree that it is good to >>>>> have "version" element inside recording element to indicate the current >>>>> version of the SIPREC metadata. This helps in case the metadata is >>>>> extended from 1.0 to 2.0 by the update of RFC. >>>>> >>>>> I'm not very sure whether it is accepted in IETF draft to update the >>>>> version of XML schema for each revision of the draft. For example, the >>>>> current version for the metadata draft will be 0.8 and the next revision >>>>> of the draft will be updated as 0.9. Let us look more comments for the >>>>> generic approach to solve this issue. >>>>> >>>>> Thanks >>>>> >>>>> Partha >>>>> >>>>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >>>>> Behalf Of *Ofir Roth >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >>>>> *To:* siprec@ietf.org >>>>> *Subject:* [siprec] Metadata version indication >>>>> >>>>> Hi, >>>>> >>>>> From our experience in SIPREC implementations, we often come across >>>>> vendors that use different versions of the SIPREC metadata versions >>>>> (which are not necessarily aligned with the latest version of metadata). >>>>> >>>>> AFAIK, there is no way to indicate the metadata version as part of the >>>>> XML/SIP headers. >>>>> >>>>> I think that having such indication will be very useful for SIPREC >>>>> implementers as they can reject or handle the metadata according to >>>>> their ability to use those versions. >>>>> >>>>> I will appreciate your comment on that. >>>>> >>>>> Thanks, >>>>> Ofir Roth. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 DAVE.HIGTON@nice.com Fri Nov 9 06:15: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 2415121F8588 for ; Fri, 9 Nov 2012 06:15:06 -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 z8ziEF1H4hF2 for ; Fri, 9 Nov 2012 06:15:05 -0800 (PST) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9921F8583 for ; Fri, 9 Nov 2012 06:15:04 -0800 (PST) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Fri, 9 Nov 2012 14:15:03 +0000 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 14:15:02 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Fri, 9 Nov 2012 14:15:02 +0000 From: "Dave Higton" To: Date: Fri, 9 Nov 2012 14:15:00 +0000 Content-Class: urn:content-classes:message Importance: normal Thread-Topic: [siprec] Metadata version indication Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac2+gzUhNaFYe9YKSe6Z+wnWnkHEngAAOIhA Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B694055EF0D140@SOUEXC01.eu.nice.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu><50897223.7040609@alum.mit.edu><92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> In-Reply-To: <509D0D59.6070703@alum.mit.edu> 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: 09 Nov 2012 14:15:02.0549 (UTC) FILETIME=[9BFAFC50:01CDBE84] Subject: Re: [siprec] Metadata version indication 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, 09 Nov 2012 14:15:06 -0000 It isn't possible to look into the future with the certainty that = nothing will change. I, too, think it would be helpful to have a version number in the = metadata. I'd vote for it to be decoupled from the version of SIPREC. It's just a = number, after all. Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 09 November 2012 14:04 To: Brian Rosen Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication On 11/8/12 4:31 PM, Brian Rosen wrote: > In the meeting today, this subject was raised again. > > There is a nuance that was discussed, which was coming up with a way = to know versions of the metadata prior to publication. > > Namespaces for XML in the IETF tend to look like: > urn:ietf:params:xml:ns:foo > > I would propose that we have the namespace here be: > urn:ietf:params:xml:ns:recording: > > I propose that drafts have the =3D 0. so, for = > example: urn:ietf:params:xml:ns:recording:0.09 > I propose that the text have an RFC editor note to replace the version = > with "1.0" when the RFC is published Having the version coupled to the version of the draft is attractive in = its simplicity. But it is a bit messy when there are versions of the = metatdata that don't change the schema. But that hardly ever happens, so = maybe it doesn't matter. With this scheme we will have to think of something else beyond V1.0.=20 But I suppose we will then have a bis draft then and we can use the same = scheme with that. So yes, this WFM. Thanks, Paul > Brian > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) = wrote: > >> [Channeling recommendation from Matt] >> >> In the XMPP Standards Foundation (XSF), we started to include = versioning into the XML namespace: >> >> urn:xmpp:{protocol-shortname}:{version} >> >> For instance, Message Carbons (specified in XEP-0280) uses the = namespace "urn:xmpp:carbons:2". >> >> Now, the version number doesn't update with each revision of the = specification. Instead, it updates with any change that is not = compatible with the previous protocol version. Also, once the XEP moves = from "Experimental" (roughly analogous to internet-drafts; many changes = possible) to "Draft" (roughly analogous to RFC; changes are very = minimal, mostly clarifications), the protocol version is *NOT CHANGED*. >> >> This seems to be working out well for us; it means that anyone that's = up to date from the experimental phase is current when we go = draft/recommended-to-implement. >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, October 25, 2012 10:09 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Metadata version indication >>> >>> I forgot: another alternative is a mime type parameter. >>> >>> Thanks, >>> Paul >>> >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >>>> I appreciate the problem here. There are a variety of ways to solve = it. >>>> >>>> The obvious one would be to keep changing the content-type, by >>> embedding >>>> a version number in the mime-type name itself. This could present=20 >>>> some logistical difficulties as we transition from draft to RFC. I=20 >>>> guess it might also not be approved by mime gurus. It has the=20 >>>> advantage that you won't accidentally try to parse a syntax you = aren't prepared for. >>>> >>>> Another way is to change the xmlns urn for each draft. As long as=20 >>>> every version starts with the element that will be=20 >>>> sufficient to disambiguate without getting into parsing trouble. >>>> >>>> Another would be to add another (optional?) attribute to the=20 >>>> element. >>>> >>>> I don't know enough about XML to have a strong preference among = these. >>>> >>>> But it may be a little late for this. How many more changes to the=20 >>>> schema do we expect before RFC? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >>>>> Hi Ofir, >>>>> >>>>> This issues was raised earlier by Hadriel. I agree that it is good = >>>>> to have "version" element inside recording element to indicate the = >>>>> current version of the SIPREC metadata. This helps in case the=20 >>>>> metadata is extended from 1.0 to 2.0 by the update of RFC. >>>>> >>>>> I'm not very sure whether it is accepted in IETF draft to update=20 >>>>> the version of XML schema for each revision of the draft. For=20 >>>>> example, the current version for the metadata draft will be 0.8=20 >>>>> and the next revision of the draft will be updated as 0.9. Let us=20 >>>>> look more comments for the generic approach to solve this issue. >>>>> >>>>> Thanks >>>>> >>>>> Partha >>>>> >>>>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]=20 >>>>> *On Behalf Of *Ofir Roth >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >>>>> *To:* siprec@ietf.org >>>>> *Subject:* [siprec] Metadata version indication >>>>> >>>>> Hi, >>>>> >>>>> From our experience in SIPREC implementations, we often come=20 >>>>> across vendors that use different versions of the SIPREC metadata=20 >>>>> versions (which are not necessarily aligned with the latest = version of metadata). >>>>> >>>>> AFAIK, there is no way to indicate the metadata version as part of = >>>>> the XML/SIP headers. >>>>> >>>>> I think that having such indication will be very useful for SIPREC = >>>>> implementers as they can reject or handle the metadata according=20 >>>>> to their ability to use those versions. >>>>> >>>>> I will appreciate your comment on that. >>>>> >>>>> Thanks, >>>>> Ofir Roth. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 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 ietf@meetecho.com Sat Nov 10 12:15:38 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 3F8F821F8507 for ; Sat, 10 Nov 2012 12:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Q55LoO7mMFfq for ; Sat, 10 Nov 2012 12:15:38 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id C181421F8532 for ; Sat, 10 Nov 2012 12:15:37 -0800 (PST) Received: from [192.168.0.4] ([151.77.98.23]) by smtpcmd03.ad.aruba.it with bizsmtp id MwFb1k00F0WGHKK01wFc17; Sat, 10 Nov 2012 21:15:37 +0100 Message-ID: <509EB5E3.4040609@meetecho.com> Date: Sat, 10 Nov 2012 21:15:31 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: siprec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] Meetecho session recording 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, 10 Nov 2012 20:15:38 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From partha@parthasarathi.co.in Mon Nov 12 09:41: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 AA69D21F860C for ; Mon, 12 Nov 2012 09:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 jncQddjIm32Z for ; Mon, 12 Nov 2012 09:41:39 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id B83DD21F85C2 for ; Mon, 12 Nov 2012 09:41:39 -0800 (PST) Received: from userPC (unknown [122.178.222.243]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 7B0301908503; Mon, 12 Nov 2012 17:41:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1352742099; bh=EfkCz8UJavHlQIl0WxgIAFY4rcfzV0InZ0igbm0ixr8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P6YozXZdD4Hk+1aFjUk9u05JmjDbXDEp+LtOd2ksOWQtPTYmuHOsBxMBnVCJWGtiL 7d+3N7eyFws4gO4fmMvp0D6Yga0FMmLIjROvlySfUFlCSnfZtJOibuggvgjEnMjwdR YnMccVOcIQTuXkGpPs1TuiT/pXpLPwmiTkZ0g4Ro= From: "Parthasarathi R" To: "'Paul Kyzivat'" , "'Brian Rosen'" , References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> In-Reply-To: <509D0D59.6070703@alum.mit.edu> Date: Mon, 12 Nov 2012 23:11:16 +0530 Message-ID: <003401cdc0fc$f73d1740$e5b745c0$@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: Ac2+gx4uy5tI78bGSZqvK0TTwQpZJwBojUiQ Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0204.50A134D3.0024, 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 indication 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, 12 Nov 2012 17:41:40 -0000 Hi all, I like the idea of using version in XML namespace. Including Peter in this mail thread to get XML expert comments in this approach. BTW, While Mary discussed about SIPREC version in the meeting, I worried a bit in case Vendor/Customer consider the draft version as a standard compliance. It may be possible in the future as today, I'm seeing the convention of requesting & showing the standard compliance for informational RFC. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, November 09, 2012 7:34 PM To: Brian Rosen Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication On 11/8/12 4:31 PM, Brian Rosen wrote: > In the meeting today, this subject was raised again. > > There is a nuance that was discussed, which was coming up with a way to know versions of the metadata prior to publication. > > Namespaces for XML in the IETF tend to look like: > urn:ietf:params:xml:ns:foo > > I would propose that we have the namespace here be: > urn:ietf:params:xml:ns:recording: > > I propose that drafts have the = 0. > so, for example: urn:ietf:params:xml:ns:recording:0.09 > I propose that the text have an RFC editor note to replace the version with "1.0" when the RFC is published Having the version coupled to the version of the draft is attractive in its simplicity. But it is a bit messy when there are versions of the metatdata that don't change the schema. But that hardly ever happens, so maybe it doesn't matter. With this scheme we will have to think of something else beyond V1.0. But I suppose we will then have a bis draft then and we can use the same scheme with that. So yes, this WFM. Thanks, Paul > Brian > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) wrote: > >> [Channeling recommendation from Matt] >> >> In the XMPP Standards Foundation (XSF), we started to include versioning into the XML namespace: >> >> urn:xmpp:{protocol-shortname}:{version} >> >> For instance, Message Carbons (specified in XEP-0280) uses the namespace "urn:xmpp:carbons:2". >> >> Now, the version number doesn't update with each revision of the specification. Instead, it updates with any change that is not compatible with the previous protocol version. Also, once the XEP moves from "Experimental" (roughly analogous to internet-drafts; many changes possible) to "Draft" (roughly analogous to RFC; changes are very minimal, mostly clarifications), the protocol version is *NOT CHANGED*. >> >> This seems to be working out well for us; it means that anyone that's up to date from the experimental phase is current when we go draft/recommended-to-implement. >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Thursday, October 25, 2012 10:09 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Metadata version indication >>> >>> I forgot: another alternative is a mime type parameter. >>> >>> Thanks, >>> Paul >>> >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >>>> I appreciate the problem here. There are a variety of ways to solve it. >>>> >>>> The obvious one would be to keep changing the content-type, by >>> embedding >>>> a version number in the mime-type name itself. This could present some >>>> logistical difficulties as we transition from draft to RFC. I guess it >>>> might also not be approved by mime gurus. It has the advantage that you >>>> won't accidentally try to parse a syntax you aren't prepared for. >>>> >>>> Another way is to change the xmlns urn for each draft. As long as every >>>> version starts with the element that will be sufficient to >>>> disambiguate without getting into parsing trouble. >>>> >>>> Another would be to add another (optional?) attribute to the >>>> element. >>>> >>>> I don't know enough about XML to have a strong preference among these. >>>> >>>> But it may be a little late for this. How many more changes to the >>>> schema do we expect before RFC? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >>>>> Hi Ofir, >>>>> >>>>> This issues was raised earlier by Hadriel. I agree that it is good to >>>>> have "version" element inside recording element to indicate the current >>>>> version of the SIPREC metadata. This helps in case the metadata is >>>>> extended from 1.0 to 2.0 by the update of RFC. >>>>> >>>>> I'm not very sure whether it is accepted in IETF draft to update the >>>>> version of XML schema for each revision of the draft. For example, the >>>>> current version for the metadata draft will be 0.8 and the next revision >>>>> of the draft will be updated as 0.9. Let us look more comments for the >>>>> generic approach to solve this issue. >>>>> >>>>> Thanks >>>>> >>>>> Partha >>>>> >>>>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >>>>> Behalf Of *Ofir Roth >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >>>>> *To:* siprec@ietf.org >>>>> *Subject:* [siprec] Metadata version indication >>>>> >>>>> Hi, >>>>> >>>>> From our experience in SIPREC implementations, we often come across >>>>> vendors that use different versions of the SIPREC metadata versions >>>>> (which are not necessarily aligned with the latest version of metadata). >>>>> >>>>> AFAIK, there is no way to indicate the metadata version as part of the >>>>> XML/SIP headers. >>>>> >>>>> I think that having such indication will be very useful for SIPREC >>>>> implementers as they can reject or handle the metadata according to >>>>> their ability to use those versions. >>>>> >>>>> I will appreciate your comment on that. >>>>> >>>>> Thanks, >>>>> Ofir Roth. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 mary.ietf.barnes@gmail.com Tue Nov 13 12:30:09 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 4545B21F8200 for ; Tue, 13 Nov 2012 12:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 J9XiQimPtFgt for ; Tue, 13 Nov 2012 12:30:07 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27AC821F881D for ; Tue, 13 Nov 2012 12:30:06 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2750524lbk.31 for ; Tue, 13 Nov 2012 12:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zAfStOJak2L6l5ETRlgkmyOH3y/EB4tYh0Ds9RTpnWQ=; b=VqEFfOdH8ln++sqZaovuhiW5jozTIiDfl10G0wl9f9wBSLulRo+VJCGMoRjc0SUVf+ uUWAMTtrQGhllCbu/CIes1oBqap30NBSuSNV53cgv+11DN/W2OF2skbyeWiJg8TBV8+9 kdAgc3IRyQyRdeYrPcR0PoFwuz2cnno1pngNF+XAnEQQJhkIaVylVmqa/cXG8S+jsv8C XPVJCNGQ9SpKJ+BaMymeW8vcmFnptxL4fsk3Ma4wX7ZaXUbJxts2wwLzF0ziQQD1Gc86 7NdJ1AsnVzzHkIr9MzMuah5FXMm9HILI71CQhQg8zZfVvrSeFwpXeVl9Sa2WpZHwkno9 8w9Q== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr9799158lbo.122.1352838605949; Tue, 13 Nov 2012 12:30:05 -0800 (PST) Received: by 10.114.69.139 with HTTP; Tue, 13 Nov 2012 12:30:05 -0800 (PST) In-Reply-To: <003401cdc0fc$f73d1740$e5b745c0$@co.in> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> Date: Tue, 13 Nov 2012 14:30:05 -0600 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: multipart/alternative; boundary=f46d0401fe598bcd1304ce6648eb Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 13 Nov 2012 20:30:09 -0000 --f46d0401fe598bcd1304ce6648eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to understand better the WG perspective on this version. My understanding from Hadriel was that the only use for this is for a version 1.0 system (per the RFC to be) to know that it can't interface with a .07, for example. The reasoning seems to be that people have already implemented various versions of the draft. So, it seems the primary reason is so that one would know right off whether the implementations were compatible. However, that does require that existing implementations make changes to add their version number. How many of these implementations are out there now? My expectation and what I was expressing at the microphone is as Partha suggests, vendor A has implemented .07 and vendor B has implemented the RFC. Since vendor A also still interfaces with systems that also implemented .07, they need to support both in their product. Thus, I can't see people using the version number as Hadriel suggests (i.e., know you can't interwork), but rather I can see people interpreting the various versions as needing to be made interoperable. As was discussed in INSIPID, it seems to me that if there is an expectation of interoperability with a specific version of the draft, then we should publish that as informational. I would think it might be possible that the metadata could be adjusted to accommodate the earlier versions - i.e, someone that has implemented the RFC might be able to interoperate with a .07. But, I personally think that likely puts undue burden and =10complexity on the schema. My understanding is that in the web world, this versioning is the norm. However, in the web world, software changes very frequently. In the world in which many of these implementations will operate, the world does not change frequently. Thus, someone that has implemented .07 is likely not to implement the RFC for a while. Mary. On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R < partha@parthasarathi.co.in> wrote: > Hi all, > > I like the idea of using version in XML namespace. Including Peter in thi= s > mail thread to get XML expert comments in this approach. > > BTW, While Mary discussed about SIPREC version in the meeting, I worried = a > bit in case Vendor/Customer consider the draft version as a standard > compliance. It may be possible in the future as today, I'm seeing the > convention of requesting & showing the standard compliance for > informational > RFC. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of > Paul Kyzivat > Sent: Friday, November 09, 2012 7:34 PM > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication > > On 11/8/12 4:31 PM, Brian Rosen wrote: > > In the meeting today, this subject was raised again. > > > > There is a nuance that was discussed, which was coming up with a way to > know versions of the metadata prior to publication. > > > > Namespaces for XML in the IETF tend to look like: > > urn:ietf:params:xml:ns:foo > > > > I would propose that we have the namespace here be: > > urn:ietf:params:xml:ns:recording: > > > > I propose that drafts have the =3D 0. > > so, for example: urn:ietf:params:xml:ns:recording:0.09 > > I propose that the text have an RFC editor note to replace the version > with "1.0" when the RFC is published > > Having the version coupled to the version of the draft is attractive in > its simplicity. But it is a bit messy when there are versions of the > metatdata that don't change the schema. But that hardly ever happens, so > maybe it doesn't matter. > > With this scheme we will have to think of something else beyond V1.0. > But I suppose we will then have a bis draft then and we can use the same > scheme with that. > > So yes, this WFM. > > Thanks, > Paul > > > Brian > > > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) > wrote: > > > >> [Channeling recommendation from Matt] > >> > >> In the XMPP Standards Foundation (XSF), we started to include versioni= ng > into the XML namespace: > >> > >> urn:xmpp:{protocol-shortname}:{version} > >> > >> For instance, Message Carbons (specified in XEP-0280) uses the namespa= ce > "urn:xmpp:carbons:2". > >> > >> Now, the version number doesn't update with each revision of the > specification. Instead, it updates with any change that is not compatibl= e > with the previous protocol version. Also, once the XEP moves from > "Experimental" (roughly analogous to internet-drafts; many changes > possible) > to "Draft" (roughly analogous to RFC; changes are very minimal, mostly > clarifications), the protocol version is *NOT CHANGED*. > >> > >> This seems to be working out well for us; it means that anyone that's = up > to date from the experimental phase is current when we go > draft/recommended-to-implement. > >> > >> - m&m > >> > >> Matt Miller < mamille2@cisco.com > > >> Cisco Systems, Inc. > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Thursday, October 25, 2012 10:09 AM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Metadata version indication > >>> > >>> I forgot: another alternative is a mime type parameter. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: > >>>> I appreciate the problem here. There are a variety of ways to solve > it. > >>>> > >>>> The obvious one would be to keep changing the content-type, by > >>> embedding > >>>> a version number in the mime-type name itself. This could present so= me > >>>> logistical difficulties as we transition from draft to RFC. I guess = it > >>>> might also not be approved by mime gurus. It has the advantage that > you > >>>> won't accidentally try to parse a syntax you aren't prepared for. > >>>> > >>>> Another way is to change the xmlns urn for each draft. As long as > every > >>>> version starts with the element that will be sufficient = to > >>>> disambiguate without getting into parsing trouble. > >>>> > >>>> Another would be to add another (optional?) attribute to the > > >>>> element. > >>>> > >>>> I don't know enough about XML to have a strong preference among thes= e. > >>>> > >>>> But it may be a little late for this. How many more changes to the > >>>> schema do we expect before RFC? > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: > >>>>> Hi Ofir, > >>>>> > >>>>> This issues was raised earlier by Hadriel. I agree that it is good = to > >>>>> have "version" element inside recording element to indicate the > current > >>>>> version of the SIPREC metadata. This helps in case the metadata is > >>>>> extended from 1.0 to 2.0 by the update of RFC. > >>>>> > >>>>> I'm not very sure whether it is accepted in IETF draft to update th= e > >>>>> version of XML schema for each revision of the draft. For example, > the > >>>>> current version for the metadata draft will be 0.8 and the next > revision > >>>>> of the draft will be updated as 0.9. Let us look more comments for > the > >>>>> generic approach to solve this issue. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Partha > >>>>> > >>>>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > >>>>> Behalf Of *Ofir Roth > >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM > >>>>> *To:* siprec@ietf.org > >>>>> *Subject:* [siprec] Metadata version indication > >>>>> > >>>>> Hi, > >>>>> > >>>>> From our experience in SIPREC implementations, we often come acros= s > >>>>> vendors that use different versions of the SIPREC metadata versions > >>>>> (which are not necessarily aligned with the latest version of > metadata). > >>>>> > >>>>> AFAIK, there is no way to indicate the metadata version as part of > the > >>>>> XML/SIP headers. > >>>>> > >>>>> I think that having such indication will be very useful for SIPREC > >>>>> implementers as they can reject or handle the metadata according to > >>>>> their ability to use those versions. > >>>>> > >>>>> I will appreciate your comment on that. > >>>>> > >>>>> Thanks, > >>>>> Ofir Roth. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > --f46d0401fe598bcd1304ce6648eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to understand better the WG perspective on this version. =A0My= understanding from Hadriel was that the only use for this is for a version= 1.0 system (per the RFC to be) to know that it can't interface with a = .07, for example. =A0The reasoning seems to be that people have already imp= lemented various versions of the draft. =A0So, it seems the primary reason = is so that one would know right off whether the implementations were compat= ible. =A0However, that does require that existing implementations make chan= ges to add their version number. =A0 How many of these implementations are = out there now? =A0=A0

My expectation and what I was expressing at the microphone i= s as Partha suggests, vendor A has implemented .07 and vendor B has impleme= nted the RFC. =A0Since vendor A also still interfaces with systems that als= o implemented .07, they need to support both in their product. Thus, I can&= #39;t see people using the version number as Hadriel suggests (i.e., know y= ou can't interwork), but rather I can see people interpreting the vario= us versions as needing to be made interoperable. =A0As was discussed in INS= IPID, it seems to me that if there is an expectation of interoperability wi= th a specific version of the draft, then we should publish that as informat= ional.=A0

I would think it might be possible that the metadata co= uld be adjusted to accommodate the earlier versions - i.e, someone that has= implemented the RFC might be able to interoperate with a .07. =A0But, I pe= rsonally think that likely puts undue burden and =10complexity on the schem= a.

My understanding is that in the web world, this version= ing is the norm. =A0However, in the web world, software changes very freque= ntly. =A0In the world in which many of these implementations will operate, = the world does not change frequently. =A0Thus, someone that has implemented= .07 is likely not to implement the RFC for a while.

Mary.=A0


On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R <partha@parthasarathi.co.in> wrote:
Hi all,

I like the idea of using version in XML namespace. Including Peter in this<= br> mail thread to get XML expert comments in this approach.

BTW, While Mary discussed about SIPREC version in the meeting, I worried a<= br> bit in case Vendor/Customer consider the draft version as a standard
compliance. It may be possible in the future as today, I'm seeing the convention of requesting & showing the standard compliance for informat= ional
RFC.

Thanks
Partha

-----Original Message-----
From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.or= g] On Behalf Of
Paul Kyzivat
Sent: Friday, November 09, 20= 12 7:34 PM
To: Brian Rosen
Cc: siprec@ietf.org
Subject: Re: [siprec] Metadata version indication

On 11/8/12 4:31 PM, Brian Rosen wrote:
> In the meeting today, this subject was raised again.
>
> There is a nuance that was discussed, which was coming up with a way t= o
know versions of the metadata prior to publication.
>
> Namespaces for XML in the IETF tend to look like:
> urn:ietf:params:xml:ns:foo
>
> I would propose that we have the namespace here be:
> urn:ietf:params:xml:ns:recording:<version>
>
> I propose that drafts have the <Version> =3D 0.<draft version= >
> so, for example: urn:ietf:params:xml:ns:recording:0.09
> I propose that the text have an RFC editor note to replace the version=
with "1.0" when the RFC is published

Having the version coupled to the version of the draft is attractive in
its simplicity. But it is a bit messy when there are versions of the
metatdata that don't change the schema. But that hardly ever happens, s= o
maybe it doesn't matter.

With this scheme we will have to think of something else beyond V1.0.
But I suppose we will then have a bis draft then and we can use the same scheme with that.

So yes, this WFM.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Brian
>
> On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com>
wrote:
>
>> [Channeling recommendation from Matt]
>>
>> In the XMPP Standards Foundation (XSF), we started to include vers= ioning
into the XML namespace:
>>
>> =A0 =A0 =A0urn:xmpp:{protocol-shortname}:{version}
>>
>> For instance, Message Carbons (specified in XEP-0280) uses the nam= espace
"urn:xmpp:carbons:2".
>>
>> Now, the version number doesn't update with each revision of t= he
specification. =A0Instead, it updates with any change that is not compatibl= e
with the previous protocol version. =A0Also, once the XEP moves from
"Experimental" (roughly analogous to internet-drafts; many change= s possible)
to "Draft" (roughly analogous to RFC; changes are very minimal, m= ostly
clarifications), the protocol version is *NOT CHANGED*.
>>
>> This seems to be working out well for us; it means that anyone tha= t's up
to date from the experimental phase is current when we go
draft/recommended-to-implement.
>>
>> - m&m
>>
>> Matt Miller < mamille2@ci= sco.com >
>> Cisco Systems, Inc.
>>
>>> -----Original Message-----
>>> From: siprec-bounce= s@ietf.org [mailto:siprec-bo= unces@ietf.org] On Behalf
>>> Of Paul Kyzivat
>>> Sent: Thursday, October 25, 2012 10:09 AM
>>> To: siprec@ietf.org
>>> Subject: Re: [siprec] Metadata version indication
>>>
>>> I forgot: another alternative is a mime type parameter.
>>>
>>> =A0 =A0 Thanks,
>>> =A0 =A0 Paul
>>>
>>> On 10/24/12 12:03 PM, Paul Kyzivat wrote:
>>>> I appreciate the problem here. There are a variety of ways= to solve it.
>>>>
>>>> The obvious one would be to keep changing the content-type= , by
>>> embedding
>>>> a version number in the mime-type name itself. This could = present some
>>>> logistical difficulties as we transition from draft to RFC= . I guess it
>>>> might also not be approved by mime gurus. It has the advan= tage that you
>>>> won't accidentally try to parse a syntax you aren'= t prepared for.
>>>>
>>>> Another way is to change the xmlns urn for each draft. As = long as every
>>>> version starts with the <recording> element that wil= l be sufficient to
>>>> disambiguate without getting into parsing trouble.
>>>>
>>>> Another would be to add another (optional?) attribute to t= he
<recording>
>>>> element.
>>>>
>>>> I don't know enough about XML to have a strong prefere= nce among these.
>>>>
>>>> But it may be a little late for this. How many more change= s to the
>>>> schema do we expect before RFC?
>>>>
>>>> =A0 =A0 =A0Thanks,
>>>> =A0 =A0 =A0Paul
>>>>
>>>> On 10/24/12 5:19 AM, Parthasarathi R wrote:
>>>>> Hi Ofir,
>>>>>
>>>>> This issues was raised earlier by Hadriel. I agree tha= t it is good to
>>>>> have "version" element inside recording elem= ent to indicate the
current
>>>>> version of the SIPREC metadata. This helps in case the= metadata is
>>>>> extended from 1.0 to 2.0 by the update of RFC.
>>>>>
>>>>> I'm not very sure whether it is accepted in IETF d= raft to update the
>>>>> version of XML schema for each revision of the draft. = For example, the
>>>>> current version for the metadata draft will be 0.8 and= the next
revision
>>>>> of the draft will be updated as 0.9. Let us look more = comments for the
>>>>> generic approach to solve this issue.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Partha
>>>>>
>>>>> *From:*sipr= ec-bounces@ietf.org [mailto:= siprec-bounces@ietf.org] *On
>>>>> Behalf Of *Ofir Roth
>>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM
>>>>> *To:* siprec@ietf.o= rg
>>>>> *Subject:* [siprec] Metadata version indication
>>>>>
>>>>> Hi,
>>>>>
>>>>> =A0From our experience in SIPREC implementations, we o= ften come across
>>>>> vendors that use different versions of the SIPREC meta= data versions
>>>>> (which are not necessarily aligned with the latest ver= sion of
metadata).
>>>>>
>>>>> AFAIK, there is no way to indicate the metadata versio= n as part of the
>>>>> XML/SIP headers.
>>>>>
>>>>> I think that having such indication will be very usefu= l for SIPREC
>>>>> implementers as they can reject or handle the metadata= according to
>>>>> their ability to use those versions.
>>>>>
>>>>> I will appreciate your comment on that.
>>>>>
>>>>> Thanks,
>>>>> Ofir Roth.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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

--f46d0401fe598bcd1304ce6648eb-- From pkyzivat@alum.mit.edu Tue Nov 13 13:06:52 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 538A621F87F1 for ; Tue, 13 Nov 2012 13:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, 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 C7vH1bTh2gJm for ; Tue, 13 Nov 2012 13:06:51 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2946921F85E1 for ; Tue, 13 Nov 2012 13:06:51 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id P3H91k0261YDfWL5396qHb; Tue, 13 Nov 2012 21:06:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id P96p1k00w3ZTu2S3g96pjN; Tue, 13 Nov 2012 21:06:50 +0000 Message-ID: <50A2B668.1040808@alum.mit.edu> Date: Tue, 13 Nov 2012 16:06:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mary Barnes References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 13 Nov 2012 21:06:52 -0000 Mary, IMO, the first draft that incorporates this idea (say it is -10, since -09 didn't) will include the version number 0.10 in the schema URN. E.g. urn:ietf:params:xml:ns:recording:0.10 Implementations of that will include this URN. Older implementations will not have a version number in their namespace urn. Then: - Older versions interoperating (or not) with each other will continue unchanged. - Older versions interoperating with new versions won't understand the versioning, but will presumably note the mismatch of schema URN and maybe punt. - Newer versions interoperating with versions prior to -10 will note the mismatch, as they will when interoperating with versions >= to -10 that differ from their own. Thanks, Paul On 11/13/12 3:30 PM, Mary Barnes wrote: > I would like to understand better the WG perspective on this version. > My understanding from Hadriel was that the only use for this is for a > version 1.0 system (per the RFC to be) to know that it can't interface > with a .07, for example. The reasoning seems to be that people have > already implemented various versions of the draft. So, it seems the > primary reason is so that one would know right off whether the > implementations were compatible. However, that does require that > existing implementations make changes to add their version number. How > many of these implementations are out there now? > > My expectation and what I was expressing at the microphone is as Partha > suggests, vendor A has implemented .07 and vendor B has implemented the > RFC. Since vendor A also still interfaces with systems that also > implemented .07, they need to support both in their product. Thus, I > can't see people using the version number as Hadriel suggests (i.e., > know you can't interwork), but rather I can see people interpreting the > various versions as needing to be made interoperable. As was discussed > in INSIPID, it seems to me that if there is an expectation of > interoperability with a specific version of the draft, then we should > publish that as informational. > > I would think it might be possible that the metadata could be adjusted > to accommodate the earlier versions - i.e, someone that has implemented > the RFC might be able to interoperate with a .07. But, I personally > think that likely puts undue burden and complexity on the schema. > > My understanding is that in the web world, this versioning is the norm. > However, in the web world, software changes very frequently. In the > world in which many of these implementations will operate, the world > does not change frequently. Thus, someone that has implemented .07 is > likely not to implement the RFC for a while. > > Mary. > > > On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R > > wrote: > > Hi all, > > I like the idea of using version in XML namespace. Including Peter > in this > mail thread to get XML expert comments in this approach. > > BTW, While Mary discussed about SIPREC version in the meeting, I > worried a > bit in case Vendor/Customer consider the draft version as a standard > compliance. It may be possible in the future as today, I'm seeing the > convention of requesting & showing the standard compliance for > informational > RFC. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org ] On > Behalf Of > Paul Kyzivat > Sent: Friday, November 09, 2012 7:34 PM > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication > > On 11/8/12 4:31 PM, Brian Rosen wrote: > > In the meeting today, this subject was raised again. > > > > There is a nuance that was discussed, which was coming up with a > way to > know versions of the metadata prior to publication. > > > > Namespaces for XML in the IETF tend to look like: > > urn:ietf:params:xml:ns:foo > > > > I would propose that we have the namespace here be: > > urn:ietf:params:xml:ns:recording: > > > > I propose that drafts have the = 0. > > so, for example: urn:ietf:params:xml:ns:recording:0.09 > > I propose that the text have an RFC editor note to replace the > version > with "1.0" when the RFC is published > > Having the version coupled to the version of the draft is attractive in > its simplicity. But it is a bit messy when there are versions of the > metatdata that don't change the schema. But that hardly ever happens, so > maybe it doesn't matter. > > With this scheme we will have to think of something else beyond V1.0. > But I suppose we will then have a bis draft then and we can use the same > scheme with that. > > So yes, this WFM. > > Thanks, > Paul > > > Brian > > > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) > > > wrote: > > > >> [Channeling recommendation from Matt] > >> > >> In the XMPP Standards Foundation (XSF), we started to include > versioning > into the XML namespace: > >> > >> urn:xmpp:{protocol-shortname}:{version} > >> > >> For instance, Message Carbons (specified in XEP-0280) uses the > namespace > "urn:xmpp:carbons:2". > >> > >> Now, the version number doesn't update with each revision of the > specification. Instead, it updates with any change that is not > compatible > with the previous protocol version. Also, once the XEP moves from > "Experimental" (roughly analogous to internet-drafts; many changes > possible) > to "Draft" (roughly analogous to RFC; changes are very minimal, mostly > clarifications), the protocol version is *NOT CHANGED*. > >> > >> This seems to be working out well for us; it means that anyone > that's up > to date from the experimental phase is current when we go > draft/recommended-to-implement. > >> > >> - m&m > >> > >> Matt Miller < mamille2@cisco.com > > >> Cisco Systems, Inc. > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org ] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Thursday, October 25, 2012 10:09 AM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Metadata version indication > >>> > >>> I forgot: another alternative is a mime type parameter. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: > >>>> I appreciate the problem here. There are a variety of ways to > solve it. > >>>> > >>>> The obvious one would be to keep changing the content-type, by > >>> embedding > >>>> a version number in the mime-type name itself. This could > present some > >>>> logistical difficulties as we transition from draft to RFC. I > guess it > >>>> might also not be approved by mime gurus. It has the advantage > that you > >>>> won't accidentally try to parse a syntax you aren't prepared for. > >>>> > >>>> Another way is to change the xmlns urn for each draft. As long > as every > >>>> version starts with the element that will be > sufficient to > >>>> disambiguate without getting into parsing trouble. > >>>> > >>>> Another would be to add another (optional?) attribute to the > > >>>> element. > >>>> > >>>> I don't know enough about XML to have a strong preference > among these. > >>>> > >>>> But it may be a little late for this. How many more changes to the > >>>> schema do we expect before RFC? > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: > >>>>> Hi Ofir, > >>>>> > >>>>> This issues was raised earlier by Hadriel. I agree that it is > good to > >>>>> have "version" element inside recording element to indicate the > current > >>>>> version of the SIPREC metadata. This helps in case the > metadata is > >>>>> extended from 1.0 to 2.0 by the update of RFC. > >>>>> > >>>>> I'm not very sure whether it is accepted in IETF draft to > update the > >>>>> version of XML schema for each revision of the draft. For > example, the > >>>>> current version for the metadata draft will be 0.8 and the next > revision > >>>>> of the draft will be updated as 0.9. Let us look more > comments for the > >>>>> generic approach to solve this issue. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Partha > >>>>> > >>>>> *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org > ] *On > >>>>> Behalf Of *Ofir Roth > >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM > >>>>> *To:* siprec@ietf.org > >>>>> *Subject:* [siprec] Metadata version indication > >>>>> > >>>>> Hi, > >>>>> > >>>>> From our experience in SIPREC implementations, we often come > across > >>>>> vendors that use different versions of the SIPREC metadata > versions > >>>>> (which are not necessarily aligned with the latest version of > metadata). > >>>>> > >>>>> AFAIK, there is no way to indicate the metadata version as > part of the > >>>>> XML/SIP headers. > >>>>> > >>>>> I think that having such indication will be very useful for > SIPREC > >>>>> implementers as they can reject or handle the metadata > according to > >>>>> their ability to use those versions. > >>>>> > >>>>> I will appreciate your comment on that. > >>>>> > >>>>> Thanks, > >>>>> Ofir Roth. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 mary.ietf.barnes@gmail.com Tue Nov 13 14:33: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 4705121F849A for ; Tue, 13 Nov 2012 14:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 giQK6P+IqEmt for ; Tue, 13 Nov 2012 14:33:22 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEEEF21F846F for ; Tue, 13 Nov 2012 14:33:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2832296lbk.31 for ; Tue, 13 Nov 2012 14:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1gjqPzVHjYklb+Sv1gwliwMNM3z04mcP75JLUPQo6sY=; b=qqmKdVo9SKQYobC8Hqde12eMfd2R963E9k6HbSxTBOnqbJGUMQsiIxeNMuTz4GytEY kO8k3vdIB7u7xX0HmQgOPjhFj20o/JDbJ2416QWriECOIl2U1c1zdQjoEnhFMz6WEklc hY9P0XjSr4r4Gf8hqA5yhzi94HRBy//G0urzKV5lnkJOyTFJ51r1FHpQ90VFCWMfnIry OOQNKHzG+L6BCd4u5hMRrycKR+Xl2gqirH0vWjwtiSZ+RsKYf9bPvvLeXjo41tIuJLRs V4dPOu1FZSdcMj7JX+UxUknuD6gyylTItROFWHM9hp3WFv4ji+HIoUffGbqtTXhSBfum E8Og== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr9919237lbo.122.1352846000853; Tue, 13 Nov 2012 14:33:20 -0800 (PST) Received: by 10.114.69.139 with HTTP; Tue, 13 Nov 2012 14:33:20 -0800 (PST) In-Reply-To: <50A2B668.1040808@alum.mit.edu> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> Date: Tue, 13 Nov 2012 16:33:20 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0401fe5951127104ce680113 Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 13 Nov 2012 22:33:24 -0000 --f46d0401fe5951127104ce680113 Content-Type: text/plain; charset=ISO-8859-1 I still don't get Hadriel's point then as he seemed concerned about what's in the field right now. If we are saying version 10 is the draft folks should implement now while they wait for the RFC, then publish that as experimental. I would also think that designing the metadata with extensibilIty would help for the folks that might want interoperability with earlier versions. I also think that you should not go by draft versions. You should go by actual versions of the metadata. People that aren't directly involved in this (e.g., people who review RFPs, etc.) won't at all get the subtlety that you might be able to implement different versions and have the document still contain the same metadata. If you go the version route, you're going to need explanatory text somewhere as to which versions have the same metadata. I understand the need for folks to deploy products now based upon specs that might be out there. But, IMHO, that's at their own risk and I really think we're going down a rathole if for every new set of protocol work, we are going to make sure that there's at least one version of the draft that still works. Mary. On Tuesday, November 13, 2012, Paul Kyzivat wrote: > Mary, > > IMO, the first draft that incorporates this idea (say it is -10, since -09 > didn't) will include the version number 0.10 in the schema URN. E.g. > > urn:ietf:params:xml:ns:**recording:0.10 > > Implementations of that will include this URN. Older implementations will > not have a version number in their namespace urn. Then: > > - Older versions interoperating (or not) with each other will > continue unchanged. > > - Older versions interoperating with new versions won't understand > the versioning, but will presumably note the mismatch of schema URN > and maybe punt. > > - Newer versions interoperating with versions prior to -10 will note > the mismatch, as they will when interoperating with versions >= > to -10 that differ from their own. > > Thanks, > Paul > > > > On 11/13/12 3:30 PM, Mary Barnes wrote: > >> I would like to understand better the WG perspective on this version. >> My understanding from Hadriel was that the only use for this is for a >> version 1.0 system (per the RFC to be) to know that it can't interface >> with a .07, for example. The reasoning seems to be that people have >> already implemented various versions of the draft. So, it seems the >> primary reason is so that one would know right off whether the >> implementations were compatible. However, that does require that >> existing implementations make changes to add their version number. How >> many of these implementations are out there now? >> >> My expectation and what I was expressing at the microphone is as Partha >> suggests, vendor A has implemented .07 and vendor B has implemented the >> RFC. Since vendor A also still interfaces with systems that also >> implemented .07, they need to support both in their product. Thus, I >> can't see people using the version number as Hadriel suggests (i.e., >> know you can't interwork), but rather I can see people interpreting the >> various versions as needing to be made interoperable. As was discussed >> in INSIPID, it seems to me that if there is an expectation of >> interoperability with a specific version of the draft, then we should >> publish that as informational. >> >> I would think it might be possible that the metadata could be adjusted >> to accommodate the earlier versions - i.e, someone that has implemented >> the RFC might be able to interoperate with a .07. But, I personally >> think that likely puts undue burden and complexity on the schema. >> >> My understanding is that in the web world, this versioning is the norm. >> However, in the web world, software changes very frequently. In the >> world in which many of these implementations will operate, the world >> does not change frequently. Thus, someone that has implemented .07 is >> likely not to implement the RFC for a while. >> >> Mary. >> >> >> On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R >> > wrote: >> >> Hi all, >> >> I like the idea of using version in XML namespace. Including Peter >> in this >> mail thread to get XML expert comments in this approach. >> >> BTW, While Mary discussed about SIPREC version in the meeting, I >> worried a >> bit in case Vendor/Customer consider the draft version as a standard >> compliance. It may be possible in the future as today, I'm seeing the >> convention of requesting & showing the standard compliance for >> informational >> RFC. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org ] On >> Behalf Of >> Paul Kyzivat >> Sent: Friday, November 09, 2012 7:34 PM >> To: Brian Rosen >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indication >> >> On 11/8/12 4:31 PM, Brian Rosen wrote: >> > In the meeting today, this subject was raised again. >> > >> > There is a nuance that was discussed, which was coming up with a >> way to >> know versions of the metadata prior to publication. >> > >> > Namespaces for XML in the IETF tend to look like: >> > urn:ietf:params:xml:ns:foo >> > >> > I would propose that we have the namespace here be: >> > urn:ietf:params:xml:ns:**recording: >> > >> > I propose that drafts have the = 0. >> > so, for example: urn:ietf:params:xml:ns:**recording:0.09 >> > I propose that the text have an RFC editor note to replace the >> version >> with "1.0" when the RFC is published >> >> Having the version coupled to the version of the draft is attractive >> in >> its simplicity. But it is a bit messy when there are versions of the >> metatdata that don't change the schema. But that hardly ever happens, >> so >> maybe it doesn't matter. >> >> With this scheme we will have to think of something else beyond V1.0. >> But I suppose we will then have a bis draft then and we can use the >> same >> scheme with that. >> >> So yes, this WFM. >> >> Thanks, >> Paul >> >> > Brian >> > >> > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) >> > >> wrote: >> > >> >> [Channeling recommendation from Matt] >> >> >> >> In the XMPP Standards Foundation (XSF), we started to include >> versioning >> into the XML namespace: >> >> >> >> urn:xmpp:{protocol-shortname}:**{version} >> >> >> >> For instance, Message Carbons (specified in XEP-0280) uses the >> namespace >> "urn:xmpp:carbons:2". >> >> >> >> Now, the version number doesn't update with each revision of the >> specification. Instead, it updates with any change that is not >> compatible >> with the previous protocol version. Also, once the XEP moves from >> "Experimental" (roughly analogous to internet-drafts; many changes >> possible) >> to "Draft" (roughly analogous to RFC; changes are very minimal, mostly >> clarifications), the protocol version is *NOT CHANGED*. >> >> >> >> This seems to be working out well for us; it means that anyone >> that's up >> to date from the experimental phase is current when we go >> draft/recommended-to-**implement. >> >> >> >> - m&m >> >> >> >> Matt Miller < mamille2@cisco.com > >> >> Cisco Systems, Inc. >> >> >> >>> -----Original Message----- >> >>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org ] On >> Behalf >> >>> Of Paul Kyzivat >> >>> Sent: Thursday, October 25, 2012 10:09 AM >> >>> To: siprec@ietf.org >> >>> Subject: Re: [siprec] Metadata version indication >> >>> >> >>> I forgot: another alternative is a mime type parameter. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >> >>>> I appreciate the problem here. There are a variety of ways to >> solve it. >> >>>> >> >>>> The obvious one would be to keep changing the content-type, by >> >>> embedding >> >>>> a version number in the mime-type name itself. This could >> present some >> >>>> logistical difficulties as we transition from draft to RFC. I >> guess it >> >>>> might also not be approved by mime gurus. It has the advantage >> that you >> >>>> won't accidentally try to parse a syntax you aren't prepared >> for. >> >>>> >> >>>> Another way is to change the xmlns urn for each draft. As long >> as every >> >>>> version starts with the element that will be >> sufficient to >> >>>> disambiguate without getting into parsing trouble. >> >>>> >> >>>> Another would be to add another (optional?) attribute to the >> >> >>>> element. >> >>>> >> >>>> I don't know enough about XML to have a strong preference >> among these. >> >>>> >> >>>> But it may be a little late for this. How many more changes to >> the >> >>>> schema do we expect before RFC? >> >>>> >> >>>> Thanks, >> >>>> Paul >> >>>> >> >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >> >>>>> Hi Ofir, >> >>>>> >> >>>>> This issues was raised earlier by Hadriel. I agree that it is >> good to >> >>>>> have "version" element inside recording element to indicate the >> current >> >>>>> version of the SIPREC metadata. This helps in case the >> metadata is >> >>>>> extended from 1.0 to 2.0 by the update of RFC. >> >>>>> >> >>>>> I'm not very sure whether it is accepted in IETF draft to >> update the >> >>>>> version of XML schema for each revision of the draft. For >> example, the >> >>>>> current version for the metadata draft will be 0.8 and the next >> revision >> >>>>> of the draft will be updated as 0.9. Let us look more >> comments for the >> >>>>> generic approach to solve this issue. >> >>>>> >> >>>>> Thanks >> >>>>> >> >>>>> Partha >> >>>>> >> >>>>> *From:*siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org >> ] *On >> >>>>> Behalf Of *Ofir Roth >> >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >> >>>>> *To:* siprec@ietf.org >> >>>>> *Subject:* [siprec] Metadata version indication >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> From our experience in SIPREC implementations, we often come >> across >> >>>>> vendors that use different versions of the SIPREC metadata >> versions >> >>>>> (which are not necessarily aligned with the latest version of >> metadata). >> >>>>> >> >>>>> AFAIK, there is no way to indicate the metadata version as >> part of the >> >>>>> XML/SIP headers. >> >>>>> >> >>>>> I think that having such indication will be very useful for >> SIPREC >> >>>>> implementers as they can reject or handle the metadata >> according to >> >>>>> their ability to use those versions. >> >>>>> >> >>>>> I will appreciate your comment on that. >> >>>>> >> >>>>> Thanks, >> >>>>> Ofir Roth. >> >>>>> >> >>>>> >> >>>>> >> >>>>> ______________________________**_________________ >> >>>>> 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 >> >> >> > --f46d0401fe5951127104ce680113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I still don't get Hadriel's point then as he seemed concerned about= what's in the field right now. =A0If we are saying version 10 is the d= raft folks should implement now while they wait for the RFC, then publish t= hat as experimental. =A0

I would also think that designing the metadata with extensibilIty woul= d help for the folks that might want interoperability with earlier versions= .=A0

I also think that you should not= go by draft versions. =A0You should go by actual versions of the metadata.= =A0People that aren't directly involved in this (e.g., people who revi= ew RFPs, etc.) won't at all get the subtlety that you might be able to = implement different versions and have the document still contain the same m= etadata. =A0If you go the version route, you're going to need explanato= ry text somewhere as to which versions have the same metadata. =A0 =A0

I understand the need for folks to deploy products now = based upon specs that might be out there. =A0But, IMHO, that's at their= own risk and I really think we're going down a rathole if for every ne= w set of protocol work, we are going to make sure that there's at least= one version of the draft that still works. =A0=A0

Mary.

On Tuesday, November 13, 2012, Paul= Kyzivat wrote:
Mary,

IMO, the first draft that incorporates this idea (say it is -10, since -09 = didn't) will include the version number 0.10 in the schema URN. E.g.
urn:ietf:params:xml:ns:recording:0.10

Implementations of that will include this URN. Older implementations will n= ot have a version number in their namespace urn. Then:

- Older versions interoperating (or not) with each other will
=A0 continue unchanged.

- Older versions interoperating with new versions won't understand
=A0 the versioning, but will presumably note the mismatch of schema URN
=A0 and maybe punt.

- Newer versions interoperating with versions prior to -10 will note
=A0 the mismatch, as they will when interoperating with versions >=3D =A0 to -10 that differ from their own.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



On 11/13/12 3:30 PM, Mary Barnes wrote:
I would like to understand better the WG perspective on this version.
=A0 My understanding from Hadriel was that the only use for this is for a version 1.0 system (per the RFC to be) to know that it can't interface<= br> with a .07, for example. =A0The reasoning seems to be that people have
already implemented various versions of the draft. =A0So, it seems the
primary reason is so that one would know right off whether the
implementations were compatible. =A0However, that does require that
existing implementations make changes to add their version number. =A0 How<= br> many of these implementations are out there now?

My expectation and what I was expressing at the microphone is as Partha
suggests, vendor A has implemented .07 and vendor B has implemented the
RFC. =A0Since vendor A also still interfaces with systems that also
implemented .07, they need to support both in their product. Thus, I
can't see people using the version number as Hadriel suggests (i.e., know you can't interwork), but rather I can see people interpreting the=
various versions as needing to be made interoperable. =A0As was discussed in INSIPID, it seems to me that if there is an expectation of
interoperability with a specific version of the draft, then we should
publish that as informational.

I would think it might be possible that the metadata could be adjusted
to accommodate the earlier versions - i.e, someone that has implemented
the RFC might be able to interoperate with a .07. =A0But, I personally
think that likely puts undue burden and =A0complexity on the schema.

My understanding is that in the web world, this versioning is the norm.
=A0 However, in the web world, software changes very frequently. =A0In the<= br> world in which many of these implementations will operate, the world
does not change frequently. =A0Thus, someone that has implemented .07 is likely not to implement the RFC for a while.

Mary.


On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R
<partha@parthasarathi.co.in <mailto:partha@parthasarathi.co= .in>> wrote:

=A0 =A0 Hi all,

=A0 =A0 I like the idea of using version in XML namespace. Including Peter<= br> =A0 =A0 in this
=A0 =A0 mail thread to get XML expert comments in this approach.

=A0 =A0 BTW, While Mary discussed about SIPREC version in the meeting, I =A0 =A0 worried a
=A0 =A0 bit in case Vendor/Customer consider the draft version as a standar= d
=A0 =A0 compliance. It may be possible in the future as today, I'm seei= ng the
=A0 =A0 convention of requesting & showing the standard compliance for<= br> =A0 =A0 informational
=A0 =A0 RFC.

=A0 =A0 Thanks
=A0 =A0 Partha

=A0 =A0 -----Original Message-----
=A0 =A0 From: siprec-bounces@ietf.org <mailto:siprec-bounces@i= etf.org>
=A0 =A0 [mailto:siprec-bounces@ietf.org <mailto:siprec-bounces= @ietf.org>] On
=A0 =A0 Behalf Of
=A0 =A0 Paul Kyzivat
=A0 =A0 Sent: Friday, November 09, 2012 7:34 PM
=A0 =A0 To: Brian Rosen
=A0 =A0 Cc: siprec@ietf.org <mailto:siprec@ietf.org> =A0 =A0 Subject: Re: [siprec] Metadata version indication

=A0 =A0 On 11/8/12 4:31 PM, Brian Rosen wrote:
=A0 =A0 =A0> In the meeting today, this subject was raised again.
=A0 =A0 =A0>
=A0 =A0 =A0> There is a nuance that was discussed, which was coming up w= ith a
=A0 =A0 way to
=A0 =A0 know versions of the metadata prior to publication.
=A0 =A0 =A0>
=A0 =A0 =A0> Namespaces for XML in the IETF tend to look like:
=A0 =A0 =A0> urn:ietf:params:xml:ns:foo
=A0 =A0 =A0>
=A0 =A0 =A0> I would propose that we have the namespace here be:
=A0 =A0 =A0> urn:ietf:params:xml:ns:recording:<version>
=A0 =A0 =A0>
=A0 =A0 =A0> I propose that drafts have the <Version> =3D 0.<dr= aft version>
=A0 =A0 =A0> so, for example: urn:ietf:params:xml:ns:recording:0.= 09
=A0 =A0 =A0> I propose that the text have an RFC editor note to replace = the
=A0 =A0 version
=A0 =A0 with "1.0" when the RFC is published

=A0 =A0 Having the version coupled to the version of the draft is attractiv= e in
=A0 =A0 its simplicity. But it is a bit messy when there are versions of th= e
=A0 =A0 metatdata that don't change the schema. But that hardly ever ha= ppens, so
=A0 =A0 maybe it doesn't matter.

=A0 =A0 With this scheme we will have to think of something else beyond V1.= 0.
=A0 =A0 But I suppose we will then have a bis draft then and we can use the= same
=A0 =A0 scheme with that.

=A0 =A0 So yes, this WFM.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 =A0> Brian
=A0 =A0 =A0>
=A0 =A0 =A0> On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu)
=A0 =A0 <eckelcu@cisco.com <mailto:eckelcu@cisco.com>= ;>
=A0 =A0 wrote:
=A0 =A0 =A0>
=A0 =A0 =A0>> [Channeling recommendation from Matt]
=A0 =A0 =A0>>
=A0 =A0 =A0>> In the XMPP Standards Foundation (XSF), we started to i= nclude
=A0 =A0 versioning
=A0 =A0 into the XML namespace:
=A0 =A0 =A0>>
=A0 =A0 =A0>> =A0 =A0 =A0urn:xmpp:{protocol-shortname}:{versio= n}
=A0 =A0 =A0>>
=A0 =A0 =A0>> For instance, Message Carbons (specified in XEP-0280) u= ses the
=A0 =A0 namespace
=A0 =A0 "urn:xmpp:carbons:2".
=A0 =A0 =A0>>
=A0 =A0 =A0>> Now, the version number doesn't update with each re= vision of the
=A0 =A0 specification. =A0Instead, it updates with any change that is not =A0 =A0 compatible
=A0 =A0 with the previous protocol version. =A0Also, once the XEP moves fro= m
=A0 =A0 "Experimental" (roughly analogous to internet-drafts; man= y changes
=A0 =A0 possible)
=A0 =A0 to "Draft" (roughly analogous to RFC; changes are very mi= nimal, mostly
=A0 =A0 clarifications), the protocol version is *NOT CHANGED*.
=A0 =A0 =A0>>
=A0 =A0 =A0>> This seems to be working out well for us; it means that= anyone
=A0 =A0 that's up
=A0 =A0 to date from the experimental phase is current when we go
=A0 =A0 draft/recommended-to-implement.
=A0 =A0 =A0>>
=A0 =A0 =A0>> - m&m
=A0 =A0 =A0>>
=A0 =A0 =A0>> Matt Miller < mamille2@cisco.com <mailto:<= a>mamille2@cisco.com> >
=A0 =A0 =A0>> Cisco Systems, Inc.
=A0 =A0 =A0>>
=A0 =A0 =A0>>> -----Original Message-----
=A0 =A0 =A0>>> From: siprec-bounces@ietf.org <mailto:= siprec-bounces@ietf.org>
=A0 =A0 [mailto:siprec-bounces@ietf.org <mailto:siprec-bounces= @ietf.org>] On
=A0 =A0 Behalf
=A0 =A0 =A0>>> Of Paul Kyzivat
=A0 =A0 =A0>>> Sent: Thursday, October 25, 2012 10:09 AM
=A0 =A0 =A0>>> To: siprec@ietf.org <mailto:siprec@iet= f.org>
=A0 =A0 =A0>>> Subject: Re: [siprec] Metadata version indication =A0 =A0 =A0>>>
=A0 =A0 =A0>>> I forgot: another alternative is a mime type parame= ter.
=A0 =A0 =A0>>>
=A0 =A0 =A0>>> =A0 =A0 Thanks,
=A0 =A0 =A0>>> =A0 =A0 Paul
=A0 =A0 =A0>>>
=A0 =A0 =A0>>> On 10/24/12 12:03 PM, Paul Kyzivat wrote:
=A0 =A0 =A0>>>> I appreciate the problem here. There are a vari= ety of ways to
=A0 =A0 solve it.
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> The obvious one would be to keep changing the c= ontent-type, by
=A0 =A0 =A0>>> embedding
=A0 =A0 =A0>>>> a version number in the mime-type name itself. = This could
=A0 =A0 present some
=A0 =A0 =A0>>>> logistical difficulties as we transition from d= raft to RFC. I
=A0 =A0 guess it
=A0 =A0 =A0>>>> might also not be approved by mime gurus. It ha= s the advantage
=A0 =A0 that you
=A0 =A0 =A0>>>> won't accidentally try to parse a syntax yo= u aren't prepared for.
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> Another way is to change the xmlns urn for each= draft. As long
=A0 =A0 as every
=A0 =A0 =A0>>>> version starts with the <recording> eleme= nt that will be
=A0 =A0 sufficient to
=A0 =A0 =A0>>>> disambiguate without getting into parsing troub= le.
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> Another would be to add another (optional?) att= ribute to the
=A0 =A0 <recording>
=A0 =A0 =A0>>>> element.
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> I don't know enough about XML to have a str= ong preference
=A0 =A0 among these.
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> But it may be a little late for this. How many = more changes to the
=A0 =A0 =A0>>>> schema do we expect before RFC?
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> =A0 =A0 =A0Thanks,
=A0 =A0 =A0>>>> =A0 =A0 =A0Paul
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> On 10/24/12 5:19 AM, Parthasarathi R wrote:
=A0 =A0 =A0>>>>> Hi Ofir,
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> This issues was raised earlier by Hadriel. = I agree that it is
=A0 =A0 good to
=A0 =A0 =A0>>>>> have "version" element inside rec= ording element to indicate the
=A0 =A0 current
=A0 =A0 =A0>>>>> version of the SIPREC metadata. This helps = in case the
=A0 =A0 metadata is
=A0 =A0 =A0>>>>> extended from 1.0 to 2.0 by the update of R= FC.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> I'm not very sure whether it is accepte= d in IETF draft to
=A0 =A0 update the
=A0 =A0 =A0>>>>> version of XML schema for each revision of = the draft. For
=A0 =A0 example, the
=A0 =A0 =A0>>>>> current version for the metadata draft will= be 0.8 and the next
=A0 =A0 revision
=A0 =A0 =A0>>>>> of the draft will be updated as 0.9. Let us= look more
=A0 =A0 comments for the
=A0 =A0 =A0>>>>> generic approach to solve this issue.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> Thanks
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> Partha
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> *From:*siprec-bounces@ietf.org
=A0 =A0 <mailto:siprec-bounces@ietf.org> [mailto:siprec-bou= nces@ietf.org
=A0 =A0 <mailto:siprec-bounces@ietf.org>] *On
=A0 =A0 =A0>>>>> Behalf Of *Ofir Roth
=A0 =A0 =A0>>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM=
=A0 =A0 =A0>>>>> *To:* siprec@ietf.org <mailto:= siprec@ietf.org>
=A0 =A0 =A0>>>>> *Subject:* [siprec] Metadata version indica= tion
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> Hi,
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> =A0From our experience in SIPREC implementa= tions, we often come
=A0 =A0 across
=A0 =A0 =A0>>>>> vendors that use different versions of the = SIPREC metadata
=A0 =A0 versions
=A0 =A0 =A0>>>>> (which are not necessarily aligned with the= latest version of
=A0 =A0 metadata).
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> AFAIK, there is no way to indicate the meta= data version as
=A0 =A0 part of the
=A0 =A0 =A0>>>>> XML/SIP headers.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> I think that having such indication will be= very useful for
=A0 =A0 SIPREC
=A0 =A0 =A0>>>>> implementers as they can reject or handle t= he metadata
=A0 =A0 according to
=A0 =A0 =A0>>>>> their ability to use those versions.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> I will appreciate your comment on that.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> Thanks,
=A0 =A0 =A0>>>>> Ofir Roth.
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>> ____________________________________= ___________
=A0 =A0 =A0>>>>> siprec mailing list
=A0 =A0 =A0>>>>> siprec@ietf.org <mailto:siprec= @ietf.org>
=A0 =A0 =A0>>>>> https://www.ietf.org/mailman/listinf= o/siprec
=A0 =A0 =A0>>>>>
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>> ________________________________________= _______
=A0 =A0 =A0>>>> siprec mailing list
=A0 =A0 =A0>>>> siprec@ietf.org <mailto:siprec@iet= f.org>
=A0 =A0 =A0>>>> https://www.ietf.org/mailman/listinfo/si= prec
=A0 =A0 =A0>>>>
=A0 =A0 =A0>>>
=A0 =A0 =A0>>> ____________________________________________= ___
=A0 =A0 =A0>>> siprec mailing list
=A0 =A0 =A0>>> siprec@ietf.org <mailto:siprec@ietf.or= g>
=A0 =A0 =A0>>> https://www.ietf.org/mailman/listinfo/siprec=
=A0 =A0 =A0>> _______________________________________________<= br> =A0 =A0 =A0>> siprec mailing list
=A0 =A0 =A0>> siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0>> https://www.ietf.org/mailman/listinfo/siprec=
=A0 =A0 =A0>
=A0 =A0 =A0>

=A0 =A0 _______________________________________________
=A0 =A0 siprec mailing list
=A0 =A0 siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/siprec

=A0 =A0 _______________________________________________
=A0 =A0 siprec mailing list
=A0 =A0 siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/siprec



--f46d0401fe5951127104ce680113-- From Ofir.Roth@nice.com Tue Nov 13 23:33: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 9A63821F85AD for ; Tue, 13 Nov 2012 23:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 InSw-v6dbL2Q for ; Tue, 13 Nov 2012 23:33:19 -0800 (PST) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFD21F879D for ; Tue, 13 Nov 2012 23:33:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,249,1352066400"; d="scan'208,217";a="5177282" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 14 Nov 2012 09:33:16 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 14 Nov 2012 09:33:14 +0200 Thread-Topic: Metadata V8 - Consult Transfer Scenario Thread-Index: Ac2zynxdRKOUTh63RHKy7nJybQgSoAOb3pug 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: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA792CTLVMBX01nicec_" MIME-Version: 1.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: Wed, 14 Nov 2012 07:33:19 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA792CTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. O= nce confirmed as a valid metadata flow, I will update it with the SDP. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA792CTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

Is it still needed?

 

Thanks,

Ofir.

 

From: siprec-bounces@ietf.org [mailto:siprec-= bounces@ietf.org] On Behalf Of Ofir Roth
Sent: Saturday, O= ctober 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).

 

T= he scenario is simple consult transfer scenario:

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

2.  &= nbsp;    Alic= e hold the call with Bob (second metadata update)

3.       Alice consults with Joe (third metadata updat= e)

4.    &n= bsp;  Bob and Joe are t= alking (fourth metadata update)

&nb= sp;

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

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

 

Thanks,
Ofir Roth.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA792CTLVMBX01nicec_-- From rmohanr@cisco.com Wed Nov 14 01:22: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 DEC5E21F84F1 for ; Wed, 14 Nov 2012 01:22:28 -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 k6DYt6KwBCJa for ; Wed, 14 Nov 2012 01:22:28 -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 06FD321F8476 for ; Wed, 14 Nov 2012 01:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1310; q=dns/txt; s=iport; t=1352884948; x=1354094548; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=BHHX7ie0kCm+dbEnoUd/KsP1KcJmLOqAIKRPf+6YK7c=; b=lDEb4N25y3CeHuf3S0ImetGz7Qwh7dBVV30WwuFzYgfWKn92ULfiR3iQ UM5nIQUjfVfv6BcJQrukkVoxP+CVHRG8arbqH4bOSQzmb4rqq+o3E38bT 0zjq1wa8UuAssDNJNfZqVsIHKjcA5t2Zt84AWv6Q6og4yxBP+99SScPSv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPxho1CtJXG//2dsb2JhbABEwz6BCIIeAQEBAwEBAQEPASc0EA0BCBEEAQELFAkuCxQJCAIEAQkJCBqHYgYLmyigAQSMKoVLYQOkVIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142259805" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 14 Nov 2012 09:22:27 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAE9MRq8002394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 09:22:27 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 03:22:27 -0600 From: "Ram Mohan R (rmohanr)" To: Ofir Roth , "siprec@ietf.org" Thread-Topic: [siprec] Metadata V8 - Consult Transfer Scenario Thread-Index: AQHNwkmQpaDzcXPXBUaGU5b3d/dHVw== Date: Wed, 14 Nov 2012 09:22:27 +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.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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: Wed, 14 Nov 2012 09:22:29 -0000 Ofir, I will review the call flows you sent and get back to you on the same. Regards, Ram > On 14/11/12 1:03 PM, "Ofir Roth" wrote: >Hi, >=20 >I did not get any feedback about the consult transfer scenario. >Is it still needed? >=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 >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) >=20 >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. >=20 >Thanks, >Ofir Roth. > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From Ofir.Roth@nice.com Wed Nov 14 04:30: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 7E36021F84E2 for ; Wed, 14 Nov 2012 04:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 UmWr5gWPHxsh for ; Wed, 14 Nov 2012 04:30:29 -0800 (PST) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id B2EE421F84E1 for ; Wed, 14 Nov 2012 04:30:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,250,1352066400"; d="scan'208,217";a="5183729" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 14 Nov 2012 14:30:27 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 14 Nov 2012 14:30:26 +0200 Thread-Topic: draft-ram-siprec-callflows-02 - review Thread-Index: Ac3CYSm52tsPv4kmSliQkSP55TZcVw== Message-ID: 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: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA7B68TLVMBX01nicec_" MIME-Version: 1.0 Subject: [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, 14 Nov 2012 12:30:30 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA7B68TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 m= issing 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" s= treams (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 m= etadata 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. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA7B68TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

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

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

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

4.   &nb= sp;   Section 3.6 – the last stream is redundant (EiXGlc+4Truqqo= DaNE76ag=3D=3D) – not in use and can be removed from the metadata.

 

Thanks,
Ofir.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8DFA7B68TLVMBX01nicec_-- From pkyzivat@alum.mit.edu Wed Nov 14 07:41:37 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 F2C4A21F85DB for ; Wed, 14 Nov 2012 07:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.047, 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 NA2r-8mvV+Wb for ; Wed, 14 Nov 2012 07:41:37 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 568A621F857D for ; Wed, 14 Nov 2012 07:41:31 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id PPek1k0061wpRvQ53ThWcj; Wed, 14 Nov 2012 15:41:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id PThW1k00k3ZTu2S3eThWlQ; Wed, 14 Nov 2012 15:41:30 +0000 Message-ID: <50A3BBAA.6050706@alum.mit.edu> Date: Wed, 14 Nov 2012 10:41:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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 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: Wed, 14 Nov 2012 15:41:38 -0000 On 11/14/12 2:33 AM, Ofir Roth wrote: > Hi, > > I did not get any feedback about the consult transfer scenario. > > Is it still needed? I said at the session last week that we really need an assortment of use cases done by different people, and carefully reviewed. This will help identify differences in understanding of how to apply the schema. Thanks, Paul > 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. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Nov 14 08:56:52 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 C1D1621F856E for ; Wed, 14 Nov 2012 08:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, 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 mzoSvDSInShO for ; Wed, 14 Nov 2012 08:56:51 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 666B021F8546 for ; Wed, 14 Nov 2012 08:56:51 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta15.westchester.pa.mail.comcast.net with comcast id PQZ01k0031uE5Es5FUwquf; Wed, 14 Nov 2012 16:56:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id PUwq1k00A3ZTu2S3cUwqo3; Wed, 14 Nov 2012 16:56:50 +0000 Message-ID: <50A3CD51.7050504@alum.mit.edu> Date: Wed, 14 Nov 2012 11:56:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mary Barnes References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 16:56:52 -0000 On 11/13/12 5:33 PM, Mary Barnes wrote: > I still don't get Hadriel's point then as he seemed concerned about > what's in the field right now. If we are saying version 10 is the draft > folks should implement now while they wait for the RFC, then publish > that as experimental. Publishing as experimental is way too heavy weight for the purpose here. > I would also think that designing the metadata with extensibilIty would > help for the folks that might want interoperability with earlier versions. I don't want to see us confine ourselves to backward compatible changes before we get to version 1.0. > I also think that you should not go by draft versions. You should go by > actual versions of the metadata. People that aren't directly involved > in this (e.g., people who review RFPs, etc.) won't at all get the > subtlety that you might be able to implement different versions and have > the document still contain the same metadata. If you go the version > route, you're going to need explanatory text somewhere as to which > versions have the same metadata. I had also been thinking of counting versions independently of draft version numbers. Brian suggested using draft version numbers. (Prior to 1.0.) While that has the potential disadvantage of showing change when there is none, I think every version of the doc to date has had some change to the schema, so I don't think it is such a risk. And there is great convenience in tying it to the draft version number. So I was happy to go along with this, though I don't feel strongly about it. > I understand the need for folks to deploy products now based upon specs > that might be out there. AFAIK we are not talking about *products*. Rather we are talking about *prototypes*, and testing of interoperability among prototypes. > But, IMHO, that's at their own risk and I > really think we're going down a rathole if for every new set of protocol > work, we are going to make sure that there's at least one version of the > draft that still works. If we were building a mechanism solely for this pre-release purpose I would be opposed. I see this as installing a mechanism that will work for version 1.0 and future standardized extensions/revisions of it. And then it is convenient that the same mechanism can be used for this pre-standard testing as well. Thanks, Paul > Mary. > > On Tuesday, November 13, 2012, Paul Kyzivat wrote: > > Mary, > > IMO, the first draft that incorporates this idea (say it is -10, > since -09 didn't) will include the version number 0.10 in the schema > URN. E.g. > > urn:ietf:params:xml:ns:__recording:0.10 > > Implementations of that will include this URN. Older implementations > will not have a version number in their namespace urn. Then: > > - Older versions interoperating (or not) with each other will > continue unchanged. > > - Older versions interoperating with new versions won't understand > the versioning, but will presumably note the mismatch of schema URN > and maybe punt. > > - Newer versions interoperating with versions prior to -10 will note > the mismatch, as they will when interoperating with versions >= > to -10 that differ from their own. > > Thanks, > Paul > > > > On 11/13/12 3:30 PM, Mary Barnes wrote: > > I would like to understand better the WG perspective on this > version. > My understanding from Hadriel was that the only use for this > is for a > version 1.0 system (per the RFC to be) to know that it can't > interface > with a .07, for example. The reasoning seems to be that people have > already implemented various versions of the draft. So, it seems the > primary reason is so that one would know right off whether the > implementations were compatible. However, that does require that > existing implementations make changes to add their version > number. How > many of these implementations are out there now? > > My expectation and what I was expressing at the microphone is as > Partha > suggests, vendor A has implemented .07 and vendor B has > implemented the > RFC. Since vendor A also still interfaces with systems that also > implemented .07, they need to support both in their product. Thus, I > can't see people using the version number as Hadriel suggests (i.e., > know you can't interwork), but rather I can see people > interpreting the > various versions as needing to be made interoperable. As was > discussed > in INSIPID, it seems to me that if there is an expectation of > interoperability with a specific version of the draft, then we > should > publish that as informational. > > I would think it might be possible that the metadata could be > adjusted > to accommodate the earlier versions - i.e, someone that has > implemented > the RFC might be able to interoperate with a .07. But, I personally > think that likely puts undue burden and complexity on the schema. > > My understanding is that in the web world, this versioning is > the norm. > However, in the web world, software changes very frequently. > In the > world in which many of these implementations will operate, the world > does not change frequently. Thus, someone that has implemented > .07 is > likely not to implement the RFC for a while. > > Mary. > > > On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R > > > wrote: > > Hi all, > > I like the idea of using version in XML namespace. > Including Peter > in this > mail thread to get XML expert comments in this approach. > > BTW, While Mary discussed about SIPREC version in the > meeting, I > worried a > bit in case Vendor/Customer consider the draft version as a > standard > compliance. It may be possible in the future as today, I'm > seeing the > convention of requesting & showing the standard compliance for > informational > RFC. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org > ] On > Behalf Of > Paul Kyzivat > Sent: Friday, November 09, 2012 7:34 PM > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication > > On 11/8/12 4:31 PM, Brian Rosen wrote: > > In the meeting today, this subject was raised again. > > > > There is a nuance that was discussed, which was coming > up with a > way to > know versions of the metadata prior to publication. > > > > Namespaces for XML in the IETF tend to look like: > > urn:ietf:params:xml:ns:foo > > > > I would propose that we have the namespace here be: > > urn:ietf:params:xml:ns:__recording: > > > > I propose that drafts have the = 0. > > so, for example: urn:ietf:params:xml:ns:__recording:0.09 > > I propose that the text have an RFC editor note to > replace the > version > with "1.0" when the RFC is published > > Having the version coupled to the version of the draft is > attractive in > its simplicity. But it is a bit messy when there are > versions of the > metatdata that don't change the schema. But that hardly > ever happens, so > maybe it doesn't matter. > > With this scheme we will have to think of something else > beyond V1.0. > But I suppose we will then have a bis draft then and we can > use the same > scheme with that. > > So yes, this WFM. > > Thanks, > Paul > > > Brian > > > > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) > > > wrote: > > > >> [Channeling recommendation from Matt] > >> > >> In the XMPP Standards Foundation (XSF), we started to > include > versioning > into the XML namespace: > >> > >> urn:xmpp:{protocol-shortname}:__{version} > >> > >> For instance, Message Carbons (specified in XEP-0280) > uses the > namespace > "urn:xmpp:carbons:2". > >> > >> Now, the version number doesn't update with each > revision of the > specification. Instead, it updates with any change that is not > compatible > with the previous protocol version. Also, once the XEP > moves from > "Experimental" (roughly analogous to internet-drafts; many > changes > possible) > to "Draft" (roughly analogous to RFC; changes are very > minimal, mostly > clarifications), the protocol version is *NOT CHANGED*. > >> > >> This seems to be working out well for us; it means that > anyone > that's up > to date from the experimental phase is current when we go > draft/recommended-to-__implement. > >> > >> - m&m > >> > >> Matt Miller < mamille2@cisco.com > > > >> Cisco Systems, Inc. > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org > ] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Thursday, October 25, 2012 10:09 AM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Metadata version indication > >>> > >>> I forgot: another alternative is a mime type parameter. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: > >>>> I appreciate the problem here. There are a variety of > ways to > solve it. > >>>> > >>>> The obvious one would be to keep changing the > content-type, by > >>> embedding > >>>> a version number in the mime-type name itself. This could > present some > >>>> logistical difficulties as we transition from draft > to RFC. I > guess it > >>>> might also not be approved by mime gurus. It has the > advantage > that you > >>>> won't accidentally try to parse a syntax you aren't > prepared for. > >>>> > >>>> Another way is to change the xmlns urn for each > draft. As long > as every > >>>> version starts with the element that will be > sufficient to > >>>> disambiguate without getting into parsing trouble. > >>>> > >>>> Another would be to add another (optional?) attribute > to the > > >>>> element. > >>>> > >>>> I don't know enough about XML to have a strong preference > among these. > >>>> > >>>> But it may be a little late for this. How many more > changes to the > >>>> schema do we expect before RFC? > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: > >>>>> Hi Ofir, > >>>>> > >>>>> This issues was raised earlier by Hadriel. I agree > that it is > good to > >>>>> have "version" element inside recording element to > indicate the > current > >>>>> version of the SIPREC metadata. This helps in case the > metadata is > >>>>> extended from 1.0 to 2.0 by the update of RFC. > >>>>> > >>>>> I'm not very sure whether it is accepted in IETF > draft to > update the > >>>>> version of XML schema for each revision of the > draft. For > example, the > >>>>> current version for the metadata draft will be 0.8 > and the next > revision > >>>>> of the draft will be updated as 0.9. Let us look more > comments for the > >>>>> generic approach to solve this issue. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Partha > >>>>> > >>>>> *From:*siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org > ] *On > >>>>> Behalf Of *Ofir Roth > >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM > >>>>> *To:* siprec@ietf.org > >>>>> *Subject:* [siprec] Metadata version indication > >>>>> > >>>>> Hi, > >>>>> > >>>>> From our experience in SIPREC implementations, we > often come > across > >>>>> vendors that use different versions of the SIPREC > metadata > versions > >>>>> (which are not necessarily aligned with the latest > version of > metadata). > >>>>> > >>>>> AFAIK, there is no way to indicate the metadata > version as > part of the > >>>>> XML/SIP headers. > >>>>> > >>>>> I think that having such indication will be very > useful for > SIPREC > >>>>> implementers as they can reject or handle the metadata > according to > >>>>> their ability to use those versions. > >>>>> > >>>>> I will appreciate your comment on that. > >>>>> > >>>>> Thanks, > >>>>> Ofir Roth. > >>>>> > >>>>> > >>>>> > >>>>> _________________________________________________ > >>>>> 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 br@brianrosen.net Wed Nov 14 09:10: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 A8EAD21F865D for ; Wed, 14 Nov 2012 09:10:40 -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=[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 lSy9cJa-kd17 for ; Wed, 14 Nov 2012 09:10:40 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4965A21F8651 for ; Wed, 14 Nov 2012 09:10:38 -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=n5Ktt+q6+Aarlwl4a3t2Gy5BKPH/YaH9Pto8tEEC3bo=; b=f8u97i04W+L5ImNzsXjfLmC4I1qrgiDa9hiI5Wq+UPcIZ1491Q/UnjMYq3cOeXBrqt16zzwEVJ46VFqsh/CLeexfgxQQI/T2UP6UXvNOlGN6/GDev09JdRiVTx0A8LLv; Received: from neustargw.va.neustar.com ([209.173.53.233]:54489 helo=[10.33.184.108]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TYgU0-0005LH-9E; Wed, 14 Nov 2012 12:10:36 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: <50A3CD51.7050504@alum.mit.edu> Date: Wed, 14 Nov 2012 12:10:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> To: Paul Kyzivat 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" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 17:10:40 -0000 > If we were building a mechanism solely for this pre-release purpose I = would be opposed. I see this as installing a mechanism that will work = for version 1.0 and future standardized extensions/revisions of it. And = then it is convenient that the same mechanism can be used for this = pre-standard testing as well. >=20 This= From mary.ietf.barnes@gmail.com Wed Nov 14 12:07: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 5746421F88EE for ; Wed, 14 Nov 2012 12:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 qVcUSk0SV03J for ; Wed, 14 Nov 2012 12:07:17 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3821F8669 for ; Wed, 14 Nov 2012 12:07:15 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so737384lah.31 for ; Wed, 14 Nov 2012 12:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZcT3zGRbmP35YgzdMPHvuDYrqR6W8TEnPSODXoACK0g=; b=gL28WKMBlnbXkyEVFjtnGM6+4Yz3rl08dnsbWKMIIyVrcndECgvX4QVH3sNJPQYI55 WCFK7Rsq9Nj8hb6E3cpS+vB2V2KFavcg7rTylLodEISkQu+X9vaOvS0AlxpuW9wY77sk Byp+ZGjrxtITmPEAlFIatiMi7P1K8hP5wsreS2MERVHfRx5mdA8g5jjGDGGqe3AWenl8 Ka7CYDpXy7VnUtLsXTmOsTwWi/mTRMahwKAX//lhOM3VJUMa9UXbTpIcaqGc/EiUYMEW 7Xc1MyGKvMzi9eHRfiQmd1GKeonAvNhAeruyaTivgfwDukRJNxA6tiZnGKWr+Dz7nO3J oOzw== MIME-Version: 1.0 Received: by 10.112.38.163 with SMTP id h3mr11108189lbk.134.1352923634601; Wed, 14 Nov 2012 12:07:14 -0800 (PST) Received: by 10.114.69.139 with HTTP; Wed, 14 Nov 2012 12:07:14 -0800 (PST) In-Reply-To: <50A3CD51.7050504@alum.mit.edu> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> Date: Wed, 14 Nov 2012 14:07:14 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e0cb4efe2a7aa611eb04ce7a146c Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 20:07:19 -0000 --e0cb4efe2a7aa611eb04ce7a146c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 10:56 AM, Paul Kyzivat wrote: > On 11/13/12 5:33 PM, Mary Barnes wrote: > >> I still don't get Hadriel's point then as he seemed concerned about >> what's in the field right now. If we are saying version 10 is the draft >> folks should implement now while they wait for the RFC, then publish >> that as experimental. >> > > Publishing as experimental is way too heavy weight for the purpose here. [MB] I somewhat disagree that this is heavyweight but it's not worth debating. /MB] > > > I would also think that designing the metadata with extensibilIty would >> help for the folks that might want interoperability with earlier versions. >> > > I don't want to see us confine ourselves to backward compatible changes > before we get to version 1.0. [MB] Yeah. I said in my first response that this likely would be too restrictive. [/MB] > > > I also think that you should not go by draft versions. You should go by >> actual versions of the metadata. People that aren't directly involved >> in this (e.g., people who review RFPs, etc.) won't at all get the >> subtlety that you might be able to implement different versions and have >> the document still contain the same metadata. If you go the version >> route, you're going to need explanatory text somewhere as to which >> versions have the same metadata. >> > > I had also been thinking of counting versions independently of draft > version numbers. Brian suggested using draft version numbers. (Prior to > 1.0.) While that has the potential disadvantage of showing change when > there is none, I think every version of the doc to date has had some change > to the schema, so I don't think it is such a risk. And there is great > convenience in tying it to the draft version number. So I was happy to go > along with this, though I don't feel strongly about it. > > > I understand the need for folks to deploy products now based upon specs >> that might be out there. >> > > AFAIK we are not talking about *products*. Rather we are talking about > *prototypes*, and testing of interoperability among prototypes. [MB] If you are talking about prototypes, then why do you need the version number in the protocol? Why can't the people that are doing the testing *ask* what version is supported. If they are not the same, then you are wasting your time trying to test, right? Or, is the expectation that someone that has implemented .11 MUST be able to interoperate with .10? I don't think that's what you are suggesting. > > But, IMHO, that's at their own risk and I >> really think we're going down a rathole if for every new set of protocol >> work, we are going to make sure that there's at least one version of the >> draft that still works. >> > > If we were building a mechanism solely for this pre-release purpose I > would be opposed. I see this as installing a mechanism that will work for > version 1.0 and future standardized extensions/revisions of it. And then it > is convenient that the same mechanism can be used for this pre-standard > testing as well. > [MB] I agree that you need a version number. 1.0 for the first version of the RFC and then 2.0 if you do a bis. If someone wants to put the .10 in there and work with another vendor to see if their .10 software works with the other guy's, I don't see that this requires anything to be put into the documents being produced by this WG. Nor, do I think it requires any more discussion. We don't develops specs to ensure that prototypes (and various draft versions) are interoperable, we do prototypes to ensure the final RFCs enable interoperability. Certainly, the former would be a good thing as that means the document is headed in the right direction. [/MB] > > Thanks, > Paul > > Mary. >> >> On Tuesday, November 13, 2012, Paul Kyzivat wrote: >> >> Mary, >> >> IMO, the first draft that incorporates this idea (say it is -10, >> since -09 didn't) will include the version number 0.10 in the schema >> URN. E.g. >> >> urn:ietf:params:xml:ns:__**recording:0.10 >> >> >> Implementations of that will include this URN. Older implementations >> will not have a version number in their namespace urn. Then: >> >> - Older versions interoperating (or not) with each other will >> continue unchanged. >> >> - Older versions interoperating with new versions won't understand >> the versioning, but will presumably note the mismatch of schema URN >> and maybe punt. >> >> - Newer versions interoperating with versions prior to -10 will note >> the mismatch, as they will when interoperating with versions >= >> to -10 that differ from their own. >> >> Thanks, >> Paul >> >> >> >> On 11/13/12 3:30 PM, Mary Barnes wrote: >> >> I would like to understand better the WG perspective on this >> version. >> My understanding from Hadriel was that the only use for this >> is for a >> version 1.0 system (per the RFC to be) to know that it can't >> interface >> with a .07, for example. The reasoning seems to be that people >> have >> already implemented various versions of the draft. So, it seems >> the >> primary reason is so that one would know right off whether the >> implementations were compatible. However, that does require that >> existing implementations make changes to add their version >> number. How >> many of these implementations are out there now? >> >> My expectation and what I was expressing at the microphone is as >> Partha >> suggests, vendor A has implemented .07 and vendor B has >> implemented the >> RFC. Since vendor A also still interfaces with systems that also >> implemented .07, they need to support both in their product. >> Thus, I >> can't see people using the version number as Hadriel suggests >> (i.e., >> know you can't interwork), but rather I can see people >> interpreting the >> various versions as needing to be made interoperable. As was >> discussed >> in INSIPID, it seems to me that if there is an expectation of >> interoperability with a specific version of the draft, then we >> should >> publish that as informational. >> >> I would think it might be possible that the metadata could be >> adjusted >> to accommodate the earlier versions - i.e, someone that has >> implemented >> the RFC might be able to interoperate with a .07. But, I >> personally >> think that likely puts undue burden and complexity on the schema. >> >> My understanding is that in the web world, this versioning is >> the norm. >> However, in the web world, software changes very frequently. >> In the >> world in which many of these implementations will operate, the >> world >> does not change frequently. Thus, someone that has implemented >> .07 is >> likely not to implement the RFC for a while. >> >> Mary. >> >> >> On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R >> >> >> >> wrote: >> >> Hi all, >> >> I like the idea of using version in XML namespace. >> Including Peter >> in this >> mail thread to get XML expert comments in this approach. >> >> BTW, While Mary discussed about SIPREC version in the >> meeting, I >> worried a >> bit in case Vendor/Customer consider the draft version as a >> standard >> compliance. It may be possible in the future as today, I'm >> seeing the >> convention of requesting & showing the standard compliance >> for >> informational >> RFC. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org > org > >> [mailto:siprec-bounces@ietf.**org >> >] On >> Behalf Of >> Paul Kyzivat >> Sent: Friday, November 09, 2012 7:34 PM >> To: Brian Rosen >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Metadata version indication >> >> On 11/8/12 4:31 PM, Brian Rosen wrote: >> > In the meeting today, this subject was raised again. >> > >> > There is a nuance that was discussed, which was coming >> up with a >> way to >> know versions of the metadata prior to publication. >> > >> > Namespaces for XML in the IETF tend to look like: >> > urn:ietf:params:xml:ns:foo >> > >> > I would propose that we have the namespace here be: >> > urn:ietf:params:xml:ns:__**recording: >> >> > >> > I propose that drafts have the = 0.> version> >> > so, for example: urn:ietf:params:xml:ns:__** >> recording:0.09 >> >> > I propose that the text have an RFC editor note to >> replace the >> version >> with "1.0" when the RFC is published >> >> Having the version coupled to the version of the draft is >> attractive in >> its simplicity. But it is a bit messy when there are >> versions of the >> metatdata that don't change the schema. But that hardly >> ever happens, so >> maybe it doesn't matter. >> >> With this scheme we will have to think of something else >> beyond V1.0. >> But I suppose we will then have a bis draft then and we can >> use the same >> scheme with that. >> >> So yes, this WFM. >> >> Thanks, >> Paul >> >> > Brian >> > >> > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) >> > >> wrote: >> > >> >> [Channeling recommendation from Matt] >> >> >> >> In the XMPP Standards Foundation (XSF), we started to >> include >> versioning >> into the XML namespace: >> >> >> >> urn:xmpp:{protocol-shortname}:**__{version} >> >> >> >> >> For instance, Message Carbons (specified in XEP-0280) >> uses the >> namespace >> "urn:xmpp:carbons:2". >> >> >> >> Now, the version number doesn't update with each >> revision of the >> specification. Instead, it updates with any change that is >> not >> compatible >> with the previous protocol version. Also, once the XEP >> moves from >> "Experimental" (roughly analogous to internet-drafts; many >> changes >> possible) >> to "Draft" (roughly analogous to RFC; changes are very >> minimal, mostly >> clarifications), the protocol version is *NOT CHANGED*. >> >> >> >> This seems to be working out well for us; it means that >> anyone >> that's up >> to date from the experimental phase is current when we go >> draft/recommended-to-__**implement. >> >> >> >> >> - m&m >> >> >> >> Matt Miller < mamille2@cisco.com >> > >> >> Cisco Systems, Inc. >> >> >> >>> -----Original Message----- >> >>> From: siprec-bounces@ietf.org >> > >> [mailto:siprec-bounces@ietf.**org >> >] On >> Behalf >> >>> Of Paul Kyzivat >> >>> Sent: Thursday, October 25, 2012 10:09 AM >> >>> To: siprec@ietf.org >> >>> Subject: Re: [siprec] Metadata version indication >> >>> >> >>> I forgot: another alternative is a mime type parameter. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>> On 10/24/12 12:03 PM, Paul Kyzivat wrote: >> >>>> I appreciate the problem here. There are a variety of >> ways to >> solve it. >> >>>> >> >>>> The obvious one would be to keep changing the >> content-type, by >> >>> embedding >> >>>> a version number in the mime-type name itself. This >> could >> present some >> >>>> logistical difficulties as we transition from draft >> to RFC. I >> guess it >> >>>> might also not be approved by mime gurus. It has the >> advantage >> that you >> >>>> won't accidentally try to parse a syntax you aren't >> prepared for. >> >>>> >> >>>> Another way is to change the xmlns urn for each >> draft. As long >> as every >> >>>> version starts with the element that will >> be >> sufficient to >> >>>> disambiguate without getting into parsing trouble. >> >>>> >> >>>> Another would be to add another (optional?) attribute >> to the >> >> >>>> element. >> >>>> >> >>>> I don't know enough about XML to have a strong >> preference >> among these. >> >>>> >> >>>> But it may be a little late for this. How many more >> changes to the >> >>>> schema do we expect before RFC? >> >>>> >> >>>> Thanks, >> >>>> Paul >> >>>> >> >>>> On 10/24/12 5:19 AM, Parthasarathi R wrote: >> >>>>> Hi Ofir, >> >>>>> >> >>>>> This issues was raised earlier by Hadriel. I agree >> that it is >> good to >> >>>>> have "version" element inside recording element to >> indicate the >> current >> >>>>> version of the SIPREC metadata. This helps in case the >> metadata is >> >>>>> extended from 1.0 to 2.0 by the update of RFC. >> >>>>> >> >>>>> I'm not very sure whether it is accepted in IETF >> draft to >> update the >> >>>>> version of XML schema for each revision of the >> draft. For >> example, the >> >>>>> current version for the metadata draft will be 0.8 >> and the next >> revision >> >>>>> of the draft will be updated as 0.9. Let us look more >> comments for the >> >>>>> generic approach to solve this issue. >> >>>>> >> >>>>> Thanks >> >>>>> >> >>>>> Partha >> >>>>> >> >>>>> *From:*siprec-bounces@ietf.org >> > >> [mailto:siprec-bounces@ietf.**org >> >] >> *On >> >>>>> Behalf Of *Ofir Roth >> >>>>> *Sent:* Wednesday, October 24, 2012 1:09 PM >> >>>>> *To:* siprec@ietf.org >> >>>>> *Subject:* [siprec] Metadata version indication >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> From our experience in SIPREC implementations, we >> often come >> across >> >>>>> vendors that use different versions of the SIPREC >> metadata >> versions >> >>>>> (which are not necessarily aligned with the latest >> version of >> metadata). >> >>>>> >> >>>>> AFAIK, there is no way to indicate the metadata >> version as >> part of the >> >>>>> XML/SIP headers. >> >>>>> >> >>>>> I think that having such indication will be very >> useful for >> SIPREC >> >>>>> implementers as they can reject or handle the metadata >> according to >> >>>>> their ability to use those versions. >> >>>>> >> >>>>> I will appreciate your comment on that. >> >>>>> >> >>>>> Thanks, >> >>>>> Ofir Roth. >> >>>>> >> >>>>> >> >>>>> >> >>>>> ______________________________**___________________ >> >> >>>>> 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 >> >> > >> >> >> >> > --e0cb4efe2a7aa611eb04ce7a146c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, N= ov 14, 2012 at 10:56 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 11/13/12 5:33 PM, Mary = Barnes wrote:
I still don't get Hadriel's point then as he seemed concerned about=
what's in the field right now. =A0If we are saying version 10 is the dr= aft
folks should implement now while they wait for the RFC, then publish
that as experimental.

Publishing as experimental is way too heavy weight for the purpose here.
[MB] =A0I somewhat disagree that this is heavyweight but it&= #39;s not worth debating. /MB]=A0


I would also think that designing the metadata with extensibilIty would
help for the folks that might want interoperability with earlier versions.<= br>

I don't want to see us confine ourselves to backward compatible changes= before we get to version 1.0.
[MB] Yeah. =A0I said in my = first response that this likely would be too restrictive. [/MB]=A0


I also think that you should not go by draft versions. =A0You should go by<= br> actual versions of the metadata. =A0People that aren't directly involve= d
in this (e.g., people who review RFPs, etc.) won't at all get the
subtlety that you might be able to implement different versions and have the document still contain the same metadata. =A0If you go the version
route, you're going to need explanatory text somewhere as to which
versions have the same metadata.

I had also been thinking of counting versions independently of draft versio= n numbers. Brian suggested using draft version numbers. (Prior to 1.0.) Whi= le that has the potential disadvantage of showing change when there is none= , I think every version of the doc to date has had some change to the schem= a, so I don't think it is such a risk. And there is great convenience i= n tying it to the draft version number. So I was happy to go along with thi= s, though I don't feel strongly about it.


I understand the need for folks to deploy products now based upon specs
that might be out there.

AFAIK we are not talking about *products*. Rather we are talking about *pro= totypes*, and testing of interoperability among prototypes.
[MB] If you are talking about prototypes, then why do you need the versio= n number in the protocol? =A0Why can't the people that are doing the te= sting *ask* what version is supported. =A0If they are not the same, then yo= u are wasting your time trying to test, right? =A0 Or, is the expectation t= hat someone that has implemented .11 MUST be able to interoperate with .10?= =A0I don't think that's what you are suggesting. =A0=A0

But, IMHO, that's at their own risk and I
really think we're going down a rathole if for every new set of protoco= l
work, we are going to make sure that there's at least one version of th= e
draft that still works.

If we were building a mechanism solely for this pre-release purpose I would= be opposed. I see this as installing a mechanism that will work for versio= n 1.0 and future standardized extensions/revisions of it. And then it is co= nvenient that the same mechanism can be used for this pre-standard testing = as well.
[MB] I agree that you need a version number. 1.0 for the = first version of the RFC and then 2.0 if you do a bis. =A0If someone wants = to put the .10 in there and work with another vendor to see if their .10 so= ftware works with the other guy's, I don't see that this requires a= nything to be put into the documents being produced by this WG. Nor, do I t= hink it requires any more discussion. =A0We don't develops specs to ens= ure that prototypes (and various draft versions) are interoperable, we do p= rototypes to ensure the final RFCs enable interoperability. =A0Certainly, t= he former would be a good thing as that means the document is headed in the= right direction. [/MB]

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Mary.

On Tuesday, November 13, 2012, Paul Kyzivat wrote:

=A0 =A0 Mary,

=A0 =A0 IMO, the first draft that incorporates this idea (say it is -10, =A0 =A0 since -09 didn't) will include the version number 0.10 in the s= chema
=A0 =A0 URN. E.g.

=A0 =A0 urn:ietf:params:xml:ns:__recording:0.10


=A0 =A0 Implementations of that will include this URN. Older implementation= s
=A0 =A0 will not have a version number in their namespace urn. Then:

=A0 =A0 - Older versions interoperating (or not) with each other will
=A0 =A0 =A0 =A0continue unchanged.

=A0 =A0 - Older versions interoperating with new versions won't underst= and
=A0 =A0 =A0 =A0the versioning, but will presumably note the mismatch of sch= ema URN
=A0 =A0 =A0 =A0and maybe punt.

=A0 =A0 - Newer versions interoperating with versions prior to -10 will not= e
=A0 =A0 =A0 =A0the mismatch, as they will when interoperating with versions= >=3D
=A0 =A0 =A0 =A0to -10 that differ from their own.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul



=A0 =A0 On 11/13/12 3:30 PM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 I would like to understand better the WG perspective on thi= s
=A0 =A0 =A0 =A0 version.
=A0 =A0 =A0 =A0 =A0 =A0My understanding from Hadriel was that the only use = for this
=A0 =A0 =A0 =A0 is for a
=A0 =A0 =A0 =A0 version 1.0 system (per the RFC to be) to know that it can&= #39;t
=A0 =A0 =A0 =A0 interface
=A0 =A0 =A0 =A0 with a .07, for example. =A0The reasoning seems to be that = people have
=A0 =A0 =A0 =A0 already implemented various versions of the draft. =A0So, i= t seems the
=A0 =A0 =A0 =A0 primary reason is so that one would know right off whether = the
=A0 =A0 =A0 =A0 implementations were compatible. =A0However, that does requ= ire that
=A0 =A0 =A0 =A0 existing implementations make changes to add their version<= br> =A0 =A0 =A0 =A0 number. =A0 How
=A0 =A0 =A0 =A0 many of these implementations are out there now?

=A0 =A0 =A0 =A0 My expectation and what I was expressing at the microphone = is as
=A0 =A0 =A0 =A0 Partha
=A0 =A0 =A0 =A0 suggests, vendor A has implemented .07 and vendor B has
=A0 =A0 =A0 =A0 implemented the
=A0 =A0 =A0 =A0 RFC. =A0Since vendor A also still interfaces with systems t= hat also
=A0 =A0 =A0 =A0 implemented .07, they need to support both in their product= . Thus, I
=A0 =A0 =A0 =A0 can't see people using the version number as Hadriel su= ggests (i.e.,
=A0 =A0 =A0 =A0 know you can't interwork), but rather I can see people<= br> =A0 =A0 =A0 =A0 interpreting the
=A0 =A0 =A0 =A0 various versions as needing to be made interoperable. =A0As= was
=A0 =A0 =A0 =A0 discussed
=A0 =A0 =A0 =A0 in INSIPID, it seems to me that if there is an expectation = of
=A0 =A0 =A0 =A0 interoperability with a specific version of the draft, then= we
=A0 =A0 =A0 =A0 should
=A0 =A0 =A0 =A0 publish that as informational.

=A0 =A0 =A0 =A0 I would think it might be possible that the metadata could = be
=A0 =A0 =A0 =A0 adjusted
=A0 =A0 =A0 =A0 to accommodate the earlier versions - i.e, someone that has=
=A0 =A0 =A0 =A0 implemented
=A0 =A0 =A0 =A0 the RFC might be able to interoperate with a .07. =A0But, I= personally
=A0 =A0 =A0 =A0 think that likely puts undue burden and =A0complexity on th= e schema.

=A0 =A0 =A0 =A0 My understanding is that in the web world, this versioning = is
=A0 =A0 =A0 =A0 the norm.
=A0 =A0 =A0 =A0 =A0 =A0However, in the web world, software changes very fre= quently.
=A0 =A0 =A0 =A0 =A0 In the
=A0 =A0 =A0 =A0 world in which many of these implementations will operate, = the world
=A0 =A0 =A0 =A0 does not change frequently. =A0Thus, someone that has imple= mented
=A0 =A0 =A0 =A0 .07 is
=A0 =A0 =A0 =A0 likely not to implement the RFC for a while.

=A0 =A0 =A0 =A0 Mary.


=A0 =A0 =A0 =A0 On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R
=A0 =A0 =A0 =A0 <partha@parthasarathi.co.in <mailto:partha@parthasarathi.co.in>>
=A0 =A0 =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0Hi all,

=A0 =A0 =A0 =A0 =A0 =A0 =A0I like the idea of using version in XML namespac= e.
=A0 =A0 =A0 =A0 Including Peter
=A0 =A0 =A0 =A0 =A0 =A0 =A0in this
=A0 =A0 =A0 =A0 =A0 =A0 =A0mail thread to get XML expert comments in this a= pproach.

=A0 =A0 =A0 =A0 =A0 =A0 =A0BTW, While Mary discussed about SIPREC version i= n the
=A0 =A0 =A0 =A0 meeting, I
=A0 =A0 =A0 =A0 =A0 =A0 =A0worried a
=A0 =A0 =A0 =A0 =A0 =A0 =A0bit in case Vendor/Customer consider the draft v= ersion as a
=A0 =A0 =A0 =A0 standard
=A0 =A0 =A0 =A0 =A0 =A0 =A0compliance. It may be possible in the future as = today, I'm
=A0 =A0 =A0 =A0 seeing the
=A0 =A0 =A0 =A0 =A0 =A0 =A0convention of requesting & showing the stand= ard compliance for
=A0 =A0 =A0 =A0 =A0 =A0 =A0informational
=A0 =A0 =A0 =A0 =A0 =A0 =A0RFC.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks
=A0 =A0 =A0 =A0 =A0 =A0 =A0Partha

=A0 =A0 =A0 =A0 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0From: siprec-bounces@ietf.org <mailto:siprec-bounces@ietf.org<= /a>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0[mailto:siprec-bounces@ietf.org
=A0 =A0 =A0 =A0 <mailto:siprec-bounces@ietf.org>] On
=A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf Of
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul Kyzivat
=A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Friday, November 09, 2012 7:34 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0To: Brian Rosen
=A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [siprec] Metadata version indicatio= n

=A0 =A0 =A0 =A0 =A0 =A0 =A0On 11/8/12 4:31 PM, Brian Rosen wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > In the meeting today, this subject was rai= sed again.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > There is a nuance that was discussed, whic= h was coming
=A0 =A0 =A0 =A0 up with a
=A0 =A0 =A0 =A0 =A0 =A0 =A0way to
=A0 =A0 =A0 =A0 =A0 =A0 =A0know versions of the metadata prior to publicati= on.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > Namespaces for XML in the IETF tend to loo= k like:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > urn:ietf:params:xml:ns:foo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > I would propose that we have the namespace= here be:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > urn:ietf:params:xml:ns:__recording:= <version>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > I propose that drafts have the <Version= > =3D 0.<draft version>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > so, for example: urn:ietf:params:xml:ns:__= recording:0.09

=A0 =A0 =A0 =A0 =A0 =A0 =A0 > I propose that the text have an RFC editor= note to
=A0 =A0 =A0 =A0 replace the
=A0 =A0 =A0 =A0 =A0 =A0 =A0version
=A0 =A0 =A0 =A0 =A0 =A0 =A0with "1.0" when the RFC is published
=A0 =A0 =A0 =A0 =A0 =A0 =A0Having the version coupled to the version of the= draft is
=A0 =A0 =A0 =A0 attractive in
=A0 =A0 =A0 =A0 =A0 =A0 =A0its simplicity. But it is a bit messy when there= are
=A0 =A0 =A0 =A0 versions of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0metatdata that don't change the schema. But = that hardly
=A0 =A0 =A0 =A0 ever happens, so
=A0 =A0 =A0 =A0 =A0 =A0 =A0maybe it doesn't matter.

=A0 =A0 =A0 =A0 =A0 =A0 =A0With this scheme we will have to think of someth= ing else
=A0 =A0 =A0 =A0 beyond V1.0.
=A0 =A0 =A0 =A0 =A0 =A0 =A0But I suppose we will then have a bis draft then= and we can
=A0 =A0 =A0 =A0 use the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0scheme with that.

=A0 =A0 =A0 =A0 =A0 =A0 =A0So yes, this WFM.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul

=A0 =A0 =A0 =A0 =A0 =A0 =A0 > Brian
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > On Oct 26, 2012, at 2:52 PM, Charles Eckel= (eckelcu)
=A0 =A0 =A0 =A0 =A0 =A0 =A0<eckelcu@cisco.com <mailto:eckelcu@cisco.com>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> [Channeling recommendation from Matt]<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> In the XMPP Standards Foundation (XSF)= , we started to
=A0 =A0 =A0 =A0 include
=A0 =A0 =A0 =A0 =A0 =A0 =A0versioning
=A0 =A0 =A0 =A0 =A0 =A0 =A0into the XML namespace:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0urn:xmpp:{protocol-shortnam= e}:__{version}

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> For instance, Message Carbons (specifi= ed in XEP-0280)
=A0 =A0 =A0 =A0 uses the
=A0 =A0 =A0 =A0 =A0 =A0 =A0namespace
=A0 =A0 =A0 =A0 =A0 =A0 =A0"urn:xmpp:carbons:2".
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> Now, the version number doesn't up= date with each
=A0 =A0 =A0 =A0 revision of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0specification. =A0Instead, it updates with any c= hange that is not
=A0 =A0 =A0 =A0 =A0 =A0 =A0compatible
=A0 =A0 =A0 =A0 =A0 =A0 =A0with the previous protocol version. =A0Also, onc= e the XEP
=A0 =A0 =A0 =A0 moves from
=A0 =A0 =A0 =A0 =A0 =A0 =A0"Experimental" (roughly analogous to i= nternet-drafts; many
=A0 =A0 =A0 =A0 changes
=A0 =A0 =A0 =A0 =A0 =A0 =A0possible)
=A0 =A0 =A0 =A0 =A0 =A0 =A0to "Draft" (roughly analogous to RFC; = changes are very
=A0 =A0 =A0 =A0 minimal, mostly
=A0 =A0 =A0 =A0 =A0 =A0 =A0clarifications), the protocol version is *NOT CH= ANGED*.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> This seems to be working out well for = us; it means that
=A0 =A0 =A0 =A0 anyone
=A0 =A0 =A0 =A0 =A0 =A0 =A0that's up
=A0 =A0 =A0 =A0 =A0 =A0 =A0to date from the experimental phase is current w= hen we go
=A0 =A0 =A0 =A0 =A0 =A0 =A0draft/recommended-to-__implement.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> - m&m
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> Matt Miller < mamille2@cisco.com
=A0 =A0 =A0 =A0 <mailto:mamille2@cisco.com> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> Cisco Systems, Inc.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> -----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> From: siprec-bounces@ietf.org
=A0 =A0 =A0 =A0 <mailto:siprec-bounces@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0[mailto:siprec-bounces@ietf.org
=A0 =A0 =A0 =A0 <mailto:siprec-bounces@ietf.org>] On
=A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> Of Paul Kyzivat
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> Sent: Thursday, October 25, 2012 1= 0:09 AM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> To: siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> Subject: Re: [siprec] Metadata ver= sion indication
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> I forgot: another alternative is a= mime type parameter.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 Paul
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> On 10/24/12 12:03 PM, Paul Kyzivat= wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> I appreciate the problem here.= There are a variety of
=A0 =A0 =A0 =A0 ways to
=A0 =A0 =A0 =A0 =A0 =A0 =A0solve it.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> The obvious one would be to ke= ep changing the
=A0 =A0 =A0 =A0 content-type, by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> embedding
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> a version number in the mime-t= ype name itself. This could
=A0 =A0 =A0 =A0 =A0 =A0 =A0present some
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> logistical difficulties as we = transition from draft
=A0 =A0 =A0 =A0 to RFC. I
=A0 =A0 =A0 =A0 =A0 =A0 =A0guess it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> might also not be approved by = mime gurus. It has the
=A0 =A0 =A0 =A0 advantage
=A0 =A0 =A0 =A0 =A0 =A0 =A0that you
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> won't accidentally try to = parse a syntax you aren't
=A0 =A0 =A0 =A0 prepared for.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> Another way is to change the x= mlns urn for each
=A0 =A0 =A0 =A0 draft. As long
=A0 =A0 =A0 =A0 =A0 =A0 =A0as every
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> version starts with the <re= cording> element that will be
=A0 =A0 =A0 =A0 =A0 =A0 =A0sufficient to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> disambiguate without getting i= nto parsing trouble.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> Another would be to add anothe= r (optional?) attribute
=A0 =A0 =A0 =A0 to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0<recording>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> element.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> I don't know enough about = XML to have a strong preference
=A0 =A0 =A0 =A0 =A0 =A0 =A0among these.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> But it may be a little late fo= r this. How many more
=A0 =A0 =A0 =A0 changes to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> schema do we expect before RFC= ?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0Paul
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> On 10/24/12 5:19 AM, Parthasar= athi R wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Hi Ofir,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> This issues was raised ear= lier by Hadriel. I agree
=A0 =A0 =A0 =A0 that it is
=A0 =A0 =A0 =A0 =A0 =A0 =A0good to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> have "version" e= lement inside recording element to
=A0 =A0 =A0 =A0 indicate the
=A0 =A0 =A0 =A0 =A0 =A0 =A0current
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> version of the SIPREC meta= data. This helps in case the
=A0 =A0 =A0 =A0 =A0 =A0 =A0metadata is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> extended from 1.0 to 2.0 b= y the update of RFC.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> I'm not very sure whet= her it is accepted in IETF
=A0 =A0 =A0 =A0 draft to
=A0 =A0 =A0 =A0 =A0 =A0 =A0update the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> version of XML schema for = each revision of the
=A0 =A0 =A0 =A0 draft. For
=A0 =A0 =A0 =A0 =A0 =A0 =A0example, the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> current version for the me= tadata draft will be 0.8
=A0 =A0 =A0 =A0 and the next
=A0 =A0 =A0 =A0 =A0 =A0 =A0revision
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> of the draft will be updat= ed as 0.9. Let us look more
=A0 =A0 =A0 =A0 =A0 =A0 =A0comments for the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> generic approach to solve = this issue.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Thanks
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Partha
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> *From:*siprec-bounces@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:siprec-bounces@ietf.org>
=A0 =A0 =A0 =A0 [mailto:siprec-bounces@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:siprec-bounces@ietf.org>] *On
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Behalf Of *Ofir Roth
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> *Sent:* Wednesday, October= 24, 2012 1:09 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> *To:* siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> *Subject:* [siprec] Metada= ta version indication
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Hi,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> =A0From our experience in = SIPREC implementations, we
=A0 =A0 =A0 =A0 often come
=A0 =A0 =A0 =A0 =A0 =A0 =A0across
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> vendors that use different= versions of the SIPREC
=A0 =A0 =A0 =A0 metadata
=A0 =A0 =A0 =A0 =A0 =A0 =A0versions
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> (which are not necessarily= aligned with the latest
=A0 =A0 =A0 =A0 version of
=A0 =A0 =A0 =A0 =A0 =A0 =A0metadata).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> AFAIK, there is no way to = indicate the metadata
=A0 =A0 =A0 =A0 version as
=A0 =A0 =A0 =A0 =A0 =A0 =A0part of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> XML/SIP headers.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> I think that having such i= ndication will be very
=A0 =A0 =A0 =A0 useful for
=A0 =A0 =A0 =A0 =A0 =A0 =A0SIPREC
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> implementers as they can r= eject or handle the metadata
=A0 =A0 =A0 =A0 =A0 =A0 =A0according to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> their ability to use those= versions.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> I will appreciate your com= ment on that.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> Ofir Roth.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> __________________________= _______________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> siprec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>> https://www.ietf.org/mai= lman/__listinfo/siprec
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> ______________________________= ___________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> siprec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>> https://www.ietf.org/mailman= /__listinfo/siprec
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> ______________________________<= /u>___________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> siprec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> https://www.ietf.org/mailman/__listinfo/siprec
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> _______________________________= __________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> siprec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> siprec@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >> https://www.ietf.org/mailman/__listinfo/siprec
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >

=A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________________= ________

=A0 =A0 =A0 =A0 =A0 =A0 =A0siprec mailing list
=A0 =A0 =A0 =A0 siprec= @ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/siprec=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >

=A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________________= ________

=A0 =A0 =A0 =A0 =A0 =A0 =A0siprec mailing list
=A0 =A0 =A0 =A0 siprec= @ietf.org <mailto:siprec@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/siprec=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/siprec= >





--e0cb4efe2a7aa611eb04ce7a146c-- From pkyzivat@alum.mit.edu Wed Nov 14 12:23:52 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 EDA9221F8554 for ; Wed, 14 Nov 2012 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.044, 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 PmPkRbmD+DVW for ; Wed, 14 Nov 2012 12:23:51 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 279A321F8546 for ; Wed, 14 Nov 2012 12:23:49 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id PRjX1k00K0QuhwU53YPpEP; Wed, 14 Nov 2012 20:23:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id PYPo1k00P3ZTu2S3NYPoL8; Wed, 14 Nov 2012 20:23:49 +0000 Message-ID: <50A3FDD4.9000404@alum.mit.edu> Date: Wed, 14 Nov 2012 15:23:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mary Barnes References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 20:23:52 -0000 On 11/14/12 3:07 PM, Mary Barnes wrote: > [MB] If you are talking about prototypes, then why do you need the > version number in the protocol? Why can't the people that are doing the > testing *ask* what version is supported. If they are not the same, then > you are wasting your time trying to test, right? Or, is the > expectation that someone that has implemented .11 MUST be able to > interoperate with .10? I don't think that's what you are suggesting. I'll let Hadriel speak to this. > But, IMHO, that's at their own risk and I > really think we're going down a rathole if for every new set of > protocol > work, we are going to make sure that there's at least one > version of the > draft that still works. > > > If we were building a mechanism solely for this pre-release purpose > I would be opposed. I see this as installing a mechanism that will > work for version 1.0 and future standardized extensions/revisions of > it. And then it is convenient that the same mechanism can be used > for this pre-standard testing as well. > > [MB] I agree that you need a version number. 1.0 for the first version > of the RFC and then 2.0 if you do a bis. If someone wants to put the > .10 in there and work with another vendor to see if their .10 software > works with the other guy's, I don't see that this requires anything to > be put into the documents being produced by this WG. Nor, do I think it > requires any more discussion. I don't expect anything to be in the document about how pre-1.0 versions are assigned. (That wouldn't be very useful when the RFC is published.) But the editor of the metadata draft does need to know what to put into the draft schemas. Consider it an informal agreement. I wouldn't object to a to-be-removed-by-RFC-editor note. > We don't develops specs to ensure that > prototypes (and various draft versions) are interoperable, we do > prototypes to ensure the final RFCs enable interoperability. Certainly, > the former would be a good thing as that means the document is headed in > the right direction. [/MB] I'm not inclined to be sympathetic to people who whine that the RFC is incompatible with some implementation they made of a pre-RFC draft. But I am fine with doing trivial things that ease testing and getting to RFC-compatible implementations. Thanks, Paul From mamille2@cisco.com Wed Nov 14 12:39: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 253F821F8792 for ; Wed, 14 Nov 2012 12:39:41 -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 RmtGjazZ8kW4 for ; Wed, 14 Nov 2012 12:39:40 -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 D45CA21F8749 for ; Wed, 14 Nov 2012 12:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6337; q=dns/txt; s=iport; t=1352925580; x=1354135180; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mKI67InR7N8QMIlz8XEncqObovq5H8JjmuKRtpqX34o=; b=D3eof5dwxjtJ0S2Cf5ZKYsFKHLxWeZrtg5JvYrYnIcPuoIjlSHGBpv0b UICh/nJRHrwhnWtHuGxY92rG80xfvdSIgBJoLuj8WSboL6YCjQ1L8/2Hs EyPHetx9Au0yAt/LDidrxxcHm+CEZLXYH4ECRU+dZYr1zvofCJbVLPkNL I=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMYApFCtJXHA/2dsb2JhbABEw0KBCIIeAQEBBBIBZhACAQgYCiQCHxElAgQOBQgGFIdXAw+bL5YvDYlUi0RphUthA457gSGEC4JxihaDJoFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="139443796" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2012 20:39:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAEKddnL006248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 20:39:39 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 14:39:38 -0600 From: "Matt Miller (mamille2)" To: Mary Barnes Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7QADLHTgABj1KoAANJHWgAArWiigAqADU4AAIqaqgACedPwAADgv8YAAAUhGAAADBasAACaJ6YAABqZ1AAABIa0A Date: Wed, 14 Nov 2012 20:39:38 +0000 Message-ID: References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.154] Content-Type: multipart/signed; boundary="Apple-Mail=_BF8FE690-94A2-42B1-AA27-C141D28A91B5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 20:39:41 -0000 --Apple-Mail=_BF8FE690-94A2-42B1-AA27-C141D28A91B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 14, 2012, at 1:07 PM, Mary Barnes wrote: >> If we were building a mechanism solely for this pre-release purpose I >> would be opposed. I see this as installing a mechanism that will work = for >> version 1.0 and future standardized extensions/revisions of it. And = then it >> is convenient that the same mechanism can be used for this = pre-standard >> testing as well. >>=20 > [MB] I agree that you need a version number. 1.0 for the first version = of > the RFC and then 2.0 if you do a bis. If someone wants to put the .10 = in > there and work with another vendor to see if their .10 software works = with > the other guy's, I don't see that this requires anything to be put = into the > documents being produced by this WG. Nor, do I think it requires any = more > discussion. We don't develops specs to ensure that prototypes (and = various > draft versions) are interoperable, we do prototypes to ensure the = final > RFCs enable interoperability. Certainly, the former would be a good = thing > as that means the document is headed in the right direction. [/MB] Anecdotal evidence from my work in the XMPP Standards Foundation (XSF): The XSF started with namespaces (e.g. "http://jabber.org/protocol/muc") = that did not change once a document was published. This worked in a = perfect world, where these implementers are in perfect lockstep with = each other, always updating to the current state of the I-D within = moments (maybe days) of its publication, up to the point it becomes an = RFC. But we do not live in a perfect world, and people develop at different = rates, and sometimes step away from something for a while and might miss = a couple of I-D versions. I dare say that some here might even deploy = software based on an intermediate version, for various reasons we = probably don't agree with ideologically. So, the XSF moved to using one namespace for the I-D like phase (e.g. = "urn:xmpp:time:tmp") and a different for the RFC phase (e.g. = "urn:xmpp:time"). This helped differentiate between "pre-RFC" versions = from "at-RFC" versions, but it was painfully annoying to implementers = because they had to go through changes and deployment of those changes = simply for a change of a constant. 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. I don't know how much this applies here; feel free to use all, none, or = some level in between. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_BF8FE690-94A2-42B1-AA27-C141D28A91B5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTExNDIwMzkz OVowIwYJKoZIhvcNAQkEMRYEFEA+LKnX4EZz6kYZ/Iuz8yZp6TeEMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCEn9T47wdC5O8Yv1I7b06NyFkYnnQe09rpYeEGFSEdSyYupbSwlgJMacSs DnZ65+Z1TMEwKRFVwho/Wfst4J3sAxkfkOy1kKjN/nAi0+43fg3+kv0Y4tFoJkwPDEMBC38/8pE4 ZMKZB4DoKBrci9W/UJTL30APngqLSQstVgS8vQIWmB8BdbrzxM2kRMUylYr9Ie5UhbH1JTq/yUu1 SjzLunXSd4+AqtX82STxPAEK2gV9oBOZln0lYI+DcYqJqz/sSXqvayP/x/oWTLJiOHibf5W5tSBM XF0GzOf1VupyUJDp9rOAnVDEtuRdx26pOYMewD98ffr5MOk6pxrFyE5zAAAAAAAA --Apple-Mail=_BF8FE690-94A2-42B1-AA27-C141D28A91B5-- From pkyzivat@alum.mit.edu Wed Nov 14 13:08:26 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 5C21D21F846E for ; Wed, 14 Nov 2012 13:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, 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 1DjK2bHI99Sz for ; Wed, 14 Nov 2012 13:08:25 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF8721F865D for ; Wed, 14 Nov 2012 13:08:24 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id PNqV1k00A0xGWP853Z8QRz; Wed, 14 Nov 2012 21:08:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id PZ8Q1k0023ZTu2S3YZ8Qkt; Wed, 14 Nov 2012 21:08:24 +0000 Message-ID: <50A40847.9010203@alum.mit.edu> Date: Wed, 14 Nov 2012 16:08:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Peter Saint-Andre Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 21:08:26 -0000 Matt, On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: > > On Nov 14, 2012, at 1:07 PM, Mary Barnes > wrote: >>> If we were building a mechanism solely for this pre-release purpose I >>> would be opposed. I see this as installing a mechanism that will work for >>> version 1.0 and future standardized extensions/revisions of it. And then it >>> is convenient that the same mechanism can be used for this pre-standard >>> testing as well. >>> >> [MB] I agree that you need a version number. 1.0 for the first version of >> the RFC and then 2.0 if you do a bis. If someone wants to put the .10 in >> there and work with another vendor to see if their .10 software works with >> the other guy's, I don't see that this requires anything to be put into the >> documents being produced by this WG. Nor, do I think it requires any more >> discussion. We don't develops specs to ensure that prototypes (and various >> draft versions) are interoperable, we do prototypes to ensure the final >> RFCs enable interoperability. Certainly, the former would be a good thing >> as that means the document is headed in the right direction. [/MB] > > > Anecdotal evidence from my work in the XMPP Standards Foundation (XSF): > > The XSF started with namespaces (e.g. "http://jabber.org/protocol/muc") that did not change once a document was published. This worked in a perfect world, where these implementers are in perfect lockstep with each other, always updating to the current state of the I-D within moments (maybe days) of its publication, up to the point it becomes an RFC. > > But we do not live in a perfect world, and people develop at different rates, and sometimes step away from something for a while and might miss a couple of I-D versions. I dare say that some here might even deploy software based on an intermediate version, for various reasons we probably don't agree with ideologically. > > So, the XSF moved to using one namespace for the I-D like phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase (e.g. "urn:xmpp:time"). This helped differentiate between "pre-RFC" versions from "at-RFC" versions, but it was painfully annoying to implementers because they had to go through changes and deployment of those changes simply for a change of a constant. > > 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. IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, ... and formally adopted ones (initial RFC and RFC'ed revisions) correspond to whichever ones happen to have ended up in drafts that become RFCs. So maybe in above i,j,k might have been standardized versions while the ones in between have no normative status. (E.g. draft-foo-core-99 has version i, as does the RFC it becomes. Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 and the RFC it becomes have version j, etc.) Is that right? I would be ok with that approach. Thanks, Paul From stpeter@stpeter.im Wed Nov 14 13:12:51 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 3E52221F8521 for ; Wed, 14 Nov 2012 13:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 rbvjqEqQPssC for ; Wed, 14 Nov 2012 13:12:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7252121F84FC for ; Wed, 14 Nov 2012 13:12:50 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D752C40062; Wed, 14 Nov 2012 14:17:00 -0700 (MST) Message-ID: <50A40955.8030800@stpeter.im> Date: Wed, 14 Nov 2012 14:12:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> In-Reply-To: <50A40847.9010203@alum.mit.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 21:12:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/12 2:08 PM, Paul Kyzivat wrote: > Matt, > > On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >> >> On Nov 14, 2012, at 1:07 PM, Mary Barnes >> wrote: >>>> If we were building a mechanism solely for this pre-release >>>> purpose I would be opposed. I see this as installing a >>>> mechanism that will work for version 1.0 and future >>>> standardized extensions/revisions of it. And then it is >>>> convenient that the same mechanism can be used for this >>>> pre-standard testing as well. >>>> >>> [MB] I agree that you need a version number. 1.0 for the first >>> version of the RFC and then 2.0 if you do a bis. If someone >>> wants to put the .10 in there and work with another vendor to >>> see if their .10 software works with the other guy's, I don't >>> see that this requires anything to be put into the documents >>> being produced by this WG. Nor, do I think it requires any >>> more discussion. We don't develops specs to ensure that >>> prototypes (and various draft versions) are interoperable, we >>> do prototypes to ensure the final RFCs enable interoperability. >>> Certainly, the former would be a good thing as that means the >>> document is headed in the right direction. [/MB] >> >> >> Anecdotal evidence from my work in the XMPP Standards Foundation >> (XSF): >> >> The XSF started with namespaces (e.g. >> "http://jabber.org/protocol/muc") that did not change once a >> document was published. This worked in a perfect world, where >> these implementers are in perfect lockstep with each other, >> always updating to the current state of the I-D within moments >> (maybe days) of its publication, up to the point it becomes an >> RFC. >> >> But we do not live in a perfect world, and people develop at >> different rates, and sometimes step away from something for a >> while and might miss a couple of I-D versions. I dare say that >> some here might even deploy software based on an intermediate >> version, for various reasons we probably don't agree with >> ideologically. >> >> So, the XSF moved to using one namespace for the I-D like phase >> (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase >> (e.g. "urn:xmpp:time"). This helped differentiate between >> "pre-RFC" versions from "at-RFC" versions, but it was painfully >> annoying to implementers because they had to go through changes >> and deployment of those changes simply for a change of a >> constant. >> >> 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. > > IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, > ... We've never gone beyond 3 or 4. We only rev the version if the protocol changes in backward-incompatible ways. We don't change it with every new version of the document. This is protocol versioning, not spec versioning. > and formally adopted ones (initial RFC and RFC'ed revisions) > correspond to whichever ones happen to have ended up in drafts that > become RFCs. So maybe in above i,j,k might have been standardized > versions while the ones in between have no normative status. (E.g. > draft-foo-core-99 has version i, as does the RFC it becomes. > Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 > and the RFC it becomes have version j, etc.) > > Is that right? Basically, yes. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkCVUACgkQNL8k5A2w/vxh0wCePNWuC2P+OzMxaU9fULD9M6te gfMAnijzCSOmh4mtgfC3wFauL34Inbdr =Eb3O -----END PGP SIGNATURE----- From mamille2@cisco.com Wed Nov 14 13:22: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 792D021F8983 for ; Wed, 14 Nov 2012 13:22:23 -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 p7bdFGpcKnvb for ; Wed, 14 Nov 2012 13:22:22 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8E21F8908 for ; Wed, 14 Nov 2012 13:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7112; q=dns/txt; s=iport; t=1352928142; x=1354137742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6HSnCOx9iiH3T72T5TuzgjpeplQbKOrmNFRWg1cYh/A=; b=mpVYquR+tfS13JbPLI02jpnVuTQneg9st2LyGcjgpUOyFy7aAxEnqduO Acc5ModvAUqWemDn/of317AHGN+fbzZ9HzrcJkVWJfZ1aMJnm4rRGx8GC axpQ6Zswmrz3UOw8uPHjYE6tzNkboYDlwAamU6McGLBzmavcff3lXVEGx Y=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAkKpFCtJXHA/2dsb2JhbABEDsM0gQiCHgEBAQMBEgFmBQsCAQgOCgokAh8RJQIEDgUIBhSHVwMJBpstljANiVSLRGmFS2EDjnuBIYQLgnGKFoMmgWuCMj2CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142458868" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 14 Nov 2012 21:22:21 +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 qAELML2q016777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 21:22:21 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 15:22:21 -0600 From: "Matt Miller (mamille2)" To: Paul Kyzivat Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7QADLHTgABj1KoAANJHWgAArWiigAqADU4AAIqaqgACedPwAADgv8YAAAUhGAAADBasAACaJ6YAABqZ1AAABIa0AAAEBDIAAAHy5AA== Date: Wed, 14 Nov 2012 21:22:21 +0000 Message-ID: References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> In-Reply-To: <50A40847.9010203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--43.597300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_67F4B93F-4660-43BC-9E72-C7231073508A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 14 Nov 2012 21:22:24 -0000 --Apple-Mail=_67F4B93F-4660-43BC-9E72-C7231073508A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 14, 2012, at 2:08 PM, Paul Kyzivat wrote: > Matt, >=20 > On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >>=20 >> On Nov 14, 2012, at 1:07 PM, Mary Barnes >> wrote: >>>> If we were building a mechanism solely for this pre-release purpose = I >>>> would be opposed. I see this as installing a mechanism that will = work for >>>> version 1.0 and future standardized extensions/revisions of it. And = then it >>>> is convenient that the same mechanism can be used for this = pre-standard >>>> testing as well. >>>>=20 >>> [MB] I agree that you need a version number. 1.0 for the first = version of >>> the RFC and then 2.0 if you do a bis. If someone wants to put the = .10 in >>> there and work with another vendor to see if their .10 software = works with >>> the other guy's, I don't see that this requires anything to be put = into the >>> documents being produced by this WG. Nor, do I think it requires any = more >>> discussion. We don't develops specs to ensure that prototypes (and = various >>> draft versions) are interoperable, we do prototypes to ensure the = final >>> RFCs enable interoperability. Certainly, the former would be a good = thing >>> as that means the document is headed in the right direction. [/MB] >>=20 >>=20 >> Anecdotal evidence from my work in the XMPP Standards Foundation = (XSF): >>=20 >> The XSF started with namespaces (e.g. = "http://jabber.org/protocol/muc") that did not change once a document = was published. This worked in a perfect world, where these implementers = are in perfect lockstep with each other, always updating to the current = state of the I-D within moments (maybe days) of its publication, up to = the point it becomes an RFC. >>=20 >> But we do not live in a perfect world, and people develop at = different rates, and sometimes step away from something for a while and = might miss a couple of I-D versions. I dare say that some here might = even deploy software based on an intermediate version, for various = reasons we probably don't agree with ideologically. >>=20 >> So, the XSF moved to using one namespace for the I-D like phase (e.g. = "urn:xmpp:time:tmp") and a different for the RFC phase (e.g. = "urn:xmpp:time"). This helped differentiate between "pre-RFC" versions = from "at-RFC" versions, but it was painfully annoying to implementers = because they had to go through changes and deployment of those changes = simply for a change of a constant. >>=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 > IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, = ... >=20 > and formally adopted ones (initial RFC and RFC'ed revisions) = correspond to whichever ones happen to have ended up in drafts that = become RFCs. So maybe in above i,j,k might have been standardized = versions while the ones in between have no normative status. (E.g. = draft-foo-core-99 has version i, as does the RFC it becomes. = Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 and the = RFC it becomes have version j, etc.) >=20 > Is that right? >=20 > I would be ok with that approach. >=20 That is correct. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_67F4B93F-4660-43BC-9E72-C7231073508A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTExNDIxMjIy MVowIwYJKoZIhvcNAQkEMRYEFGCMVNsyNjDREdKDY7r/vuYfdTMhMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBpq7onzks/1a9gFhHIwiWQWyQXB5lVCa0x2273EtDqAiFI4j79snF6hZeW Tr4iIy8RRIDQd6E6+GmjLDfhUjpkYsqcEaqVpwEH8X2ucf+Ci2sDU72O8ZUujGR1daxHxQ0CM0Yo wRHwHA4bUoKW5lcTPQBng9+TTxdP9XMNWYDE+gRuf55no8jdXH4ZHRfkKLfjT5bDIE7KhsixlLHi 5V49cZcyJQpVP2u4lHogzqHsNgJ/n95t927TIQn+qnjMHsNaS2h8oXWqLK4rQpTw2YA0WdX6jexC zx7XLdGn86zbmAz2zwEFg86YP8ZZCH1vZBx760rnp9QCcrP99ERP+GF6AAAAAAAA --Apple-Mail=_67F4B93F-4660-43BC-9E72-C7231073508A-- From partha@parthasarathi.co.in Thu Nov 15 08:15:21 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 2324021F8475 for ; Thu, 15 Nov 2012 08:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.218, 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 7Yva1o4J35x7 for ; Thu, 15 Nov 2012 08:15:17 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id D62C121F8473 for ; Thu, 15 Nov 2012 08:15:16 -0800 (PST) Received: from userPC (unknown [122.179.86.37]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 529871908090; Thu, 15 Nov 2012 16:15:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1352996116; bh=ksQIhXxjFL5ZMAga+6KQdEG1M4QvA7x/8H3wsj1d02s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dOaB5MAsTraRX1A5YQqhRW04UqiQz7SkHIUnMPIGn4xzx+NUVMftkdrhWGwwEZg+r hIKfzyt9eIbsgRM1mu3e4LXd9hTrDk2pIPXObiRjptmufoOevEtW2MOgEnwfRQ1XVq 4mRVblRSkqsFBnXLylFqO2rcGUUsjSJkYjRC43Lw= From: "Parthasarathi R" To: "'Peter Saint-Andre'" , "'Paul Kyzivat'" , References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> In-Reply-To: <50A40955.8030800@stpeter.im> Date: Thu, 15 Nov 2012 21:45:03 +0530 Message-ID: <004e01cdc34c$636c38a0$2a44a9e0$@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: Ac3CrM8ylNgdoFIoSMeoD4NcykGT4gAnJXXA Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0204.50A51514.009E, 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 indication 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, 15 Nov 2012 16:15:21 -0000 Thanks to Peter & Matt for sharing XSF XML namespace versioning experience. Hi all, As per the below discussion, the namespace has to be updated for each RFC (standardized) version and not for each revision of the draft. SIPREC metadata namespace has to be updated as urn:ietf:params:xml:ns:recording:1 in the next revision of the draft in case "1" is assumed as a starting number. Please let us know in case anybody has difference of opinion in this proposal. Including Hadriel in this mail thread as the original requirement of draft specific XML version is started by him. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/12 2:08 PM, Paul Kyzivat wrote: > Matt, > > On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >> >> On Nov 14, 2012, at 1:07 PM, Mary Barnes >> wrote: >>>> If we were building a mechanism solely for this pre-release >>>> purpose I would be opposed. I see this as installing a >>>> mechanism that will work for version 1.0 and future >>>> standardized extensions/revisions of it. And then it is >>>> convenient that the same mechanism can be used for this >>>> pre-standard testing as well. >>>> >>> [MB] I agree that you need a version number. 1.0 for the first >>> version of the RFC and then 2.0 if you do a bis. If someone >>> wants to put the .10 in there and work with another vendor to >>> see if their .10 software works with the other guy's, I don't >>> see that this requires anything to be put into the documents >>> being produced by this WG. Nor, do I think it requires any >>> more discussion. We don't develops specs to ensure that >>> prototypes (and various draft versions) are interoperable, we >>> do prototypes to ensure the final RFCs enable interoperability. >>> Certainly, the former would be a good thing as that means the >>> document is headed in the right direction. [/MB] >> >> >> Anecdotal evidence from my work in the XMPP Standards Foundation >> (XSF): >> >> The XSF started with namespaces (e.g. >> "http://jabber.org/protocol/muc") that did not change once a >> document was published. This worked in a perfect world, where >> these implementers are in perfect lockstep with each other, >> always updating to the current state of the I-D within moments >> (maybe days) of its publication, up to the point it becomes an >> RFC. >> >> But we do not live in a perfect world, and people develop at >> different rates, and sometimes step away from something for a >> while and might miss a couple of I-D versions. I dare say that >> some here might even deploy software based on an intermediate >> version, for various reasons we probably don't agree with >> ideologically. >> >> So, the XSF moved to using one namespace for the I-D like phase >> (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase >> (e.g. "urn:xmpp:time"). This helped differentiate between >> "pre-RFC" versions from "at-RFC" versions, but it was painfully >> annoying to implementers because they had to go through changes >> and deployment of those changes simply for a change of a >> constant. >> >> 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. > > IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, > ... We've never gone beyond 3 or 4. We only rev the version if the protocol changes in backward-incompatible ways. We don't change it with every new version of the document. This is protocol versioning, not spec versioning. > and formally adopted ones (initial RFC and RFC'ed revisions) > correspond to whichever ones happen to have ended up in drafts that > become RFCs. So maybe in above i,j,k might have been standardized > versions while the ones in between have no normative status. (E.g. > draft-foo-core-99 has version i, as does the RFC it becomes. > Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 > and the RFC it becomes have version j, etc.) > > Is that right? Basically, yes. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkCVUACgkQNL8k5A2w/vxh0wCePNWuC2P+OzMxaU9fULD9M6te gfMAnijzCSOmh4mtgfC3wFauL34Inbdr =Eb3O -----END PGP SIGNATURE----- _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Thu Nov 15 09:13:42 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 05CBD21F852C for ; Thu, 15 Nov 2012 09:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 7X7IMifQ3KDc for ; Thu, 15 Nov 2012 09:13:41 -0800 (PST) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCD21F8509 for ; Thu, 15 Nov 2012 09:13:40 -0800 (PST) Received: from userPC (unknown [122.178.223.131]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id C8CED14D808A; Thu, 15 Nov 2012 17:13:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1352999619; bh=BtAn6Tgqr1ggrJ/p1Wnn+ltqRy1lwkeS6eiVI2ZaNHg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=I49izwpjzTNuZKBx4ujx8Mxekg1E/tQEoc//gf7dnXVU8z1nIvwk6GLmUWwaBoiI6 hojDFOxP4nX6eBjAsGOIsXpDQtsy7aqhJKZAGbddW9KNRQCQ0op6xlpI8PbmaYawAH dLHbeEdE3yuDaVwHrKyab9uaJx04g/62LWgW9gUk= From: "Parthasarathi R" To: "'Parthasarathi R'" , "'Peter Saint-Andre'" , "'Paul Kyzivat'" , References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> In-Reply-To: Date: Thu, 15 Nov 2012 22:43:25 +0530 Message-ID: <005b01cdc354$8b8b16f0$a2a144d0$@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: Ac3CrM8ylNgdoFIoSMeoD4NcykGT4gAnJXXAAALD/4A= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0206.50A522C3.0056, 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 indication 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, 15 Nov 2012 17:13:42 -0000 Including the correct Hadriel e-mail id. -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: [siprec] Metadata version indication Thanks to Peter & Matt for sharing XSF XML namespace versioning experience. Hi all, As per the below discussion, the namespace has to be updated for each RFC (standardized) version and not for each revision of the draft. SIPREC metadata namespace has to be updated as urn:ietf:params:xml:ns:recording:1 in the next revision of the draft in case "1" is assumed as a starting number. Please let us know in case anybody has difference of opinion in this proposal. Including Hadriel in this mail thread as the original requirement of draft specific XML version is started by him. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/12 2:08 PM, Paul Kyzivat wrote: > Matt, > > On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >> >> On Nov 14, 2012, at 1:07 PM, Mary Barnes >> wrote: >>>> If we were building a mechanism solely for this pre-release >>>> purpose I would be opposed. I see this as installing a >>>> mechanism that will work for version 1.0 and future >>>> standardized extensions/revisions of it. And then it is >>>> convenient that the same mechanism can be used for this >>>> pre-standard testing as well. >>>> >>> [MB] I agree that you need a version number. 1.0 for the first >>> version of the RFC and then 2.0 if you do a bis. If someone >>> wants to put the .10 in there and work with another vendor to >>> see if their .10 software works with the other guy's, I don't >>> see that this requires anything to be put into the documents >>> being produced by this WG. Nor, do I think it requires any >>> more discussion. We don't develops specs to ensure that >>> prototypes (and various draft versions) are interoperable, we >>> do prototypes to ensure the final RFCs enable interoperability. >>> Certainly, the former would be a good thing as that means the >>> document is headed in the right direction. [/MB] >> >> >> Anecdotal evidence from my work in the XMPP Standards Foundation >> (XSF): >> >> The XSF started with namespaces (e.g. >> "http://jabber.org/protocol/muc") that did not change once a >> document was published. This worked in a perfect world, where >> these implementers are in perfect lockstep with each other, >> always updating to the current state of the I-D within moments >> (maybe days) of its publication, up to the point it becomes an >> RFC. >> >> But we do not live in a perfect world, and people develop at >> different rates, and sometimes step away from something for a >> while and might miss a couple of I-D versions. I dare say that >> some here might even deploy software based on an intermediate >> version, for various reasons we probably don't agree with >> ideologically. >> >> So, the XSF moved to using one namespace for the I-D like phase >> (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase >> (e.g. "urn:xmpp:time"). This helped differentiate between >> "pre-RFC" versions from "at-RFC" versions, but it was painfully >> annoying to implementers because they had to go through changes >> and deployment of those changes simply for a change of a >> constant. >> >> 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. > > IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, > ... We've never gone beyond 3 or 4. We only rev the version if the protocol changes in backward-incompatible ways. We don't change it with every new version of the document. This is protocol versioning, not spec versioning. > and formally adopted ones (initial RFC and RFC'ed revisions) > correspond to whichever ones happen to have ended up in drafts that > become RFCs. So maybe in above i,j,k might have been standardized > versions while the ones in between have no normative status. (E.g. > draft-foo-core-99 has version i, as does the RFC it becomes. > Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 > and the RFC it becomes have version j, etc.) > > Is that right? Basically, yes. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkCVUACgkQNL8k5A2w/vxh0wCePNWuC2P+OzMxaU9fULD9M6te gfMAnijzCSOmh4mtgfC3wFauL34Inbdr =Eb3O -----END PGP SIGNATURE----- _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From br@brianrosen.net Thu Nov 15 12:48:31 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 AE1E021F89F5 for ; Thu, 15 Nov 2012 12:48:31 -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=[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 dlSAu9wI8BwD for ; Thu, 15 Nov 2012 12:48:29 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 22ADE21F89F3 for ; Thu, 15 Nov 2012 12:48:28 -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=tsNDbYEog2T+TToubwZBkS/2qe88l/4DQvySwcd0e0c=; b=rocHREDwbG8PSGvIcFQh98BzJHwEO4uCnl4ZexzPXkggVLLRlQFuTk5PSrvxGY987KIijg88cTZ2jwNGTUcSwlhgpjX3AgMnQHhTtGgA7l4rcU4yKw485kYZQLxbePBu; Received: from neustargw.va.neustar.com ([209.173.53.233]:50462 helo=[192.168.133.78]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TZ6MN-00086t-2m; Thu, 15 Nov 2012 15:48:27 -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: <005b01cdc354$8b8b16f0$a2a144d0$@co.in> Date: Thu, 15 Nov 2012 15:48:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@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 indication 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, 15 Nov 2012 20:48:31 -0000 I don't think that is right. I could be misunderstanding something but there is no specific proposal = to change what I originally outlined. There was a discussion of = changing the scheme to just increment the version when the protocol = changed, ignoring whether that was a draft or RFC. We could do that, = but I think the original proposal works well enough. There is a clear desire to have some way to indicate versions of drafts, = as long as the RFC has a simple (say "version 1.0") version everyone = understands. There doesn't seem to be any downside to changing the = version on drafts. The only discussion on that point was whether it = changes on every draft, or every draft that changes the schema. As long as the draft contains an RFC editor note to set the version to a = fixed, agreed value when the RFC is published, we can do anything we = want to with the draft versions without causing any harm. On Nov 15, 2012, at 12:13 PM, Parthasarathi R = wrote: > Including the correct Hadriel e-mail id. >=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 > Sent: Thursday, November 15, 2012 9:45 PM > To: 'Peter Saint-Andre'; 'Paul Kyzivat'; = 'hadriel.kaplan@acmepacket.com' > Cc: 'siprec@ietf.org' > Subject: RE: [siprec] Metadata version indication >=20 > Thanks to Peter & Matt for sharing XSF XML namespace versioning = experience.=20 >=20 > Hi all, >=20 > As per the below discussion, the namespace has to be updated for each = RFC > (standardized) version and not for each revision of the draft. SIPREC > metadata namespace has to be updated as = urn:ietf:params:xml:ns:recording:1 > in the next revision of the draft in case "1" is assumed as a starting > number. Please let us know in case anybody has difference of opinion = in this > proposal. >=20 > Including Hadriel in this mail thread as the original requirement of = draft > specific XML version is started by him. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of > Peter Saint-Andre > Sent: Thursday, November 15, 2012 2:43 AM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/14/12 2:08 PM, Paul Kyzivat wrote: >> Matt, >>=20 >> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >>>=20 >>> On Nov 14, 2012, at 1:07 PM, Mary Barnes >>> wrote: >>>>> If we were building a mechanism solely for this pre-release >>>>> purpose I would be opposed. I see this as installing a >>>>> mechanism that will work for version 1.0 and future >>>>> standardized extensions/revisions of it. And then it is >>>>> convenient that the same mechanism can be used for this >>>>> pre-standard testing as well. >>>>>=20 >>>> [MB] I agree that you need a version number. 1.0 for the first=20 >>>> version of the RFC and then 2.0 if you do a bis. If someone >>>> wants to put the .10 in there and work with another vendor to >>>> see if their .10 software works with the other guy's, I don't >>>> see that this requires anything to be put into the documents >>>> being produced by this WG. Nor, do I think it requires any=20 >>>> more discussion. We don't develops specs to ensure that >>>> prototypes (and various draft versions) are interoperable, we >>>> do prototypes to ensure the final RFCs enable interoperability. >>>> Certainly, the former would be a good thing as that means the >>>> document is headed in the right direction. [/MB] >>>=20 >>>=20 >>> Anecdotal evidence from my work in the XMPP Standards Foundation >>> (XSF): >>>=20 >>> The XSF started with namespaces (e.g.=20 >>> "http://jabber.org/protocol/muc") that did not change once a >>> document was published. This worked in a perfect world, where >>> these implementers are in perfect lockstep with each other, >>> always updating to the current state of the I-D within moments >>> (maybe days) of its publication, up to the point it becomes an >>> RFC. >>>=20 >>> But we do not live in a perfect world, and people develop at >>> different rates, and sometimes step away from something for a >>> while and might miss a couple of I-D versions. I dare say that >>> some here might even deploy software based on an intermediate >>> version, for various reasons we probably don't agree with >>> ideologically. >>>=20 >>> So, the XSF moved to using one namespace for the I-D like phase >>> (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase >>> (e.g. "urn:xmpp:time"). This helped differentiate between >>> "pre-RFC" versions from "at-RFC" versions, but it was painfully >>> annoying to implementers because they had to go through changes >>> and deployment of those changes simply for a change of a >>> constant. >>>=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 >> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, >> ... >=20 > We've never gone beyond 3 or 4. >=20 > We only rev the version if the protocol changes in > backward-incompatible ways. We don't change it with every new version > of the document. This is protocol versioning, not spec versioning. >=20 >> and formally adopted ones (initial RFC and RFC'ed revisions) >> correspond to whichever ones happen to have ended up in drafts that >> become RFCs. So maybe in above i,j,k might have been standardized >> versions while the ones in between have no normative status. (E.g. >> draft-foo-core-99 has version i, as does the RFC it becomes. >> Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 >> and the RFC it becomes have version j, etc.) >>=20 >> Is that right? >=20 > Basically, yes. >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlCkCVUACgkQNL8k5A2w/vxh0wCePNWuC2P+OzMxaU9fULD9M6te > gfMAnijzCSOmh4mtgfC3wFauL34Inbdr > =3DEb3O > -----END PGP SIGNATURE----- > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From stpeter@stpeter.im Thu Nov 15 13:06: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 8600621F8528 for ; Thu, 15 Nov 2012 13:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 cLu1zvCq6PRj for ; Thu, 15 Nov 2012 13:06:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 521D321F84C9 for ; Thu, 15 Nov 2012 13:06:47 -0800 (PST) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5B0C40062; Thu, 15 Nov 2012 14:11:00 -0700 (MST) Message-ID: <50A5596E.6090708@stpeter.im> Date: Thu, 15 Nov 2012 14:06:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian Rosen References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication 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, 15 Nov 2012 21:06:58 -0000 A simple question (pointer to previous list message is fine): what problem are we trying to solve here? On 11/15/12 1:48 PM, Brian Rosen wrote: > I don't think that is right. > > I could be misunderstanding something but there is no specific > proposal to change what I originally outlined. There was a > discussion of changing the scheme to just increment the version when > the protocol changed, ignoring whether that was a draft or RFC. We > could do that, but I think the original proposal works well enough. > > There is a clear desire to have some way to indicate versions of > drafts, as long as the RFC has a simple (say "version 1.0") version > everyone understands. There doesn't seem to be any downside to > changing the version on drafts. The only discussion on that point > was whether it changes on every draft, or every draft that changes > the schema. > > As long as the draft contains an RFC editor note to set the version > to a fixed, agreed value when the RFC is published, we can do > anything we want to with the draft versions without causing any > harm. > > > > > On Nov 15, 2012, at 12:13 PM, Parthasarathi R > wrote: > >> Including the correct Hadriel e-mail id. >> >> -----Original Message----- From: Parthasarathi R >> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, >> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; >> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: >> [siprec] Metadata version indication >> >> Thanks to Peter & Matt for sharing XSF XML namespace versioning >> experience. >> >> Hi all, >> >> As per the below discussion, the namespace has to be updated for >> each RFC (standardized) version and not for each revision of the >> draft. SIPREC metadata namespace has to be updated as >> urn:ietf:params:xml:ns:recording:1 in the next revision of the >> draft in case "1" is assumed as a starting number. Please let us >> know in case anybody has difference of opinion in this proposal. >> >> Including Hadriel in this mail thread as the original requirement >> of draft specific XML version is started by him. >> >> Thanks Partha >> >> -----Original Message----- From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: >> siprec@ietf.org Subject: Re: [siprec] Metadata version indication >> > On 11/14/12 2:08 PM, Paul Kyzivat wrote: >>>> Matt, >>>> >>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >>>>> >>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes >>>>> wrote: >>>>>>> If we were building a mechanism solely for this >>>>>>> pre-release purpose I would be opposed. I see this as >>>>>>> installing a mechanism that will work for version 1.0 and >>>>>>> future standardized extensions/revisions of it. And then >>>>>>> it is convenient that the same mechanism can be used for >>>>>>> this pre-standard testing as well. >>>>>>> >>>>>> [MB] I agree that you need a version number. 1.0 for the >>>>>> first version of the RFC and then 2.0 if you do a bis. If >>>>>> someone wants to put the .10 in there and work with another >>>>>> vendor to see if their .10 software works with the other >>>>>> guy's, I don't see that this requires anything to be put >>>>>> into the documents being produced by this WG. Nor, do I >>>>>> think it requires any more discussion. We don't develops >>>>>> specs to ensure that prototypes (and various draft >>>>>> versions) are interoperable, we do prototypes to ensure the >>>>>> final RFCs enable interoperability. Certainly, the former >>>>>> would be a good thing as that means the document is headed >>>>>> in the right direction. [/MB] >>>>> >>>>> >>>>> Anecdotal evidence from my work in the XMPP Standards >>>>> Foundation (XSF): >>>>> >>>>> The XSF started with namespaces (e.g. >>>>> "http://jabber.org/protocol/muc") that did not change once a >>>>> document was published. This worked in a perfect world, >>>>> where these implementers are in perfect lockstep with each >>>>> other, always updating to the current state of the I-D within >>>>> moments (maybe days) of its publication, up to the point it >>>>> becomes an RFC. >>>>> >>>>> But we do not live in a perfect world, and people develop at >>>>> different rates, and sometimes step away from something for >>>>> a while and might miss a couple of I-D versions. I dare say >>>>> that some here might even deploy software based on an >>>>> intermediate version, for various reasons we probably don't >>>>> agree with ideologically. >>>>> >>>>> So, the XSF moved to using one namespace for the I-D like >>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC >>>>> phase (e.g. "urn:xmpp:time"). This helped differentiate >>>>> between "pre-RFC" versions from "at-RFC" versions, but it was >>>>> painfully annoying to implementers because they had to go >>>>> through changes and deployment of those changes simply for a >>>>> change of a constant. >>>>> >>>>> 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. >>>> >>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, >>>> ... k, ... > > We've never gone beyond 3 or 4. > > We only rev the version if the protocol changes in > backward-incompatible ways. We don't change it with every new > version of the document. This is protocol versioning, not spec > versioning. > >>>> and formally adopted ones (initial RFC and RFC'ed revisions) >>>> correspond to whichever ones happen to have ended up in drafts >>>> that become RFCs. So maybe in above i,j,k might have been >>>> standardized versions while the ones in between have no >>>> normative status. (E.g. draft-foo-core-99 has version i, as >>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, >>>> while draft-foo-corebis-19 and the RFC it becomes have version >>>> j, etc.) >>>> >>>> Is that right? > > Basically, yes. > > Peter > >> _______________________________________________ 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 > -- Peter Saint-Andre https://stpeter.im/ From br@brianrosen.net Thu Nov 15 13:13:31 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 EF20E21F8B15 for ; Thu, 15 Nov 2012 13:13:31 -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=[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 RUT-npdV3wCY for ; Thu, 15 Nov 2012 13:13:31 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A26E421F8B41 for ; Thu, 15 Nov 2012 13:13:30 -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=iYioLVGVsmbakgxC5XhkkT5vDdBdlYTDpbmiajKrs9A=; b=oLjaJ5JCCb0+LPQv+fl0ltVUZtCW2yh7YDoVmiYQs3MRoiXdC5M0NFiOUsR/J6su3XKvKLm7OA/Mnct4u6heeyMIFhYpeN/FcWZ9L3LvalrCGjy05GsIBUmI/nc29swC; Received: from neustargw.va.neustar.com ([209.173.53.233]:58383 helo=[192.168.133.78]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TZ6kb-0005YI-51; Thu, 15 Nov 2012 16:13:29 -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: <50A5596E.6090708@stpeter.im> Date: Thu, 15 Nov 2012 16:13:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.net> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> <50A5596E.6090708@stpeter.im> To: Peter Saint-Andre 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 indication 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, 15 Nov 2012 21:13:32 -0000 There was a request to have a version number in the schema namespace = that changed when versions changed in drafts as well as RFCs, because we = are already doing interoperability testing, and we've been stung by = different implementations of the drafts not interworking. That's the problem. Brian On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre = wrote: > A simple question (pointer to previous list message is fine): what > problem are we trying to solve here? >=20 > On 11/15/12 1:48 PM, Brian Rosen wrote: >> I don't think that is right. >>=20 >> I could be misunderstanding something but there is no specific >> proposal to change what I originally outlined. There was a >> discussion of changing the scheme to just increment the version when >> the protocol changed, ignoring whether that was a draft or RFC. We >> could do that, but I think the original proposal works well enough. >>=20 >> There is a clear desire to have some way to indicate versions of >> drafts, as long as the RFC has a simple (say "version 1.0") version >> everyone understands. There doesn't seem to be any downside to >> changing the version on drafts. The only discussion on that point >> was whether it changes on every draft, or every draft that changes >> the schema. >>=20 >> As long as the draft contains an RFC editor note to set the version >> to a fixed, agreed value when the RFC is published, we can do >> anything we want to with the draft versions without causing any >> harm. >>=20 >>=20 >>=20 >>=20 >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R >> wrote: >>=20 >>> Including the correct Hadriel e-mail id. >>>=20 >>> -----Original Message----- From: Parthasarathi R >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: >>> [siprec] Metadata version indication >>>=20 >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning >>> experience. >>>=20 >>> Hi all, >>>=20 >>> As per the below discussion, the namespace has to be updated for >>> each RFC (standardized) version and not for each revision of the >>> draft. SIPREC metadata namespace has to be updated as >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the >>> draft in case "1" is assumed as a starting number. Please let us >>> know in case anybody has difference of opinion in this proposal. >>>=20 >>> Including Hadriel in this mail thread as the original requirement >>> of draft specific XML version is started by him. >>>=20 >>> Thanks Partha >>>=20 >>> -----Original Message----- From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre=20 >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication >>>=20 >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: >>>>> Matt, >>>>>=20 >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >>>>>>=20 >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes=20 >>>>>> wrote: >>>>>>>> If we were building a mechanism solely for this >>>>>>>> pre-release purpose I would be opposed. I see this as >>>>>>>> installing a mechanism that will work for version 1.0 and >>>>>>>> future standardized extensions/revisions of it. And then >>>>>>>> it is convenient that the same mechanism can be used for >>>>>>>> this pre-standard testing as well. >>>>>>>>=20 >>>>>>> [MB] I agree that you need a version number. 1.0 for the >>>>>>> first version of the RFC and then 2.0 if you do a bis. If >>>>>>> someone wants to put the .10 in there and work with another >>>>>>> vendor to see if their .10 software works with the other >>>>>>> guy's, I don't see that this requires anything to be put >>>>>>> into the documents being produced by this WG. Nor, do I >>>>>>> think it requires any more discussion. We don't develops >>>>>>> specs to ensure that prototypes (and various draft >>>>>>> versions) are interoperable, we do prototypes to ensure the >>>>>>> final RFCs enable interoperability. Certainly, the former >>>>>>> would be a good thing as that means the document is headed >>>>>>> in the right direction. [/MB] >>>>>>=20 >>>>>>=20 >>>>>> Anecdotal evidence from my work in the XMPP Standards >>>>>> Foundation (XSF): >>>>>>=20 >>>>>> The XSF started with namespaces (e.g.=20 >>>>>> "http://jabber.org/protocol/muc") that did not change once a=20 >>>>>> document was published. This worked in a perfect world, >>>>>> where these implementers are in perfect lockstep with each >>>>>> other, always updating to the current state of the I-D within >>>>>> moments (maybe days) of its publication, up to the point it >>>>>> becomes an RFC. >>>>>>=20 >>>>>> But we do not live in a perfect world, and people develop at=20 >>>>>> different rates, and sometimes step away from something for >>>>>> a while and might miss a couple of I-D versions. I dare say >>>>>> that some here might even deploy software based on an >>>>>> intermediate version, for various reasons we probably don't >>>>>> agree with ideologically. >>>>>>=20 >>>>>> So, the XSF moved to using one namespace for the I-D like >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC >>>>>> phase (e.g. "urn:xmpp:time"). This helped differentiate >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was >>>>>> painfully annoying to implementers because they had to go >>>>>> through changes and deployment of those changes simply for a >>>>>> change of a constant. >>>>>>=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 >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, >>>>> ... k, ... >>=20 >> We've never gone beyond 3 or 4. >>=20 >> We only rev the version if the protocol changes in=20 >> backward-incompatible ways. We don't change it with every new >> version of the document. This is protocol versioning, not spec >> versioning. >>=20 >>>>> and formally adopted ones (initial RFC and RFC'ed revisions)=20 >>>>> correspond to whichever ones happen to have ended up in drafts >>>>> that become RFCs. So maybe in above i,j,k might have been >>>>> standardized versions while the ones in between have no >>>>> normative status. (E.g. draft-foo-core-99 has version i, as >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, >>>>> while draft-foo-corebis-19 and the RFC it becomes have version >>>>> j, etc.) >>>>>=20 >>>>> Is that right? >>=20 >> Basically, yes. >>=20 >> Peter >>=20 >>> _______________________________________________ siprec mailing >>> list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec >>>=20 >>> _______________________________________________ siprec mailing >>> list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 From mary.ietf.barnes@gmail.com Thu Nov 15 15:39:48 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 C667D21F8A1F for ; Thu, 15 Nov 2012 15:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 AcfkCAmnPcqR for ; Thu, 15 Nov 2012 15:39:47 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60DF921F845B for ; Thu, 15 Nov 2012 15:39:46 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1780733lah.31 for ; Thu, 15 Nov 2012 15:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtnmNEMJoR17e2qwUaktMKGrsngpOrAQj+NzJjCeCqg=; b=XU1aKnqGiubsc4+z//Rcr/8y5EXaSDaAjWq4DNGFhBVTxMg5vjVpZaB8lUDlCb7O75 pPWrMkDHYzKYogMRr3LtLnwmMqErSsFH1GTD67mVPZmEnoMsnX3UoTZyvCmjzZOGNqhx vlOVFb1CAFHmvXmrud6RhfUI114ljh850j0MKesvnD45QUFNq5H6poR5Yo7VdcMkpA61 dV5+HLOwsX4mYa19yp654tkpWbSQJg13oNk4J4HZGn0/+X4XYIkFXXGCt/Vr1Imr29c+ WOSrsnfUb//AHMZ4TdX1OAGmma7y1jHyzxAMk3j2tj83t3Ay6dLVbgS69b1SIzXjvHy2 oIhQ== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr1251290lbo.122.1353022785058; Thu, 15 Nov 2012 15:39:45 -0800 (PST) Received: by 10.114.69.139 with HTTP; Thu, 15 Nov 2012 15:39:44 -0800 (PST) In-Reply-To: <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.net> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> <50A5596E.6090708@stpeter.im> <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.net> Date: Thu, 15 Nov 2012 17:39:44 -0600 Message-ID: From: Mary Barnes To: Brian Rosen Content-Type: multipart/alternative; boundary=f46d0401fe5979f73704ce912a31 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 15 Nov 2012 23:39:48 -0000 --f46d0401fe5979f73704ce912a31 Content-Type: text/plain; charset=ISO-8859-1 But, this version doesn't do anything to improve the interop situation. All that it will tell you is that Vendor A can't interop with Vendor B if they have each implemented different versions which have different metadata. My understanding of what Hadriel said was that this is all he wants to know - i.e., different versions mean you can't interoperate. Unless the expectation is that vendors/implementors support multiple versions, then I don't see how this improves the situation and adds any more value than Vendor A asking Vendor B what version they have implemented. If the issue is that the RFC won't be available in time for people that are implementing, I still suggest that one version of the draft be selected and publish that as "this is what's currently implemented", which was the approach being taken in INSIPID. Mary. On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen wrote: > There was a request to have a version number in the schema namespace that > changed when versions changed in drafts as well as RFCs, because we are > already doing interoperability testing, and we've been stung by different > implementations of the drafts not interworking. > > That's the problem. > > Brian > On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre wrote: > > > A simple question (pointer to previous list message is fine): what > > problem are we trying to solve here? > > > > On 11/15/12 1:48 PM, Brian Rosen wrote: > >> I don't think that is right. > >> > >> I could be misunderstanding something but there is no specific > >> proposal to change what I originally outlined. There was a > >> discussion of changing the scheme to just increment the version when > >> the protocol changed, ignoring whether that was a draft or RFC. We > >> could do that, but I think the original proposal works well enough. > >> > >> There is a clear desire to have some way to indicate versions of > >> drafts, as long as the RFC has a simple (say "version 1.0") version > >> everyone understands. There doesn't seem to be any downside to > >> changing the version on drafts. The only discussion on that point > >> was whether it changes on every draft, or every draft that changes > >> the schema. > >> > >> As long as the draft contains an RFC editor note to set the version > >> to a fixed, agreed value when the RFC is published, we can do > >> anything we want to with the draft versions without causing any > >> harm. > >> > >> > >> > >> > >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R > >> wrote: > >> > >>> Including the correct Hadriel e-mail id. > >>> > >>> -----Original Message----- From: Parthasarathi R > >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, > >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; > >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: > >>> [siprec] Metadata version indication > >>> > >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning > >>> experience. > >>> > >>> Hi all, > >>> > >>> As per the below discussion, the namespace has to be updated for > >>> each RFC (standardized) version and not for each revision of the > >>> draft. SIPREC metadata namespace has to be updated as > >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the > >>> draft in case "1" is assumed as a starting number. Please let us > >>> know in case anybody has difference of opinion in this proposal. > >>> > >>> Including Hadriel in this mail thread as the original requirement > >>> of draft specific XML version is started by him. > >>> > >>> Thanks Partha > >>> > >>> -----Original Message----- From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre > >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: > >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication > >>> > >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: > >>>>> Matt, > >>>>> > >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: > >>>>>> > >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes > >>>>>> wrote: > >>>>>>>> If we were building a mechanism solely for this > >>>>>>>> pre-release purpose I would be opposed. I see this as > >>>>>>>> installing a mechanism that will work for version 1.0 and > >>>>>>>> future standardized extensions/revisions of it. And then > >>>>>>>> it is convenient that the same mechanism can be used for > >>>>>>>> this pre-standard testing as well. > >>>>>>>> > >>>>>>> [MB] I agree that you need a version number. 1.0 for the > >>>>>>> first version of the RFC and then 2.0 if you do a bis. If > >>>>>>> someone wants to put the .10 in there and work with another > >>>>>>> vendor to see if their .10 software works with the other > >>>>>>> guy's, I don't see that this requires anything to be put > >>>>>>> into the documents being produced by this WG. Nor, do I > >>>>>>> think it requires any more discussion. We don't develops > >>>>>>> specs to ensure that prototypes (and various draft > >>>>>>> versions) are interoperable, we do prototypes to ensure the > >>>>>>> final RFCs enable interoperability. Certainly, the former > >>>>>>> would be a good thing as that means the document is headed > >>>>>>> in the right direction. [/MB] > >>>>>> > >>>>>> > >>>>>> Anecdotal evidence from my work in the XMPP Standards > >>>>>> Foundation (XSF): > >>>>>> > >>>>>> The XSF started with namespaces (e.g. > >>>>>> "http://jabber.org/protocol/muc") that did not change once a > >>>>>> document was published. This worked in a perfect world, > >>>>>> where these implementers are in perfect lockstep with each > >>>>>> other, always updating to the current state of the I-D within > >>>>>> moments (maybe days) of its publication, up to the point it > >>>>>> becomes an RFC. > >>>>>> > >>>>>> But we do not live in a perfect world, and people develop at > >>>>>> different rates, and sometimes step away from something for > >>>>>> a while and might miss a couple of I-D versions. I dare say > >>>>>> that some here might even deploy software based on an > >>>>>> intermediate version, for various reasons we probably don't > >>>>>> agree with ideologically. > >>>>>> > >>>>>> So, the XSF moved to using one namespace for the I-D like > >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC > >>>>>> phase (e.g. "urn:xmpp:time"). This helped differentiate > >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was > >>>>>> painfully annoying to implementers because they had to go > >>>>>> through changes and deployment of those changes simply for a > >>>>>> change of a constant. > >>>>>> > >>>>>> 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. > >>>>> > >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, > >>>>> ... k, ... > >> > >> We've never gone beyond 3 or 4. > >> > >> We only rev the version if the protocol changes in > >> backward-incompatible ways. We don't change it with every new > >> version of the document. This is protocol versioning, not spec > >> versioning. > >> > >>>>> and formally adopted ones (initial RFC and RFC'ed revisions) > >>>>> correspond to whichever ones happen to have ended up in drafts > >>>>> that become RFCs. So maybe in above i,j,k might have been > >>>>> standardized versions while the ones in between have no > >>>>> normative status. (E.g. draft-foo-core-99 has version i, as > >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, > >>>>> while draft-foo-corebis-19 and the RFC it becomes have version > >>>>> j, etc.) > >>>>> > >>>>> Is that right? > >> > >> Basically, yes. > >> > >> Peter > >> > >>> _______________________________________________ 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 > >> > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > --f46d0401fe5979f73704ce912a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But, this version doesn't do anything to improve the interop situation.= =A0All that it will tell you is that Vendor A can't interop with Vendo= r B if they have each implemented different versions which have different m= etadata. =A0 My understanding of what Hadriel said was that this is all he = wants to know - i.e., different versions mean you can't interoperate. = =A0 Unless the expectation is that vendors/implementors support multiple ve= rsions, then I don't see how this improves the situation and adds any m= ore value than Vendor A asking Vendor B what version they have implemented.= =A0

If the issue is that the RFC won't be available in time = for people that are implementing, I still suggest that one version of the d= raft be selected and publish that as "this is what's currently imp= lemented", which was the approach being taken in INSIPID. =A0

Mary.=A0




On Thu, Nov 15, 2012= at 3:13 PM, Brian Rosen <br@brianrosen.net> wrote:
There was a request to have a version number= in the schema namespace that changed when versions changed in drafts as we= ll as RFCs, because we are already doing interoperability testing, and we&#= 39;ve been stung by different implementations of the drafts not interworkin= g.

That's the problem.

Brian
On Nov 15, 2012, at 4= :06 PM, Peter Saint-Andre <stpeter= @stpeter.im> wrote:

> A simple question (pointer to previous list message is fine): what
> problem are we trying to solve here?
>
> On 11/15/12 1:48 PM, Brian Rosen wrote:
>> <as individual> I don't think that is right.
>>
>> I could be misunderstanding something but there is no specific
>> proposal to change what I originally outlined. =A0There was a
>> discussion of changing the scheme to just increment the version wh= en
>> the protocol changed, ignoring whether that was a draft or RFC. = =A0We
>> could do that, but I think the original proposal works well enough= .
>>
>> There is a clear desire to have some way to indicate versions of >> drafts, as long as the RFC has a simple (say "version 1.0&quo= t;) version
>> everyone understands. =A0There doesn't seem to be any downside= to
>> changing the version on drafts. =A0The only discussion on that poi= nt
>> was whether it changes on every draft, or every draft that changes=
>> the schema.
>>
>> As long as the draft contains an RFC editor note to set the versio= n
>> to a fixed, agreed value when the RFC is published, we can do
>> anything we want to with the draft versions without causing any >> harm.
>>
>>
>>
>>
>> On Nov 15, 2012, at 12:13 PM, Parthasarathi R
>> <partha@parthasar= athi.co.in> wrote:
>>
>>> Including the correct Hadriel e-mail id.
>>>
>>> -----Original Message----- From: Parthasarathi R
>>> [mailto:partha@p= arthasarathi.co.in] Sent: Thursday, November 15,
>>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyziva= t';
>>> 'hadriel.= kaplan@acmepacket.com' Cc: '= siprec@ietf.org' Subject: RE:
>>> [siprec] Metadata version indication
>>>
>>> Thanks to Peter & Matt for sharing XSF XML namespace versi= oning
>>> experience.
>>>
>>> Hi all,
>>>
>>> As per the below discussion, the namespace has to be updated f= or
>>> each RFC (standardized) version and not for each revision of t= he
>>> draft. SIPREC metadata namespace has to be updated as
>>> urn:ietf:params:xml:ns:recording:1 in the next revision of the=
>>> draft in case "1" is assumed as a starting number. P= lease let us
>>> know in case anybody has difference of opinion in this proposa= l.
>>>
>>> Including Hadriel in this mail thread as the original requirem= ent
>>> of draft specific XML version is started by him.
>>>
>>> Thanks Partha
>>>
>>> -----Original Message----- From: siprec-bounces@ietf.org
>>> [mailto:siprec-boun= ces@ietf.org] On Behalf Of Peter Saint-Andre
>>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc:=
>>> siprec@ietf.org Subject= : Re: [siprec] Metadata version indication
>>>
>> On 11/14/12 2:08 PM, Paul Kyzivat wrote:
>>>>> Matt,
>>>>>
>>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote:
>>>>>>
>>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes
>>>>>> <= mary.ietf.barnes@gmail.com> wrote:
>>>>>>>> If we were building a mechanism solely for= this
>>>>>>>> pre-release purpose I would be opposed. I = see this as
>>>>>>>> installing a mechanism that will work for = version 1.0 and
>>>>>>>> future standardized extensions/revisions o= f it. And then
>>>>>>>> it is convenient that the same mechanism c= an be used for
>>>>>>>> this pre-standard testing as well.
>>>>>>>>
>>>>>>> [MB] I agree that you need a version number. 1= .0 for the
>>>>>>> first version of the RFC and then 2.0 if you d= o a bis. =A0If
>>>>>>> someone wants to put the .10 in there and work= with another
>>>>>>> vendor to see if their .10 software works with= the other
>>>>>>> guy's, I don't see that this requires = anything to be put
>>>>>>> into the documents being produced by this WG. = Nor, do I
>>>>>>> think it requires any more discussion. =A0We d= on't develops
>>>>>>> specs to ensure that prototypes (and various d= raft
>>>>>>> versions) are interoperable, we do prototypes = to ensure the
>>>>>>> final RFCs enable interoperability. Certainly,= the former
>>>>>>> would be a good thing as that means the docume= nt is headed
>>>>>>> in the right direction. [/MB]
>>>>>>
>>>>>>
>>>>>> Anecdotal evidence from my work in the XMPP Standa= rds
>>>>>> Foundation (XSF):
>>>>>>
>>>>>> The XSF started with namespaces (e.g.
>>>>>> "http://jabber.org/protocol/muc") that did not cha= nge once a
>>>>>> document was published. =A0This worked in a perfec= t world,
>>>>>> where these implementers are in perfect lockstep w= ith each
>>>>>> other, always updating to the current state of the= I-D within
>>>>>> moments (maybe days) of its publication, up to the= point it
>>>>>> becomes an RFC.
>>>>>>
>>>>>> But we do not live in a perfect world, and people = develop at
>>>>>> different rates, and sometimes step away from some= thing for
>>>>>> a while and might miss a couple of I-D versions. = =A0I dare say
>>>>>> that some here might even deploy software based on= an
>>>>>> intermediate version, for various reasons we proba= bly don't
>>>>>> agree with ideologically.
>>>>>>
>>>>>> So, the XSF moved to using one namespace for the I= -D like
>>>>>> phase (e.g. "urn:xmpp:time:tmp") and a d= ifferent for the RFC
>>>>>> phase (e.g. "urn:xmpp:time"). =A0This he= lped differentiate
>>>>>> between "pre-RFC" versions from "at= -RFC" versions, but it was
>>>>>> painfully annoying to implementers because they ha= d to go
>>>>>> through changes and deployment of those changes si= mply for a
>>>>>> change of a constant.
>>>>>>
>>>>>> This led the XSF to use a protocol versioning sche= me
>>>>>> currently in use (e.g. "urn:xmpp:carbons:2&qu= ot;), where the
>>>>>> number starts at 0 and increments with each protoc= ol-breaking
>>>>>> change. =A0It meant that different teams understoo= d to what
>>>>>> level another had implemented to, and adoption of = an I-D
>>>>>> phase document to an RFC phase document meant no c= hurn simply
>>>>>> because the XSF accepted the work.
>>>>>
>>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, = ... j,
>>>>> ... k, ...
>>
>> We've never gone beyond 3 or 4.
>>
>> We only rev the version if the protocol changes in
>> backward-incompatible ways. We don't change it with every new<= br> >> version of the document. This is protocol versioning, not spec
>> versioning.
>>
>>>>> and formally adopted ones (initial RFC and RFC'ed = revisions)
>>>>> correspond to whichever ones happen to have ended up i= n drafts
>>>>> that become RFCs. So maybe in above i,j,k might have b= een
>>>>> standardized versions while the ones in between have n= o
>>>>> normative status. (E.g. draft-foo-core-99 has version = i, as
>>>>> does the RFC it becomes. Draft-foo-corebis-00 has vers= ion i+1,
>>>>> while draft-foo-corebis-19 and the RFC it becomes have= version
>>>>> j, etc.)
>>>>>
>>>>> Is that right?
>>
>> Basically, yes.
>>
>> Peter
>>
>>> _______________________________________________ siprec mailing=
>>> list siprec@ietf.org ht= tps://www.ietf.org/mailman/listinfo/siprec
>>>
>>> _______________________________________________ siprec mailing=
>>> list siprec@ietf.org ht= tps://www.ietf.org/mailman/listinfo/siprec
>>
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>

_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec

--f46d0401fe5979f73704ce912a31-- From DAVE.HIGTON@nice.com Fri Nov 16 02:44: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 1777F21F850D for ; Fri, 16 Nov 2012 02:44:03 -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=[AWL=-0.001, 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 z4e2-x9vQ4v8 for ; Fri, 16 Nov 2012 02:43:59 -0800 (PST) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2902B21F84D7 for ; Fri, 16 Nov 2012 02:43:58 -0800 (PST) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Fri, 16 Nov 2012 10:43:57 +0000 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Nov 2012 10:43:56 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::ec6d:6017:186e:e8f8]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Fri, 16 Nov 2012 10:43:56 +0000 From: "Dave Higton" Content-Transfer-Encoding: 7bit To: Date: Fri, 16 Nov 2012 10:43:54 +0000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac3DioWzOYP7lebvRnWisNPqln95twAXDuZA Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B694055F9C2390@SOUEXC01.eu.nice.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu><92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com><509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in><50A2B668.1040808@alum.mit.edu><50A3CD51.7050504@alum.mit.edu><50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im><005b01cdc354$8b8b16f0$a2a144d0$@co.in><50A5596E.6090708@stpeter.im><083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.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: multipart/alternative; boundary="_000_9B0B6FB9606F4D4AB133C5E9A203B694055F9C2390SOUEXC01eunic_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Nov 2012 10:43:56.0492 (UTC) FILETIME=[475050C0:01CDC3E7] Subject: Re: [siprec] Metadata version indication 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, 16 Nov 2012 10:44:03 -0000 This is a multi-part message in MIME format. --_000_9B0B6FB9606F4D4AB133C5E9A203B694055F9C2390SOUEXC01eunic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it's a lesson from programming life: when you're exchanging = formatted data, always include version information. It gives the possibility of interworking with more than one version. If you are unable or unwilling to interwork with more than one version, = at least it lets you know if you've been given a version that you can't = interwork with, rather than trying and falling over with errors. Dave From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Mary Barnes Sent: 15 November 2012 23:40 To: Brian Rosen Cc: siprec@ietf.org Subject: Re: [siprec] Metadata version indication But, this version doesn't do anything to improve the interop situation. = All that it will tell you is that Vendor A can't interop with Vendor B = if they have each implemented different versions which have different = metadata. My understanding of what Hadriel said was that this is all = he wants to know - i.e., different versions mean you can't interoperate. = Unless the expectation is that vendors/implementors support multiple = versions, then I don't see how this improves the situation and adds any = more value than Vendor A asking Vendor B what version they have = implemented. If the issue is that the RFC won't be available in time for people that = are implementing, I still suggest that one version of the draft be = selected and publish that as "this is what's currently implemented", = which was the approach being taken in INSIPID. Mary. On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen = > wrote: There was a request to have a version number in the schema namespace = that changed when versions changed in drafts as well as RFCs, because we = are already doing interoperability testing, and we've been stung by = different implementations of the drafts not interworking. That's the problem. Brian On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre = > wrote: > A simple question (pointer to previous list message is fine): what > problem are we trying to solve here? > > On 11/15/12 1:48 PM, Brian Rosen wrote: >> I don't think that is right. >> >> I could be misunderstanding something but there is no specific >> proposal to change what I originally outlined. There was a >> discussion of changing the scheme to just increment the version when >> the protocol changed, ignoring whether that was a draft or RFC. We >> could do that, but I think the original proposal works well enough. >> >> There is a clear desire to have some way to indicate versions of >> drafts, as long as the RFC has a simple (say "version 1.0") version >> everyone understands. There doesn't seem to be any downside to >> changing the version on drafts. The only discussion on that point >> was whether it changes on every draft, or every draft that changes >> the schema. >> >> As long as the draft contains an RFC editor note to set the version >> to a fixed, agreed value when the RFC is published, we can do >> anything we want to with the draft versions without causing any >> harm. >> >> >> >> >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R >> > = wrote: >> >>> Including the correct Hadriel e-mail id. >>> >>> -----Original Message----- From: Parthasarathi R >>> = [mailto:partha@parthasarathi.co.in] = Sent: Thursday, November 15, >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; >>> = 'hadriel.kaplan@acmepacket.com' = Cc: 'siprec@ietf.org' Subject: RE: >>> [siprec] Metadata version indication >>> >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning >>> experience. >>> >>> Hi all, >>> >>> As per the below discussion, the namespace has to be updated for >>> each RFC (standardized) version and not for each revision of the >>> draft. SIPREC metadata namespace has to be updated as >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the >>> draft in case "1" is assumed as a starting number. Please let us >>> know in case anybody has difference of opinion in this proposal. >>> >>> Including Hadriel in this mail thread as the original requirement >>> of draft specific XML version is started by him. >>> >>> Thanks Partha >>> >>> -----Original Message----- From: = siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On = Behalf Of Peter Saint-Andre >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: >>> siprec@ietf.org Subject: Re: [siprec] = Metadata version indication >>> >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: >>>>> Matt, >>>>> >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: >>>>>> >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes >>>>>> > = wrote: >>>>>>>> If we were building a mechanism solely for this >>>>>>>> pre-release purpose I would be opposed. I see this as >>>>>>>> installing a mechanism that will work for version 1.0 and >>>>>>>> future standardized extensions/revisions of it. And then >>>>>>>> it is convenient that the same mechanism can be used for >>>>>>>> this pre-standard testing as well. >>>>>>>> >>>>>>> [MB] I agree that you need a version number. 1.0 for the >>>>>>> first version of the RFC and then 2.0 if you do a bis. If >>>>>>> someone wants to put the .10 in there and work with another >>>>>>> vendor to see if their .10 software works with the other >>>>>>> guy's, I don't see that this requires anything to be put >>>>>>> into the documents being produced by this WG. Nor, do I >>>>>>> think it requires any more discussion. We don't develops >>>>>>> specs to ensure that prototypes (and various draft >>>>>>> versions) are interoperable, we do prototypes to ensure the >>>>>>> final RFCs enable interoperability. Certainly, the former >>>>>>> would be a good thing as that means the document is headed >>>>>>> in the right direction. [/MB] >>>>>> >>>>>> >>>>>> Anecdotal evidence from my work in the XMPP Standards >>>>>> Foundation (XSF): >>>>>> >>>>>> The XSF started with namespaces (e.g. >>>>>> "http://jabber.org/protocol/muc") that did not change once a >>>>>> document was published. This worked in a perfect world, >>>>>> where these implementers are in perfect lockstep with each >>>>>> other, always updating to the current state of the I-D within >>>>>> moments (maybe days) of its publication, up to the point it >>>>>> becomes an RFC. >>>>>> >>>>>> But we do not live in a perfect world, and people develop at >>>>>> different rates, and sometimes step away from something for >>>>>> a while and might miss a couple of I-D versions. I dare say >>>>>> that some here might even deploy software based on an >>>>>> intermediate version, for various reasons we probably don't >>>>>> agree with ideologically. >>>>>> >>>>>> So, the XSF moved to using one namespace for the I-D like >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC >>>>>> phase (e.g. "urn:xmpp:time"). This helped differentiate >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was >>>>>> painfully annoying to implementers because they had to go >>>>>> through changes and deployment of those changes simply for a >>>>>> change of a constant. >>>>>> >>>>>> 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. >>>>> >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, >>>>> ... k, ... >> >> We've never gone beyond 3 or 4. >> >> We only rev the version if the protocol changes in >> backward-incompatible ways. We don't change it with every new >> version of the document. This is protocol versioning, not spec >> versioning. >> >>>>> and formally adopted ones (initial RFC and RFC'ed revisions) >>>>> correspond to whichever ones happen to have ended up in drafts >>>>> that become RFCs. So maybe in above i,j,k might have been >>>>> standardized versions while the ones in between have no >>>>> normative status. (E.g. draft-foo-core-99 has version i, as >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, >>>>> while draft-foo-corebis-19 and the RFC it becomes have version >>>>> j, etc.) >>>>> >>>>> Is that right? >> >> Basically, yes. >> >> Peter >> >>> _______________________________________________ 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 >> > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec 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. --_000_9B0B6FB9606F4D4AB133C5E9A203B694055F9C2390SOUEXC01eunic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it’s a lesson from programming life: when you’re = exchanging formatted data, always include version = information.

 

It gives the possibility of interworking with more than one = version.

 

If you are unable or unwilling to interwork with more than one = version, at least it lets you know if you’ve been given a version = that you can’t interwork with, rather than trying and falling over = with errors.

 

Dave

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 15 November 2012 23:40
To: = Brian Rosen
Cc: siprec@ietf.org
Subject: Re: = [siprec] Metadata version indication

 

But, this = version doesn't do anything to improve the interop situation.  All = that it will tell you is that Vendor A can't interop with Vendor B if = they have each implemented different versions which have different = metadata.   My understanding of what Hadriel said was that this is = all he wants to know - i.e., different versions mean you can't = interoperate.   Unless the expectation is that vendors/implementors = support multiple versions, then I don't see how this improves the = situation and adds any more value than Vendor A asking Vendor B what = version they have implemented.  

 

If the issue is that the RFC won't be available in = time for people that are implementing, I still suggest that one version = of the draft be selected and publish that as "this is what's = currently implemented", which was the approach being taken in = INSIPID.  

 

Mary. 

 

 

 

On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen <br@brianrosen.net> wrote:

There was a request to have a version number in the = schema namespace that changed when versions changed in drafts as well as = RFCs, because we are already doing interoperability testing, and we've = been stung by different implementations of the drafts not = interworking.

That's the problem.

Brian

On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

> A simple question (pointer to previous list message = is fine): what
> problem are we trying to solve = here?
>
> On 11/15/12 1:48 PM, Brian Rosen = wrote:
>> <as individual> I don't think that is = right.
>>
>> I could be misunderstanding something but = there is no specific
>> proposal to change what I originally = outlined.  There was a
>> discussion of changing the = scheme to just increment the version when
>> the protocol = changed, ignoring whether that was a draft or RFC.  We
>> = could do that, but I think the original proposal works well = enough.
>>
>> There is a clear desire to have some way = to indicate versions of
>> drafts, as long as the RFC has a = simple (say "version 1.0") version
>> everyone = understands.  There doesn't seem to be any downside to
>> = changing the version on drafts.  The only discussion on that = point
>> was whether it changes on every draft, or every draft = that changes
>> the schema.
>>
>> As long as = the draft contains an RFC editor note to set the version
>> to = a fixed, agreed value when the RFC is published, we can do
>> = anything we want to with the draft versions without causing = any
>> = harm.
>>
>>
>>
>>
>> On Nov = 15, 2012, at 12:13 PM, Parthasarathi R
>> <partha@parthasarathi.co.in= > wrote:
>>
>>> Including the correct Hadriel = e-mail id.
>>>
>>> -----Original Message----- = From: Parthasarathi R
>>> [mailto:partha@parthasarathi.co.in= ] Sent: Thursday, November 15,
>>> 2012 9:45 PM To: 'Peter = Saint-Andre'; 'Paul Kyzivat';
>>> 'hadriel.kaplan@acmepacket.c= om' Cc: 'siprec@ietf.org' = Subject: RE:
>>> [siprec] Metadata version = indication
>>>
>>> Thanks to Peter & Matt = for sharing XSF XML namespace versioning
>>> = experience.
>>>
>>> Hi = all,
>>>
>>> As per the below discussion, the = namespace has to be updated for
>>> each RFC (standardized) = version and not for each revision of the
>>> draft. SIPREC = metadata namespace has to be updated as
>>> = urn:ietf:params:xml:ns:recording:1 in the next revision of = the
>>> draft in case "1" is assumed as a starting = number. Please let us
>>> know in case anybody has = difference of opinion in this proposal.
>>>
>>> = Including Hadriel in this mail thread as the original = requirement
>>> of draft specific XML version is started by = him.
>>>
>>> Thanks = Partha
>>>
>>> -----Original Message----- From: = siprec-bounces@ietf.org
&g= t;>> [mailto:siprec-bounces@ietf.org] On = Behalf Of Peter Saint-Andre
>>> Sent: Thursday, November 15, = 2012 2:43 AM To: Paul Kyzivat Cc:
>>> siprec@ietf.org Subject: Re: = [siprec] Metadata version indication
>>>
>> On = 11/14/12 2:08 PM, Paul Kyzivat wrote:
>>>>> = Matt,
>>>>>
>>>>> On 11/14/12 3:39 = PM, Matt Miller (mamille2) = wrote:
>>>>>>
>>>>>> On Nov = 14, 2012, at 1:07 PM, Mary Barnes
>>>>>> <mary.ietf.barnes@gmail.com= > wrote:
>>>>>>>> If we were building a = mechanism solely for this
>>>>>>>> = pre-release purpose I would be opposed. I see this = as
>>>>>>>> installing a mechanism that will = work for version 1.0 and
>>>>>>>> future = standardized extensions/revisions of it. And = then
>>>>>>>> it is convenient that the same = mechanism can be used for
>>>>>>>> this = pre-standard testing as = well.
>>>>>>>>
>>>>>>>= [MB] I agree that you need a version number. 1.0 for = the
>>>>>>> first version of the RFC and then = 2.0 if you do a bis.  If
>>>>>>> someone = wants to put the .10 in there and work with = another
>>>>>>> vendor to see if their .10 = software works with the other
>>>>>>> guy's, I = don't see that this requires anything to be = put
>>>>>>> into the documents being produced by = this WG. Nor, do I
>>>>>>> think it requires any = more discussion.  We don't develops
>>>>>>> = specs to ensure that prototypes (and various = draft
>>>>>>> versions) are interoperable, we do = prototypes to ensure the
>>>>>>> final RFCs = enable interoperability. Certainly, the = former
>>>>>>> would be a good thing as that = means the document is headed
>>>>>>> in the = right direction. = [/MB]
>>>>>>
>>>>>>
>>= >>>> Anecdotal evidence from my work in the XMPP = Standards
>>>>>> Foundation = (XSF):
>>>>>>
>>>>>> The XSF = started with namespaces (e.g.
>>>>>> "http://jabber.org/protocol/muc") that did not = change once a
>>>>>> document was published. =  This worked in a perfect world,
>>>>>> where = these implementers are in perfect lockstep with = each
>>>>>> other, always updating to the current = state of the I-D within
>>>>>> moments (maybe days) = of its publication, up to the point it
>>>>>> = becomes an RFC.
>>>>>>
>>>>>> = But we do not live in a perfect world, and people develop = at
>>>>>> different rates, and sometimes step away = from something for
>>>>>> a while and might miss a = couple of I-D versions.  I dare say
>>>>>> = that some here might even deploy software based on = an
>>>>>> intermediate version, for various reasons = we probably don't
>>>>>> agree with = ideologically.
>>>>>>
>>>>>> = So, the XSF moved to using one namespace for the I-D = like
>>>>>> phase (e.g. = "urn:xmpp:time:tmp") and a different for the = RFC
>>>>>> phase (e.g. "urn:xmpp:time"). =  This helped differentiate
>>>>>> between = "pre-RFC" versions from "at-RFC" versions, but it = was
>>>>>> painfully annoying to implementers = because they had to go
>>>>>> through changes and = deployment of those changes simply for a
>>>>>> = change of a = constant.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> IIUC, = there are a sequence of versions: 1, 2, ..., i, ... = j,
>>>>> ... k, ...
>>
>> We've = never gone beyond 3 or 4.
>>
>> We only rev the = version if the protocol changes in
>> backward-incompatible = ways. We don't change it with every new
>> version of the = document. This is protocol versioning, not spec
>> = versioning.
>>
>>>>> and formally adopted = ones (initial RFC and RFC'ed revisions)
>>>>> = correspond to whichever ones happen to have ended up in = drafts
>>>>> that become RFCs. So maybe in above i,j,k = might have been
>>>>> standardized versions while the = ones in between have no
>>>>> normative status. (E.g. = draft-foo-core-99 has version i, as
>>>>> does the RFC = it becomes. Draft-foo-corebis-00 has version = i+1,
>>>>> while draft-foo-corebis-19 and the RFC it = becomes have version
>>>>> j, = etc.)
>>>>>
>>>>> Is that = right?
>>
>> Basically, yes.
>>
>> = Peter
>>
>>> = _______________________________________________ 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
>= ;>
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

________= _______________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec

 



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. 

 --_000_9B0B6FB9606F4D4AB133C5E9A203B694055F9C2390SOUEXC01eunic_-- From andrew.hutton@siemens-enterprise.com Fri Nov 16 03:22:12 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 D513D21F84B5 for ; Fri, 16 Nov 2012 03:22:12 -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=[AWL=0.000, 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 E4nkmhPd0-RR for ; Fri, 16 Nov 2012 03:22:11 -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 3A26221F8495 for ; Fri, 16 Nov 2012 03:22:11 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DF7151EB85B1; Fri, 16 Nov 2012 12:22:09 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 12:22:09 +0100 From: "Hutton, Andrew" To: Mary Barnes , Brian Rosen Thread-Topic: [siprec] Metadata version indication Thread-Index: AQHNw3KWxiUyOW9Wgk+4pI6e/c/oQ5frUp4AgAAB1YCAACjfAIAAymSg Date: Fri, 16 Nov 2012 11:22:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01368AA0@MCHP04MSX.global-ad.net> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> <50A5596E.6090708@stpeter.im> <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 16 Nov 2012 11:22:13 -0000 Hi, The only reason for needing a version number is to aid interoperability and= I tend to agree with Mary that creating a version based on draft numbers d= oes nothing to improve interoperability in fact it may make things worse. However we do need drafts to be implemented and interop testing to take pla= ce and it is highly likely that some of these pre-RFC implementations will = get deployed and probably already are. When performing such interop testing= it would be helpful if the metadata contained the version of the draft tha= t was implemented so why not make that an element in the metadata which is = included for information only. At least then developers/testers will be abl= e to quickly see what they are dealing with and it would have no impact on = interoperability. In addition I think we do need a version number which changes only when bac= kwards compatibility is an issue and I like the idea of learning from the e= xperience of the XSF and including a protocol version number (i.e. recordin= g xmlns=3D'urn:ietf:params:xml:ns:recording:1') which does not change just = because the RFC is published as again that would seem to harm interoperabil= ity for no good reason. I would support getting this in to the next update = of the draft. What we then need is this type of energy to be put in to completing the wor= k and getting to an RFC without too many more versions of the draft which i= s I think the best solution to the problem. Regards Andy (As an individual). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: 15 November 2012 23:40 > To: Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > But, this version doesn't do anything to improve the interop situation. > =A0All that it will tell you is that Vendor A can't interop with Vendor B > if they have each implemented different versions which have different > metadata. =A0 My understanding of what Hadriel said was that this is all > he wants to know - i.e., different versions mean you can't > interoperate. =A0 Unless the expectation is that vendors/implementors > support multiple versions, then I don't see how this improves the > situation and adds any more value than Vendor A asking Vendor B what > version they have implemented. >=20 > If the issue is that the RFC won't be available in time for people that > are implementing, I still suggest that one version of the draft be > selected and publish that as "this is what's currently implemented", > which was the approach being taken in INSIPID. >=20 > Mary. >=20 >=20 >=20 > On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen wrote: > There was a request to have a version number in the schema namespace > that changed when versions changed in drafts as well as RFCs, because > we are already doing interoperability testing, and we've been stung by > different implementations of the drafts not interworking. >=20 > That's the problem. >=20 > Brian > On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre > wrote: >=20 > > A simple question (pointer to previous list message is fine): what > > problem are we trying to solve here? > > > > On 11/15/12 1:48 PM, Brian Rosen wrote: > >> I don't think that is right. > >> > >> I could be misunderstanding something but there is no specific > >> proposal to change what I originally outlined. =A0There was a > >> discussion of changing the scheme to just increment the version when > >> the protocol changed, ignoring whether that was a draft or RFC. =A0We > >> could do that, but I think the original proposal works well enough. > >> > >> There is a clear desire to have some way to indicate versions of > >> drafts, as long as the RFC has a simple (say "version 1.0") version > >> everyone understands. =A0There doesn't seem to be any downside to > >> changing the version on drafts. =A0The only discussion on that point > >> was whether it changes on every draft, or every draft that changes > >> the schema. > >> > >> As long as the draft contains an RFC editor note to set the version > >> to a fixed, agreed value when the RFC is published, we can do > >> anything we want to with the draft versions without causing any > >> harm. > >> > >> > >> > >> > >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R > >> wrote: > >> > >>> Including the correct Hadriel e-mail id. > >>> > >>> -----Original Message----- From: Parthasarathi R > >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, > >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; > >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: > >>> [siprec] Metadata version indication > >>> > >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning > >>> experience. > >>> > >>> Hi all, > >>> > >>> As per the below discussion, the namespace has to be updated for > >>> each RFC (standardized) version and not for each revision of the > >>> draft. SIPREC metadata namespace has to be updated as > >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the > >>> draft in case "1" is assumed as a starting number. Please let us > >>> know in case anybody has difference of opinion in this proposal. > >>> > >>> Including Hadriel in this mail thread as the original requirement > >>> of draft specific XML version is started by him. > >>> > >>> Thanks Partha > >>> > >>> -----Original Message----- From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre > >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: > >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication > >>> > >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: > >>>>> Matt, > >>>>> > >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: > >>>>>> > >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes > >>>>>> wrote: > >>>>>>>> If we were building a mechanism solely for this > >>>>>>>> pre-release purpose I would be opposed. I see this as > >>>>>>>> installing a mechanism that will work for version 1.0 and > >>>>>>>> future standardized extensions/revisions of it. And then > >>>>>>>> it is convenient that the same mechanism can be used for > >>>>>>>> this pre-standard testing as well. > >>>>>>>> > >>>>>>> [MB] I agree that you need a version number. 1.0 for the > >>>>>>> first version of the RFC and then 2.0 if you do a bis. =A0If > >>>>>>> someone wants to put the .10 in there and work with another > >>>>>>> vendor to see if their .10 software works with the other > >>>>>>> guy's, I don't see that this requires anything to be put > >>>>>>> into the documents being produced by this WG. Nor, do I > >>>>>>> think it requires any more discussion. =A0We don't develops > >>>>>>> specs to ensure that prototypes (and various draft > >>>>>>> versions) are interoperable, we do prototypes to ensure the > >>>>>>> final RFCs enable interoperability. Certainly, the former > >>>>>>> would be a good thing as that means the document is headed > >>>>>>> in the right direction. [/MB] > >>>>>> > >>>>>> > >>>>>> Anecdotal evidence from my work in the XMPP Standards > >>>>>> Foundation (XSF): > >>>>>> > >>>>>> The XSF started with namespaces (e.g. > >>>>>> "http://jabber.org/protocol/muc") that did not change once a > >>>>>> document was published. =A0This worked in a perfect world, > >>>>>> where these implementers are in perfect lockstep with each > >>>>>> other, always updating to the current state of the I-D within > >>>>>> moments (maybe days) of its publication, up to the point it > >>>>>> becomes an RFC. > >>>>>> > >>>>>> But we do not live in a perfect world, and people develop at > >>>>>> different rates, and sometimes step away from something for > >>>>>> a while and might miss a couple of I-D versions. =A0I dare say > >>>>>> that some here might even deploy software based on an > >>>>>> intermediate version, for various reasons we probably don't > >>>>>> agree with ideologically. > >>>>>> > >>>>>> So, the XSF moved to using one namespace for the I-D like > >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC > >>>>>> phase (e.g. "urn:xmpp:time"). =A0This helped differentiate > >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was > >>>>>> painfully annoying to implementers because they had to go > >>>>>> through changes and deployment of those changes simply for a > >>>>>> change of a constant. > >>>>>> > >>>>>> 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. =A0It 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. > >>>>> > >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, > >>>>> ... k, ... > >> > >> We've never gone beyond 3 or 4. > >> > >> We only rev the version if the protocol changes in > >> backward-incompatible ways. We don't change it with every new > >> version of the document. This is protocol versioning, not spec > >> versioning. > >> > >>>>> and formally adopted ones (initial RFC and RFC'ed revisions) > >>>>> correspond to whichever ones happen to have ended up in drafts > >>>>> that become RFCs. So maybe in above i,j,k might have been > >>>>> standardized versions while the ones in between have no > >>>>> normative status. (E.g. draft-foo-core-99 has version i, as > >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, > >>>>> while draft-foo-corebis-19 and the RFC it becomes have version > >>>>> j, etc.) > >>>>> > >>>>> Is that right? > >> > >> Basically, yes. > >> > >> Peter > >> > >>> _______________________________________________ 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 > >> > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From br@brianrosen.net Fri Nov 16 05:39:50 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 2540C21F8B0C for ; Fri, 16 Nov 2012 05:39:50 -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=[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 gjIGkHGIMAbI for ; Fri, 16 Nov 2012 05:39:49 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7721F8A6D for ; Fri, 16 Nov 2012 05:39:49 -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:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=WOq1UQcZ3czPbozJ38qVPkrQrf+gkNM4IEcMGfp+GJU=; b=wI9V92rZaMMBmp9Fnk8CbGt95pqn0cm5QFmzGHFYdo+4nOHik9ds1LtB742/6Dv0AIH/xBuLCuO9RAKdhERL9b34hej8nxzlmrtVtoOzczqK+3FwRqhTs/5QawU3RByr; Received: from 184-49-187-55.phillyiap.philapa.wayport.net ([184.49.187.55]:57875) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TZM96-0000Cs-MH for siprec@ietf.org; Fri, 16 Nov 2012 08:39:48 -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: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 07:24:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> To: "siprec@ietf.org" 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 Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 16 Nov 2012 13:39:50 -0000 This IPR notice was filed against the protocol draft. It was filed = quite late, and an explanation was supplied which chairs find = satisfactory. In the IETF85 session, we asked if there were any = concerns with respect to this IPR. None were raised. =20 If you have any concerns, please raise them on the list now. Brian On Nov 6, 2012, at 5:42 PM, IETF Secretariat wrote: >=20 > Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles = Eckel: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Session > Recording Protocol" (draft-ietf-siprec-protocol) was submitted to the = IETF > Secretariat on 2012-11-06 and has been posted on the "IETF Page of = Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1912/). = The title > of the IPR disclosure is "Avaya Inc.'s Statement about IPR related to = draft- > ietf-siprec-protocol-08.""); >=20 > The IETF Secretariat >=20 From br@brianrosen.net Fri Nov 16 05:41: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 0BEB621F8499 for ; Fri, 16 Nov 2012 05:41:17 -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=[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 VAI2AhwnkbUO for ; Fri, 16 Nov 2012 05:41:16 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9321F8466 for ; Fri, 16 Nov 2012 05:41:16 -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:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=WOq1UQcZ3czPbozJ38qVPkrQrf+gkNM4IEcMGfp+GJU=; b=FJMyO2dx2Yr0qMyMJHEn17lyXH9LDhd6nSQ903RVlnuUlCGOE0zI13g5rvaanX+nAkqjhCmjQUF4J+MHqtSgRDaf7gQ7+y0Kz0dzWfZk8/jpMdwmGbqtAsZ37Mav3D9Q; Received: from neustargw.va.neustar.com ([209.173.53.233]:50980 helo=[192.168.133.86]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TZMAW-0000dk-8O for siprec@ietf.org; Fri, 16 Nov 2012 08:41:16 -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: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 08:41:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> To: "siprec@ietf.org" 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 Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 16 Nov 2012 13:41:17 -0000 This IPR notice was filed against the protocol draft. It was filed = quite late, and an explanation was supplied which chairs find = satisfactory. In the IETF85 session, we asked if there were any = concerns with respect to this IPR. None were raised. =20 If you have any concerns, please raise them on the list now. Brian On Nov 6, 2012, at 5:42 PM, IETF Secretariat wrote: >=20 > Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles = Eckel: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Session > Recording Protocol" (draft-ietf-siprec-protocol) was submitted to the = IETF > Secretariat on 2012-11-06 and has been posted on the "IETF Page of = Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1912/). = The title > of the IPR disclosure is "Avaya Inc.'s Statement about IPR related to = draft- > ietf-siprec-protocol-08.""); >=20 > The IETF Secretariat >=20 From pkyzivat@alum.mit.edu Fri Nov 16 07:36:10 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 A0CA521F8C9D for ; Fri, 16 Nov 2012 07:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, 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 hZVo9y+cElmr for ; Fri, 16 Nov 2012 07:36:10 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0A21F8C9C for ; Fri, 16 Nov 2012 07:36:09 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id QBVx1k0020ldTLk51Fc9pE; Fri, 16 Nov 2012 15:36:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id QFc81k00j3ZTu2S3QFc8cq; Fri, 16 Nov 2012 15:36:09 +0000 Message-ID: <50A65D68.7070501@alum.mit.edu> Date: Fri, 16 Nov 2012 10:36:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 16 Nov 2012 15:36:10 -0000 I can't say I'm happy about this. But AFAICT there have been no Avaya contributions to siprec, so I can find no grounds to complain. Thanks, Paul On 11/16/12 8:41 AM, Brian Rosen wrote: > This IPR notice was filed against the protocol draft. It was filed quite late, and an explanation was supplied which chairs find satisfactory. In the IETF85 session, we asked if there were any concerns with respect to this IPR. None were raised. > > If you have any concerns, please raise them on the list now. > > Brian > > On Nov 6, 2012, at 5:42 PM, IETF Secretariat wrote: > >> >> Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles Eckel: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Session >> Recording Protocol" (draft-ietf-siprec-protocol) was submitted to the IETF >> Secretariat on 2012-11-06 and has been posted on the "IETF Page of Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1912/). The title >> of the IPR disclosure is "Avaya Inc.'s Statement about IPR related to draft- >> ietf-siprec-protocol-08.""); >> >> The IETF Secretariat >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Fri Nov 16 07:56: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 6A01121F8797 for ; Fri, 16 Nov 2012 07:56:46 -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=[AWL=0.000, 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 99ymSge4Grqc for ; Fri, 16 Nov 2012 07:56:45 -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 7839B21F8521 for ; Fri, 16 Nov 2012 07:56:45 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id AEE3823F047F; Fri, 16 Nov 2012 16:56:44 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 16:56:44 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 Thread-Index: AQHNxBArk02HbP5xw02iam3W9FCc7JfsnKtg Date: Fri, 16 Nov 2012 15:56:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0136927D@MCHP04MSX.global-ad.net> References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> <50A65D68.7070501@alum.mit.edu> In-Reply-To: <50A65D68.7070501@alum.mit.edu> 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] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 16 Nov 2012 15:56:46 -0000 Avaya did contribute to the SIP extensions which were originally in http://= tools.ietf.org/html/draft-johnston-siprec-cc-rec-00 which was later merged = with the protocol draft for which Avaya is a contributor (See http://tools.= ietf.org/html/draft-ietf-siprec-protocol-08). Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 16 November 2012 15:36 > To: siprec@ietf.org > Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR > related to draft-ietf-siprec-protocol-08 >=20 > I can't say I'm happy about this. But AFAICT there have been no Avaya > contributions to siprec, so I can find no grounds to complain. >=20 > Thanks, > Paul >=20 > On 11/16/12 8:41 AM, Brian Rosen wrote: > > This IPR notice was filed against the protocol draft. It was filed > quite late, and an explanation was supplied which chairs find > satisfactory. In the IETF85 session, we asked if there were any > concerns with respect to this IPR. None were raised. > > > > If you have any concerns, please raise them on the list now. > > > > Brian > > > > On Nov 6, 2012, at 5:42 PM, IETF Secretariat > wrote: > > > >> > >> Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles > Eckel: > >> > >> An IPR disclosure that pertains to your Internet-Draft entitled > "Session > >> Recording Protocol" (draft-ietf-siprec-protocol) was submitted to > the IETF > >> Secretariat on 2012-11-06 and has been posted on the "IETF Page of > Intellectual > >> Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1912/). The title > >> of the IPR disclosure is "Avaya Inc.'s Statement about IPR related > to draft- > >> ietf-siprec-protocol-08.""); > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Nov 16 08:10:43 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 7FA3321F8585 for ; Fri, 16 Nov 2012 08:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 fHYPWTINr3Gx for ; Fri, 16 Nov 2012 08:10:41 -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 5264E21F846C for ; Fri, 16 Nov 2012 08:10:41 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 41F4A1EB8448; Fri, 16 Nov 2012 17:10:40 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 17:10:40 +0100 From: "Hutton, Andrew" To: Ofir Roth , "siprec@ietf.org" Thread-Topic: Metadata V8 - Consult Transfer Scenario Thread-Index: Ac2zynxdRKOUTh63RHKy7nJybQgSoAOb3pugAHWDfsA= Date: Fri, 16 Nov 2012 16:10:38 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01369309@MCHP04MSX.global-ad.net> References: 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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF01369309MCHP04MSXglobal_" MIME-Version: 1.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: Fri, 16 Nov 2012 16:10:43 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF01369309MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ofir, Yes it is still needed and indeed as Paul stated we need more of these. I will have a look at it over the next few days. Regards Andy From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ofir Roth Sent: 14 November 2012 07:33 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:sipre= c-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. O= nce confirmed as a valid metadata flow, I will update it with the SDP. Thanks, Ofir Roth. --_000_9F33F40F6F2CD847824537F3C4E37DDF01369309MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ofir,

 

Yes it is still needed= and indeed as Paul stated we need more of these.

 

I will have a look at = it over the next few days.

 

Regards

Andy=

 

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth
Sent: 14 November 2012 07:33
To: siprec@ietf.org
Subject: Re: [siprec] Metadata V8 - Consult Transfer Scenario

 

Hi,<= /p>

 

I did not get any feed= back 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 sc= enario (attached).

 

The scenario is simple consult transfer scenario:

1.     &= nbsp; Alice calls to Bob, Bob answer (first metadata upda= te)  

2.     &= nbsp; Alice hold the call with Bob (second metadata updat= e)

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

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

 

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

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

 

Thanks,
Ofir Roth.

--_000_9F33F40F6F2CD847824537F3C4E37DDF01369309MCHP04MSXglobal_-- From eckelcu@cisco.com Fri Nov 16 08:18:21 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 849F221F84FF for ; Fri, 16 Nov 2012 08:18:21 -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=[AWL=0.000, 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 jIScU2NDm4DV for ; Fri, 16 Nov 2012 08:18:20 -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 94CF821F84FB for ; Fri, 16 Nov 2012 08:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12205; q=dns/txt; s=iport; t=1353082699; x=1354292299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O03FQylxC80KZ/vFdfxZBLoFxF5f4llXJXIw4qpeXoo=; b=A3Fqi6Enf47LnUE7N8SUzUFNuWFQRxobBI6HGwlSIIJrROFxf/GtMlFq z4R29pPJKZQCZ8j65zVRXRhzz7vk3deICVIkkl7vxaCRmRRkLdGJpH9rv F+pWGgkBTUwy2VCxpCRkQGzWLHn34Bf2nwRME9ILpVkzG2Vtx7X1GGSrV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAABmplCtJXG+/2dsb2JhbABEwmaBCIIeAQEBBAEBAQ8BWgELDAQCAQgRBAEBAQodByEGCxQJCAIEAQ0FCAwFAgeHWQMOAQueKZYrDYlUi0ppGoQSYQOIJYolgV2CcYoWgyaBa4JvgV0HFwYY X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="143226264" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 16 Nov 2012 16:18:15 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAGGIFEM011133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Nov 2012 16:18:15 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.251]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 10:18:15 -0600 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , Mary Barnes , Brian Rosen Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac3CrM8ynQ0d4/p1R2+UYYJTcCmk7QAnJXXAAALD/4AAFBjnAAAApWcAAAA6kIAABRvgAAAYiBiAAAKS0MA= Date: Fri, 16 Nov 2012 16:18:14 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882813B40B@xmb-aln-x08.cisco.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> <50A5596E.6090708@stpeter.im> <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.net> <9F33F40F6F2CD847824537F3C4E37DDF01368AA0@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF01368AA0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19370.005 x-tm-as-result: No--71.065800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 16 Nov 2012 16:18:21 -0000 I'm in favor a adding the version number. I think we need it to make the me= tadata extensible in the future, and adding it now reduces the guesswork re= quired on behalf of the development community implementing pre-RFC versions= . We need such efforts in order to validate the model and corresponding sch= ema, so anything we can do to make their life better sounds good to me. An = implementation may choose to ignore the version field, or refuse to interwo= rk with anything other than version x, or try to interwork intelligently wi= th version x as well as version x-1. By adding the version number we enable= such interworking. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Friday, November 16, 2012 3:22 AM > To: Mary Barnes; Brian Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > Hi, >=20 > The only reason for needing a version number is to aid interoperability a= nd I > tend to agree with Mary that creating a version based on draft numbers > does nothing to improve interoperability in fact it may make things worse= . >=20 > However we do need drafts to be implemented and interop testing to take > place and it is highly likely that some of these pre-RFC implementations = will > get deployed and probably already are. When performing such interop > testing it would be helpful if the metadata contained the version of the > draft that was implemented so why not make that an element in the > metadata which is included for information only. At least then > developers/testers will be able to quickly see what they are dealing with > and it would have no impact on interoperability. >=20 > In addition I think we do need a version number which changes only when > backwards compatibility is an issue and I like the idea of learning from = the > experience of the XSF and including a protocol version number (i.e. > recording xmlns=3D'urn:ietf:params:xml:ns:recording:1') which does not > change just because the RFC is published as again that would seem to harm > interoperability for no good reason. I would support getting this in to t= he > next update of the draft. >=20 > What we then need is this type of energy to be put in to completing the > work and getting to an RFC without too many more versions of the draft > which is I think the best solution to the problem. >=20 > Regards > Andy (As an individual). >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Mary Barnes > > Sent: 15 November 2012 23:40 > > To: Brian Rosen > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Metadata version indication > > > > But, this version doesn't do anything to improve the interop situation. > > =A0All that it will tell you is that Vendor A can't interop with Vendor= B > > if they have each implemented different versions which have different > > metadata. =A0 My understanding of what Hadriel said was that this is al= l > > he wants to know - i.e., different versions mean you can't > > interoperate. =A0 Unless the expectation is that vendors/implementors > > support multiple versions, then I don't see how this improves the > > situation and adds any more value than Vendor A asking Vendor B what > > version they have implemented. > > > > If the issue is that the RFC won't be available in time for people that > > are implementing, I still suggest that one version of the draft be > > selected and publish that as "this is what's currently implemented", > > which was the approach being taken in INSIPID. > > > > Mary. > > > > > > > > On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen wrote: > > There was a request to have a version number in the schema namespace > > that changed when versions changed in drafts as well as RFCs, because > > we are already doing interoperability testing, and we've been stung by > > different implementations of the drafts not interworking. > > > > That's the problem. > > > > Brian > > On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre > > wrote: > > > > > A simple question (pointer to previous list message is fine): what > > > problem are we trying to solve here? > > > > > > On 11/15/12 1:48 PM, Brian Rosen wrote: > > >> I don't think that is right. > > >> > > >> I could be misunderstanding something but there is no specific > > >> proposal to change what I originally outlined. =A0There was a > > >> discussion of changing the scheme to just increment the version when > > >> the protocol changed, ignoring whether that was a draft or RFC. =A0W= e > > >> could do that, but I think the original proposal works well enough. > > >> > > >> There is a clear desire to have some way to indicate versions of > > >> drafts, as long as the RFC has a simple (say "version 1.0") version > > >> everyone understands. =A0There doesn't seem to be any downside to > > >> changing the version on drafts. =A0The only discussion on that point > > >> was whether it changes on every draft, or every draft that changes > > >> the schema. > > >> > > >> As long as the draft contains an RFC editor note to set the version > > >> to a fixed, agreed value when the RFC is published, we can do > > >> anything we want to with the draft versions without causing any > > >> harm. > > >> > > >> > > >> > > >> > > >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R > > >> wrote: > > >> > > >>> Including the correct Hadriel e-mail id. > > >>> > > >>> -----Original Message----- From: Parthasarathi R > > >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, > > >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; > > >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: > > >>> [siprec] Metadata version indication > > >>> > > >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning > > >>> experience. > > >>> > > >>> Hi all, > > >>> > > >>> As per the below discussion, the namespace has to be updated for > > >>> each RFC (standardized) version and not for each revision of the > > >>> draft. SIPREC metadata namespace has to be updated as > > >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the > > >>> draft in case "1" is assumed as a starting number. Please let us > > >>> know in case anybody has difference of opinion in this proposal. > > >>> > > >>> Including Hadriel in this mail thread as the original requirement > > >>> of draft specific XML version is started by him. > > >>> > > >>> Thanks Partha > > >>> > > >>> -----Original Message----- From: siprec-bounces@ietf.org > > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre > > >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: > > >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication > > >>> > > >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: > > >>>>> Matt, > > >>>>> > > >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: > > >>>>>> > > >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes > > >>>>>> wrote: > > >>>>>>>> If we were building a mechanism solely for this > > >>>>>>>> pre-release purpose I would be opposed. I see this as > > >>>>>>>> installing a mechanism that will work for version 1.0 and > > >>>>>>>> future standardized extensions/revisions of it. And then > > >>>>>>>> it is convenient that the same mechanism can be used for > > >>>>>>>> this pre-standard testing as well. > > >>>>>>>> > > >>>>>>> [MB] I agree that you need a version number. 1.0 for the > > >>>>>>> first version of the RFC and then 2.0 if you do a bis. =A0If > > >>>>>>> someone wants to put the .10 in there and work with another > > >>>>>>> vendor to see if their .10 software works with the other > > >>>>>>> guy's, I don't see that this requires anything to be put > > >>>>>>> into the documents being produced by this WG. Nor, do I > > >>>>>>> think it requires any more discussion. =A0We don't develops > > >>>>>>> specs to ensure that prototypes (and various draft > > >>>>>>> versions) are interoperable, we do prototypes to ensure the > > >>>>>>> final RFCs enable interoperability. Certainly, the former > > >>>>>>> would be a good thing as that means the document is headed > > >>>>>>> in the right direction. [/MB] > > >>>>>> > > >>>>>> > > >>>>>> Anecdotal evidence from my work in the XMPP Standards > > >>>>>> Foundation (XSF): > > >>>>>> > > >>>>>> The XSF started with namespaces (e.g. > > >>>>>> "http://jabber.org/protocol/muc") that did not change once a > > >>>>>> document was published. =A0This worked in a perfect world, > > >>>>>> where these implementers are in perfect lockstep with each > > >>>>>> other, always updating to the current state of the I-D within > > >>>>>> moments (maybe days) of its publication, up to the point it > > >>>>>> becomes an RFC. > > >>>>>> > > >>>>>> But we do not live in a perfect world, and people develop at > > >>>>>> different rates, and sometimes step away from something for > > >>>>>> a while and might miss a couple of I-D versions. =A0I dare say > > >>>>>> that some here might even deploy software based on an > > >>>>>> intermediate version, for various reasons we probably don't > > >>>>>> agree with ideologically. > > >>>>>> > > >>>>>> So, the XSF moved to using one namespace for the I-D like > > >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC > > >>>>>> phase (e.g. "urn:xmpp:time"). =A0This helped differentiate > > >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was > > >>>>>> painfully annoying to implementers because they had to go > > >>>>>> through changes and deployment of those changes simply for a > > >>>>>> change of a constant. > > >>>>>> > > >>>>>> 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. =A0It 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. > > >>>>> > > >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, > > >>>>> ... k, ... > > >> > > >> We've never gone beyond 3 or 4. > > >> > > >> We only rev the version if the protocol changes in > > >> backward-incompatible ways. We don't change it with every new > > >> version of the document. This is protocol versioning, not spec > > >> versioning. > > >> > > >>>>> and formally adopted ones (initial RFC and RFC'ed revisions) > > >>>>> correspond to whichever ones happen to have ended up in drafts > > >>>>> that become RFCs. So maybe in above i,j,k might have been > > >>>>> standardized versions while the ones in between have no > > >>>>> normative status. (E.g. draft-foo-core-99 has version i, as > > >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, > > >>>>> while draft-foo-corebis-19 and the RFC it becomes have version > > >>>>> j, etc.) > > >>>>> > > >>>>> Is that right? > > >> > > >> Basically, yes. > > >> > > >> Peter > > >> > > >>> _______________________________________________ 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 > > >> > > > > > > -- > > > Peter Saint-Andre > > > https://stpeter.im/ > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From mary.ietf.barnes@gmail.com Fri Nov 16 08:29:56 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 88E0821F86AB for ; Fri, 16 Nov 2012 08:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.418 X-Spam-Level: X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 d0z4sashY7Qr for ; Fri, 16 Nov 2012 08:29:54 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3321F8688 for ; Fri, 16 Nov 2012 08:29:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2459508lbk.31 for ; Fri, 16 Nov 2012 08:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QkLTzD9quAfb9es8rG0J8dNgul1Wn0xW8fxZHBQnqmQ=; b=vKU5b6JTB6hfGh0nFIDcsvoAyhwEXBXgbFeOjPCNnkaZkg2wRwNg8tEGiMXAuCjlIq PAzA6UPLl1tBQh9mLkAwssYslopKYbQcw2oFAgcfZJvvIRpdqh8AkjrmtpFAtmlSK2hR H5EJTcBGTqOZqwP7dHG5Ca67E6NIo1MB6y+CHD5/y1KXsrSsm9tLo1yE0V2soz8NzfIF 6SHfzjB0pM0/o6ukvN1CuZWxs/49demsywS719TXM7s1RUN0T3hy/rXfbVBihZqEDsrv 6BfzBQki5muJKklOVNCdxvXRgvJ8BE/FdnSXDpsJ678w9G0nsSyO9D67gpWcWR1FIPNF 59vA== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr2236375lbf.24.1353083392104; Fri, 16 Nov 2012 08:29:52 -0800 (PST) Received: by 10.114.69.139 with HTTP; Fri, 16 Nov 2012 08:29:51 -0800 (PST) In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882813B40B@xmb-aln-x08.cisco.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> <509D0D59.6070703@alum.mit.edu> <003401cdc0fc$f73d1740$e5b745c0$@co.in> <50A2B668.1040808@alum.mit.edu> <50A3CD51.7050504@alum.mit.edu> <50A40847.9010203@alum.mit.edu> <50A40955.8030800@stpeter.im> <005b01cdc354$8b8b16f0$a2a144d0$@co.in> <50A5596E.6090708@stpeter.im> <083725D4-7720-40DB-B73B-BE9ECC00E6DD@brianrosen.net> <9F33F40F6F2CD847824537F3C4E37DDF01368AA0@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C0882813B40B@xmb-aln-x08.cisco.com> Date: Fri, 16 Nov 2012 10:29:51 -0600 Message-ID: From: Mary Barnes To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=e0cb4efe2a0af0194904ce9f4685 Cc: "siprec@ietf.org" Subject: Re: [siprec] Metadata version indication 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, 16 Nov 2012 16:29:56 -0000 --e0cb4efe2a0af0194904ce9f4685 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 16, 2012 at 10:18 AM, Charles Eckel (eckelcu) wrote: > I'm in favor a adding the version number. I think we need it to make the > metadata extensible in the future, and adding it now reduces the guesswork > required on behalf of the development community implementing pre-RFC > versions. We need such efforts in order to validate the model and > corresponding schema, so anything we can do to make their life better > sounds good to me. An implementation may choose to ignore the version > field, or refuse to interwork with anything other than version x, or try to > interwork intelligently with version x as well as version x-1. By adding > the version number we enable such interworking. > [MB] Or you end up with 4 SIPREC implementations at an interop event, each supporting a different version and thus no one interworks. For implementors that need to interwork with multiple other implementations due to a business requirement, I think this just adds chaos. If we are doing this, then what's the motivation for ever publishing an RFC? I think the trying "to interwork intelligently" with multiple versions will result in some ugly, error prone code. Note, that I understand the need and importance of implementing drafts to increase the probability that the final RFC is accurate so that there is confidence that interop happens in a timely manner. I can also understand Hadriel's point (somewhat) that one would not interop with a system that wasn't the same version, which I thought was what motivated the addition of this version number. I think this document should clearly state that there should be no expectation of interop if the version numbers are not the same *unless* the plan is to ensure, for example, that version 2.0 would be backwards compatible with 1.0, in which case you need to put in that extensibility now, in which case you could ensure backwards compatibility with your different draft versions. [/MB] > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > > Of Hutton, Andrew > > Sent: Friday, November 16, 2012 3:22 AM > > To: Mary Barnes; Brian Rosen > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Metadata version indication > > > > Hi, > > > > The only reason for needing a version number is to aid interoperability > and I > > tend to agree with Mary that creating a version based on draft numbers > > does nothing to improve interoperability in fact it may make things > worse. > > > > However we do need drafts to be implemented and interop testing to take > > place and it is highly likely that some of these pre-RFC implementations > will > > get deployed and probably already are. When performing such interop > > testing it would be helpful if the metadata contained the version of the > > draft that was implemented so why not make that an element in the > > metadata which is included for information only. At least then > > developers/testers will be able to quickly see what they are dealing with > > and it would have no impact on interoperability. > > > > In addition I think we do need a version number which changes only when > > backwards compatibility is an issue and I like the idea of learning from > the > > experience of the XSF and including a protocol version number (i.e. > > recording xmlns='urn:ietf:params:xml:ns:recording:1') which does not > > change just because the RFC is published as again that would seem to harm > > interoperability for no good reason. I would support getting this in to > the > > next update of the draft. > > > > What we then need is this type of energy to be put in to completing the > > work and getting to an RFC without too many more versions of the draft > > which is I think the best solution to the problem. > > > > Regards > > Andy (As an individual). > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Mary Barnes > > > Sent: 15 November 2012 23:40 > > > To: Brian Rosen > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Metadata version indication > > > > > > But, this version doesn't do anything to improve the interop situation. > > > All that it will tell you is that Vendor A can't interop with Vendor B > > > if they have each implemented different versions which have different > > > metadata. My understanding of what Hadriel said was that this is all > > > he wants to know - i.e., different versions mean you can't > > > interoperate. Unless the expectation is that vendors/implementors > > > support multiple versions, then I don't see how this improves the > > > situation and adds any more value than Vendor A asking Vendor B what > > > version they have implemented. > > > > > > If the issue is that the RFC won't be available in time for people that > > > are implementing, I still suggest that one version of the draft be > > > selected and publish that as "this is what's currently implemented", > > > which was the approach being taken in INSIPID. > > > > > > Mary. > > > > > > > > > > > > On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen > wrote: > > > There was a request to have a version number in the schema namespace > > > that changed when versions changed in drafts as well as RFCs, because > > > we are already doing interoperability testing, and we've been stung by > > > different implementations of the drafts not interworking. > > > > > > That's the problem. > > > > > > Brian > > > On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre > > > wrote: > > > > > > > A simple question (pointer to previous list message is fine): what > > > > problem are we trying to solve here? > > > > > > > > On 11/15/12 1:48 PM, Brian Rosen wrote: > > > >> I don't think that is right. > > > >> > > > >> I could be misunderstanding something but there is no specific > > > >> proposal to change what I originally outlined. There was a > > > >> discussion of changing the scheme to just increment the version when > > > >> the protocol changed, ignoring whether that was a draft or RFC. We > > > >> could do that, but I think the original proposal works well enough. > > > >> > > > >> There is a clear desire to have some way to indicate versions of > > > >> drafts, as long as the RFC has a simple (say "version 1.0") version > > > >> everyone understands. There doesn't seem to be any downside to > > > >> changing the version on drafts. The only discussion on that point > > > >> was whether it changes on every draft, or every draft that changes > > > >> the schema. > > > >> > > > >> As long as the draft contains an RFC editor note to set the version > > > >> to a fixed, agreed value when the RFC is published, we can do > > > >> anything we want to with the draft versions without causing any > > > >> harm. > > > >> > > > >> > > > >> > > > >> > > > >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R > > > >> wrote: > > > >> > > > >>> Including the correct Hadriel e-mail id. > > > >>> > > > >>> -----Original Message----- From: Parthasarathi R > > > >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15, > > > >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat'; > > > >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE: > > > >>> [siprec] Metadata version indication > > > >>> > > > >>> Thanks to Peter & Matt for sharing XSF XML namespace versioning > > > >>> experience. > > > >>> > > > >>> Hi all, > > > >>> > > > >>> As per the below discussion, the namespace has to be updated for > > > >>> each RFC (standardized) version and not for each revision of the > > > >>> draft. SIPREC metadata namespace has to be updated as > > > >>> urn:ietf:params:xml:ns:recording:1 in the next revision of the > > > >>> draft in case "1" is assumed as a starting number. Please let us > > > >>> know in case anybody has difference of opinion in this proposal. > > > >>> > > > >>> Including Hadriel in this mail thread as the original requirement > > > >>> of draft specific XML version is started by him. > > > >>> > > > >>> Thanks Partha > > > >>> > > > >>> -----Original Message----- From: siprec-bounces@ietf.org > > > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre > > > >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc: > > > >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication > > > >>> > > > >> On 11/14/12 2:08 PM, Paul Kyzivat wrote: > > > >>>>> Matt, > > > >>>>> > > > >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) wrote: > > > >>>>>> > > > >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes > > > >>>>>> wrote: > > > >>>>>>>> If we were building a mechanism solely for this > > > >>>>>>>> pre-release purpose I would be opposed. I see this as > > > >>>>>>>> installing a mechanism that will work for version 1.0 and > > > >>>>>>>> future standardized extensions/revisions of it. And then > > > >>>>>>>> it is convenient that the same mechanism can be used for > > > >>>>>>>> this pre-standard testing as well. > > > >>>>>>>> > > > >>>>>>> [MB] I agree that you need a version number. 1.0 for the > > > >>>>>>> first version of the RFC and then 2.0 if you do a bis. If > > > >>>>>>> someone wants to put the .10 in there and work with another > > > >>>>>>> vendor to see if their .10 software works with the other > > > >>>>>>> guy's, I don't see that this requires anything to be put > > > >>>>>>> into the documents being produced by this WG. Nor, do I > > > >>>>>>> think it requires any more discussion. We don't develops > > > >>>>>>> specs to ensure that prototypes (and various draft > > > >>>>>>> versions) are interoperable, we do prototypes to ensure the > > > >>>>>>> final RFCs enable interoperability. Certainly, the former > > > >>>>>>> would be a good thing as that means the document is headed > > > >>>>>>> in the right direction. [/MB] > > > >>>>>> > > > >>>>>> > > > >>>>>> Anecdotal evidence from my work in the XMPP Standards > > > >>>>>> Foundation (XSF): > > > >>>>>> > > > >>>>>> The XSF started with namespaces (e.g. > > > >>>>>> "http://jabber.org/protocol/muc") that did not change once a > > > >>>>>> document was published. This worked in a perfect world, > > > >>>>>> where these implementers are in perfect lockstep with each > > > >>>>>> other, always updating to the current state of the I-D within > > > >>>>>> moments (maybe days) of its publication, up to the point it > > > >>>>>> becomes an RFC. > > > >>>>>> > > > >>>>>> But we do not live in a perfect world, and people develop at > > > >>>>>> different rates, and sometimes step away from something for > > > >>>>>> a while and might miss a couple of I-D versions. I dare say > > > >>>>>> that some here might even deploy software based on an > > > >>>>>> intermediate version, for various reasons we probably don't > > > >>>>>> agree with ideologically. > > > >>>>>> > > > >>>>>> So, the XSF moved to using one namespace for the I-D like > > > >>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC > > > >>>>>> phase (e.g. "urn:xmpp:time"). This helped differentiate > > > >>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was > > > >>>>>> painfully annoying to implementers because they had to go > > > >>>>>> through changes and deployment of those changes simply for a > > > >>>>>> change of a constant. > > > >>>>>> > > > >>>>>> 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. > > > >>>>> > > > >>>>> IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, > > > >>>>> ... k, ... > > > >> > > > >> We've never gone beyond 3 or 4. > > > >> > > > >> We only rev the version if the protocol changes in > > > >> backward-incompatible ways. We don't change it with every new > > > >> version of the document. This is protocol versioning, not spec > > > >> versioning. > > > >> > > > >>>>> and formally adopted ones (initial RFC and RFC'ed revisions) > > > >>>>> correspond to whichever ones happen to have ended up in drafts > > > >>>>> that become RFCs. So maybe in above i,j,k might have been > > > >>>>> standardized versions while the ones in between have no > > > >>>>> normative status. (E.g. draft-foo-core-99 has version i, as > > > >>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1, > > > >>>>> while draft-foo-corebis-19 and the RFC it becomes have version > > > >>>>> j, etc.) > > > >>>>> > > > >>>>> Is that right? > > > >> > > > >> Basically, yes. > > > >> > > > >> Peter > > > >> > > > >>> _______________________________________________ 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 > > > >> > > > > > > > > -- > > > > Peter Saint-Andre > > > > https://stpeter.im/ > > > > > > > > > > > > > > _______________________________________________ > > > 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 > --e0cb4efe2a0af0194904ce9f4685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 16, 2012 at 10:18 AM, Charles Eckel = (eckelcu) <eckelcu@cisco.com> wrote:
I'm in favor a adding the version number= . I think we need it to make the metadata extensible in the future, and add= ing it now reduces the guesswork required on behalf of the development comm= unity implementing pre-RFC versions. We need such efforts in order to valid= ate the model and corresponding schema, so anything we can do to make their= life better sounds good to me. An implementation may choose to ignore the = version field, or refuse to interwork with anything other than version x, o= r try to interwork intelligently with version x as well as version x-1. By = adding the version number we enable such interworking.
=A0
[MB] Or you end up with 4 SIPREC implementa= tions at an interop event, each supporting a different version and thus no = one interworks. For implementors that need to interwork with multiple other= implementations due to a business requirement, I think this just adds chao= s. =A0If we are doing this, then what's the motivation for ever publish= ing an RFC? =A0 I think the trying "to interwork intelligently" w= ith multiple versions will result in some ugly, error prone code. =A0Note, = that I understand the need and importance of implementing drafts to increas= e the probability that the final RFC is accurate so that there is confidenc= e that interop happens in a timely manner. =A0I can also understand Hadriel= 's point (somewhat) that one would not interop with a system that wasn&= #39;t the same version, which I thought was what motivated the addition of = this version number. =A0I think this document should clearly state that the= re should be no expectation of interop if the version numbers are not the s= ame *unless* the plan is to ensure, for example, that version 2.0 would be = backwards compatible with 1.0, in which case you need to put in that extens= ibility now, in which case you could ensure backwards compatibility with yo= ur different draft versions.
[/MB]=A0

Cheers,
Charles

> -----Original Message-----
> From: siprec-bounces@ietf.o= rg [mailto:siprec-bounces@ie= tf.org] On Behalf
> Of Hutton, Andrew
> Sent: Friday, November 16, 2012 3:22 AM
> To: Mary Barnes; Brian Rosen
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Metadata version indication
>
> Hi,
>
> The only reason for needing a version number is to aid interoperabilit= y and I
> tend to agree with Mary that creating a version based on draft numbers=
> does nothing to improve interoperability in fact it may make things wo= rse.
>
> However we do need drafts to be implemented and interop testing to tak= e
> place and it is highly likely that some of these pre-RFC implementatio= ns will
> get deployed and probably already are. When performing such interop > testing it would be helpful if the metadata contained the version of t= he
> draft that was implemented so why not make that an element in the
> metadata which is included for information only. At least then
> developers/testers will be able to quickly see what they are dealing w= ith
> and it would have no impact on interoperability.
>
> In addition I think we do need a version number which changes only whe= n
> backwards compatibility is an issue and I like the idea of learning fr= om the
> experience of the XSF and including a protocol version number (i.e. > recording xmlns=3D'urn:ietf:params:xml:ns:recording:1') which = does not
> change just because the RFC is published as again that would seem to h= arm
> interoperability for no good reason. I would support getting this in t= o the
> next update of the draft.
>
> What we then need is this type of energy to be put in to completing th= e
> work and getting to an RFC without too many more versions of the draft=
> which is I think the best solution to the problem.
>
> Regards
> Andy (As an individual).
>
>
>
>
> > -----Original Message-----
> > From: siprec-bounces@i= etf.org [mailto:siprec-bounc= es@ietf.org] On
> > Behalf Of Mary Barnes
> > Sent: 15 November 2012 23:40
> > To: Brian Rosen
> > Cc: siprec@ietf.org
> > Subject: Re: [siprec] Metadata version indication
> >
> > But, this version doesn't do anything to improve the interop = situation.
> > =A0All that it will tell you is that Vendor A can't interop w= ith Vendor B
> > if they have each implemented different versions which have diffe= rent
> > metadata. =A0 My understanding of what Hadriel said was that this= is all
> > he wants to know - i.e., different versions mean you can't > > interoperate. =A0 Unless the expectation is that vendors/implemen= tors
> > support multiple versions, then I don't see how this improves= the
> > situation and adds any more value than Vendor A asking Vendor B w= hat
> > version they have implemented.
> >
> > If the issue is that the RFC won't be available in time for p= eople that
> > are implementing, I still suggest that one version of the draft b= e
> > selected and publish that as "this is what's currently i= mplemented",
> > which was the approach being taken in INSIPID.
> >
> > Mary.
> >
> >
> >
> > On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen <br@brianrosen.net> wrote:
> > There was a request to have a version number in the schema namesp= ace
> > that changed when versions changed in drafts as well as RFCs, bec= ause
> > we are already doing interoperability testing, and we've been= stung by
> > different implementations of the drafts not interworking.
> >
> > That's the problem.
> >
> > Brian
> > On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre <stpeter@stpeter.im>
> > wrote:
> >
> > > A simple question (pointer to previous list message is fine)= : what
> > > problem are we trying to solve here?
> > >
> > > On 11/15/12 1:48 PM, Brian Rosen wrote:
> > >> <as individual> I don't think that is right. > > >>
> > >> I could be misunderstanding something but there is no sp= ecific
> > >> proposal to change what I originally outlined. =A0There = was a
> > >> discussion of changing the scheme to just increment the = version when
> > >> the protocol changed, ignoring whether that was a draft = or RFC. =A0We
> > >> could do that, but I think the original proposal works w= ell enough.
> > >>
> > >> There is a clear desire to have some way to indicate ver= sions of
> > >> drafts, as long as the RFC has a simple (say "versi= on 1.0") version
> > >> everyone understands. =A0There doesn't seem to be an= y downside to
> > >> changing the version on drafts. =A0The only discussion o= n that point
> > >> was whether it changes on every draft, or every draft th= at changes
> > >> the schema.
> > >>
> > >> As long as the draft contains an RFC editor note to set = the version
> > >> to a fixed, agreed value when the RFC is published, we c= an do
> > >> anything we want to with the draft versions without caus= ing any
> > >> harm.
> > >>
> > >>
> > >>
> > >>
> > >> On Nov 15, 2012, at 12:13 PM, Parthasarathi R
> > >> <partha= @parthasarathi.co.in> wrote:
> > >>
> > >>> Including the correct Hadriel e-mail id.
> > >>>
> > >>> -----Original Message----- From: Parthasarathi R
> > >>> [mailto:partha@parthasarathi.co.in] Sent: Thursday, November 15,
> > >>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'P= aul Kyzivat';
> > >>> 'hadriel.kaplan@acmepacket.com' Cc: 'siprec@ietf.org' Subject: RE:
> > >>> [siprec] Metadata version indication
> > >>>
> > >>> Thanks to Peter & Matt for sharing XSF XML names= pace versioning
> > >>> experience.
> > >>>
> > >>> Hi all,
> > >>>
> > >>> As per the below discussion, the namespace has to be= updated for
> > >>> each RFC (standardized) version and not for each rev= ision of the
> > >>> draft. SIPREC metadata namespace has to be updated a= s
> > >>> urn:ietf:params:xml:ns:recording:1 in the next revis= ion of the
> > >>> draft in case "1" is assumed as a starting= number. Please let us
> > >>> know in case anybody has difference of opinion in th= is proposal.
> > >>>
> > >>> Including Hadriel in this mail thread as the origina= l requirement
> > >>> of draft specific XML version is started by him.
> > >>>
> > >>> Thanks Partha
> > >>>
> > >>> -----Original Message----- From: siprec-bounces@ietf.org
> > >>> [mailto:s= iprec-bounces@ietf.org] On Behalf Of Peter Saint-Andre
> > >>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul K= yzivat Cc:
> > >>> siprec@ietf.org Subject: Re: [siprec] Metadata version indication
> > >>>
> > >> On 11/14/12 2:08 PM, Paul Kyzivat wrote:
> > >>>>> Matt,
> > >>>>>
> > >>>>> On 11/14/12 3:39 PM, Matt Miller (mamille2) = wrote:
> > >>>>>>
> > >>>>>> On Nov 14, 2012, at 1:07 PM, Mary Barnes=
> > >>>>>> <mary.ietf.barnes@gmail.com> wrote:
> > >>>>>>>> If we were building a mechanism = solely for this
> > >>>>>>>> pre-release purpose I would be o= pposed. I see this as
> > >>>>>>>> installing a mechanism that will= work for version 1.0 and
> > >>>>>>>> future standardized extensions/r= evisions of it. And then
> > >>>>>>>> it is convenient that the same m= echanism can be used for
> > >>>>>>>> this pre-standard testing as wel= l.
> > >>>>>>>>
> > >>>>>>> [MB] I agree that you need a version= number. 1.0 for the
> > >>>>>>> first version of the RFC and then 2.= 0 if you do a bis. =A0If
> > >>>>>>> someone wants to put the .10 in ther= e and work with another
> > >>>>>>> vendor to see if their .10 software = works with the other
> > >>>>>>> guy's, I don't see that this= requires anything to be put
> > >>>>>>> into the documents being produced by= this WG. Nor, do I
> > >>>>>>> think it requires any more discussio= n. =A0We don't develops
> > >>>>>>> specs to ensure that prototypes (and= various draft
> > >>>>>>> versions) are interoperable, we do p= rototypes to ensure the
> > >>>>>>> final RFCs enable interoperability. = Certainly, the former
> > >>>>>>> would be a good thing as that means = the document is headed
> > >>>>>>> in the right direction. [/MB]
> > >>>>>>
> > >>>>>>
> > >>>>>> Anecdotal evidence from my work in the X= MPP Standards
> > >>>>>> Foundation (XSF):
> > >>>>>>
> > >>>>>> The XSF started with namespaces (e.g. > > >>>>>> "http://jabber.org/protocol/muc") that d= id not change once a
> > >>>>>> document was published. =A0This worked i= n a perfect world,
> > >>>>>> where these implementers are in perfect = lockstep with each
> > >>>>>> other, always updating to the current st= ate of the I-D within
> > >>>>>> moments (maybe days) of its publication,= up to the point it
> > >>>>>> becomes an RFC.
> > >>>>>>
> > >>>>>> But we do not live in a perfect world, a= nd people develop at
> > >>>>>> different rates, and sometimes step away= from something for
> > >>>>>> a while and might miss a couple of I-D v= ersions. =A0I dare say
> > >>>>>> that some here might even deploy softwar= e based on an
> > >>>>>> intermediate version, for various reason= s we probably don't
> > >>>>>> agree with ideologically.
> > >>>>>>
> > >>>>>> So, the XSF moved to using one namespace= for the I-D like
> > >>>>>> phase (e.g. "urn:xmpp:time:tmp"= ;) and a different for the RFC
> > >>>>>> phase (e.g. "urn:xmpp:time"). = =A0This helped differentiate
> > >>>>>> between "pre-RFC" versions fro= m "at-RFC" versions, but it was
> > >>>>>> painfully annoying to implementers becau= se they had to go
> > >>>>>> through changes and deployment of those = changes simply for a
> > >>>>>> change of a constant.
> > >>>>>>
> > >>>>>> This led the XSF to use a protocol versi= oning scheme
> > >>>>>> currently in use (e.g. "urn:xmpp:ca= rbons:2"), where the
> > >>>>>> number starts at 0 and increments with e= ach protocol-breaking
> > >>>>>> change. =A0It meant that different teams= understood to what
> > >>>>>> level another had implemented to, and ad= option of an I-D
> > >>>>>> phase document to an RFC phase document = meant no churn simply
> > >>>>>> because the XSF accepted the work.
> > >>>>>
> > >>>>> IIUC, there are a sequence of versions: 1, 2= , ..., i, ... j,
> > >>>>> ... k, ...
> > >>
> > >> We've never gone beyond 3 or 4.
> > >>
> > >> We only rev the version if the protocol changes in
> > >> backward-incompatible ways. We don't change it with = every new
> > >> version of the document. This is protocol versioning, no= t spec
> > >> versioning.
> > >>
> > >>>>> and formally adopted ones (initial RFC and R= FC'ed revisions)
> > >>>>> correspond to whichever ones happen to have = ended up in drafts
> > >>>>> that become RFCs. So maybe in above i,j,k mi= ght have been
> > >>>>> standardized versions while the ones in betw= een have no
> > >>>>> normative status. (E.g. draft-foo-core-99 ha= s version i, as
> > >>>>> does the RFC it becomes. Draft-foo-corebis-0= 0 has version i+1,
> > >>>>> while draft-foo-corebis-19 and the RFC it be= comes have version
> > >>>>> j, etc.)
> > >>>>>
> > >>>>> Is that right?
> > >>
> > >> Basically, yes.
> > >>
> > >> Peter
> > >>
> > >>> _______________________________________________ sipr= ec mailing
> > >>> list siprec@ietf.= org https://www.ietf.org/mailman/listinfo/siprec
> > >>>
> > >>> _______________________________________________ sipr= ec mailing
> > >>> list siprec@ietf.= org https://www.ietf.org/mailman/listinfo/siprec
> > >>
> > >
> > > --
> > > Peter Saint-Andre
> > > https://st= peter.im/
> > >
> > >
> >
> > _______________________________________________
> > 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

--e0cb4efe2a0af0194904ce9f4685-- From pkyzivat@alum.mit.edu Mon Nov 19 07:17:09 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 749EC21F865D for ; Mon, 19 Nov 2012 07:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ogk9bEh7FS7V for ; Mon, 19 Nov 2012 07:17:09 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5D621F8683 for ; Mon, 19 Nov 2012 07:17:08 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id RR1g1k0041GhbT85FTH8M1; Mon, 19 Nov 2012 15:17:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id RTH71k00X3ZTu2S3TTH7hw; Mon, 19 Nov 2012 15:17:08 +0000 Message-ID: <50AA4D72.7090006@alum.mit.edu> Date: Mon, 19 Nov 2012 10:17:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com> <50A65D68.7070501@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF0136927D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0136927D@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 19 Nov 2012 15:17:09 -0000 On 11/16/12 10:56 AM, Hutton, Andrew wrote: > Avaya did contribute to the SIP extensions which were originally in http://tools.ietf.org/html/draft-johnston-siprec-cc-rec-00 which was later merged with the protocol draft for which Avaya is a contributor (See http://tools.ietf.org/html/draft-ietf-siprec-protocol-08). Oh, duh. I just searched emails for "avaya" in the address. But Alan is using a gmail address. While not being happy about this, I don't see that there is anything to do about it. Thanks, Paul > Regards > Andy (SIPREC Co-Chair). > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 16 November 2012 15:36 >> To: siprec@ietf.org >> Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR >> related to draft-ietf-siprec-protocol-08 >> >> I can't say I'm happy about this. But AFAICT there have been no Avaya >> contributions to siprec, so I can find no grounds to complain. >> >> Thanks, >> Paul >> >> On 11/16/12 8:41 AM, Brian Rosen wrote: >>> This IPR notice was filed against the protocol draft. It was filed >> quite late, and an explanation was supplied which chairs find >> satisfactory. In the IETF85 session, we asked if there were any >> concerns with respect to this IPR. None were raised. >>> >>> If you have any concerns, please raise them on the list now. >>> >>> Brian >>> >>> On Nov 6, 2012, at 5:42 PM, IETF Secretariat >> wrote: >>> >>>> >>>> Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles >> Eckel: >>>> >>>> An IPR disclosure that pertains to your Internet-Draft entitled >> "Session >>>> Recording Protocol" (draft-ietf-siprec-protocol) was submitted to >> the IETF >>>> Secretariat on 2012-11-06 and has been posted on the "IETF Page of >> Intellectual >>>> Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1912/). The title >>>> of the IPR disclosure is "Avaya Inc.'s Statement about IPR related >> to draft- >>>> ietf-siprec-protocol-08.""); >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> 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 Henry.Lum@genesyslab.com Mon Nov 19 08:18:47 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 BE1D021F863B for ; Mon, 19 Nov 2012 08:18:47 -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 XYsoeAmyEJL2 for ; Mon, 19 Nov 2012 08:18:46 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7121F862B for ; Mon, 19 Nov 2012 08:18:46 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id qAJGIhTH007828; Mon, 19 Nov 2012 08:18:44 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Nov 2012 08:18:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2012 08:18:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740971F41B@NAHALD.us.int.genesyslab.com> In-Reply-To: <50AA4D72.7090006@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 Thread-Index: Ac3GaPPP3m3Kc4jxQqeAsNnjPG1jowABogFA References: <20121106224220.23339.58702.idtracker@ietfa.amsl.com><50A65D68.7070501@alum.mit.edu><9F33F40F6F2CD847824537F3C4E37DDF0136927D@MCHP04MSX.global-ad.net> <50AA4D72.7090006@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 19 Nov 2012 16:18:27.0952 (UTC) FILETIME=[82134F00:01CDC671] Cc: siprec@ietf.org Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related to draft-ietf-siprec-protocol-08 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, 19 Nov 2012 16:18:47 -0000 Same here - I'm not thrilled to learn about this late IPR claim. I don't see we can do anything about it too since I think the RS call flow is the most obvious way of addressing active call recording. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: November-19-12 10:17 AM > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR related > to draft-ietf-siprec-protocol-08 >=20 > On 11/16/12 10:56 AM, Hutton, Andrew wrote: > > Avaya did contribute to the SIP extensions which were originally in > http://tools.ietf.org/html/draft-johnston-siprec-cc-rec-00 which was later > merged with the protocol draft for which Avaya is a contributor (See > http://tools.ietf.org/html/draft-ietf-siprec-protocol-08). >=20 > Oh, duh. I just searched emails for "avaya" in the address. But Alan is > using a gmail address. >=20 > While not being happy about this, I don't see that there is anything to > do about it. >=20 > Thanks, > Paul >=20 > > Regards > > Andy (SIPREC Co-Chair). > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 16 November 2012 15:36 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] IPR Disclosure: Avaya Inc.'s Statement about IPR > >> related to draft-ietf-siprec-protocol-08 > >> > >> I can't say I'm happy about this. But AFAICT there have been no Avaya > >> contributions to siprec, so I can find no grounds to complain. > >> > >> Thanks, > >> Paul > >> > >> On 11/16/12 8:41 AM, Brian Rosen wrote: > >>> This IPR notice was filed against the protocol draft. It was filed > >> quite late, and an explanation was supplied which chairs find > >> satisfactory. In the IETF85 session, we asked if there were any > >> concerns with respect to this IPR. None were raised. > >>> > >>> If you have any concerns, please raise them on the list now. > >>> > >>> Brian > >>> > >>> On Nov 6, 2012, at 5:42 PM, IETF Secretariat > >> wrote: > >>> > >>>> > >>>> Dear Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, Charles > >> Eckel: > >>>> > >>>> An IPR disclosure that pertains to your Internet-Draft entitled > >> "Session > >>>> Recording Protocol" (draft-ietf-siprec-protocol) was submitted to > >> the IETF > >>>> Secretariat on 2012-11-06 and has been posted on the "IETF Page of > >> Intellectual > >>>> Property Rights Disclosures" > >> (https://datatracker.ietf.org/ipr/1912/). The title > >>>> of the IPR disclosure is "Avaya Inc.'s Statement about IPR related > >> to draft- > >>>> ietf-siprec-protocol-08.""); > >>>> > >>>> The IETF Secretariat > >>>> > >>> > >>> _______________________________________________ > >>> 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 > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Mon Nov 19 08:32:57 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 B95B421F854C; Mon, 19 Nov 2012 08:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 XW229gabpzdp; Mon, 19 Nov 2012 08:32:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4B21F8552; Mon, 19 Nov 2012 08:32:56 -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: <20121119163256.7750.83966.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 08:32:56 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-10.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: Mon, 19 Nov 2012 16:32:58 -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 Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-10.txt Pages : 28 Date : 2012-11-19 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From partha@parthasarathi.co.in Mon Nov 19 08:39: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 4B58C21F86B0 for ; Mon, 19 Nov 2012 08:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.174, 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 az7E+SnqO2PE for ; Mon, 19 Nov 2012 08:39:16 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85021F86AD for ; Mon, 19 Nov 2012 08:39:16 -0800 (PST) Received: from userPC (unknown [122.179.98.71]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 307F51908110; Mon, 19 Nov 2012 16:39:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1353343155; bh=AD2CVEEPpHYsrU1HDTD7TTq8hQT98fvVs/OwHDIAwHo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=W293T3RtQcc0yxggP7Caaahm9RzvNDEJHCKvyd9S9m5x6MTaVWvYitsOjaj5MDiR0 iJdA4KK9mDxNx9DjUbUSS2aPqOTWqRvom74hoccYVIzO61Tw3tu9vsoX9NT5cfrrQl 3skcchgKhyr5HG4rXEv7QHwKTMc+ibeFFNDkOA0Q= From: "Parthasarathi R" To: References: <20121119163256.7750.83966.idtracker@ietfa.amsl.com> In-Reply-To: <20121119163256.7750.83966.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 22:09:08 +0530 Message-ID: <004e01cdc674$698f5700$3cae0500$@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: Ac3Gc4sM8HHsV6hWQYyjpzdyrMzF5gAABIoQ Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0205.50AA60B3.0181, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-10.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: Mon, 19 Nov 2012 16:39:17 -0000 Hi all, As per IETF-85 SIPREC consensus, Metadata Model Object Instances (Appendix A) and Metadata XML schema Examplesx (Appendix B) are removed from the draft in this latest -10 revision. The only open item in the draft is about SIPREC metadata version which is under discussion in the separate mail thread. Also as Paul mentioned in IETF-85 SIPREC meeting, the detail review is yet to be done. Could you please provide your valuable expert comments. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, November 19, 2012 10:03 PM To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-10.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 IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-10.txt Pages : 28 Date : 2012-11-19 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-10 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 From andrew.hutton@siemens-enterprise.com Tue Nov 20 07:56:33 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 BF0A421F86E5 for ; Tue, 20 Nov 2012 07:56:33 -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=[AWL=0.000, 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 01vvYZY+JJEf for ; Tue, 20 Nov 2012 07:56:33 -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 D683D21F86C6 for ; Tue, 20 Nov 2012 07:56:32 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 4D1901EB85B4 for ; Tue, 20 Nov 2012 16:56:31 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 16:56:31 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF85 Draft SIPREC Minutes. Thread-Index: Ac3HN5rB6huX3llNSuGqwEcW0ynA7g== Date: Tue, 20 Nov 2012 15:56:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0136BD77@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: [siprec] IETF85 Draft SIPREC Minutes. 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, 20 Nov 2012 15:56:33 -0000 Draft minutes for the IETF85 SIPREC meeting can be found at: http://www.iet= f.org/proceedings/85/minutes/minutes-85-siprec. Please let me have any comments on the minutes by Monday 26th of November. Regards Andy (SIPREC Co-Chair). From internet-drafts@ietf.org Wed Nov 21 07:56: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 6119721F854F; Wed, 21 Nov 2012 07:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 W9u23m3D3Lvi; Wed, 21 Nov 2012 07:55:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47B21F8563; Wed, 21 Nov 2012 07:55:59 -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: <20121121155559.22088.51004.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 07:55:59 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-07.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: Wed, 21 Nov 2012 15:56:00 -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 : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-07.txt Pages : 16 Date : 2012-11-21 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-architecture-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-architecture-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leon.portman@gmail.com Wed Nov 21 07:59:34 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 6D0D021F855E for ; Wed, 21 Nov 2012 07:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 ZskmQUaptsQl for ; Wed, 21 Nov 2012 07:59:34 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1721F854F for ; Wed, 21 Nov 2012 07:59:33 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so3139899wgb.13 for ; Wed, 21 Nov 2012 07:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=936DCwZJI46NU+yCOjl8GxdkUOVTneo3wJ4j73cIRqc=; b=AICSUhL5s8PA6pFJYq4xdV2SdMRhplSimlyTYoF4u+tATuyfG5xvFb80RfWMfhLnjB Rm8kttwlCsqCXqP6PgvrHjUEinlPEPpS5aW+KoCn/IseDnUS6wZ3pguleUwhXJvdfvV0 NZ7N2T+YDQ/Sw+qF3yeNJgGr+u9kX3b1zPeCu3QAfjlsB9L1UprIes8NpxufrF03ZW5S RIThCTIVuXoMCXcFyqfe94TvmjBJVz7fsyDrvjw0mC0dbKMBXhpB5t9wMMi7Jmp1Ifsd /aNSwMWTdv9lrofWalYcx2YLLXnB0WVsDzyYxmxsiN0Wc60zL1+MdbvBGNkZVJpnE4U1 fvHA== Received: by 10.216.70.195 with SMTP id p45mr867247wed.193.1353513567717; Wed, 21 Nov 2012 07:59:27 -0800 (PST) Received: from [192.168.2.105] ([37.142.157.100]) by mx.google.com with ESMTPS id w5sm794987wiz.10.2012.11.21.07.59.22 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 07:59:22 -0800 (PST) From: Leon Portman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2E9D83CD-624B-4107-A51B-EDB0B71D90D3@gmail.com> Date: Wed, 21 Nov 2012 17:59:20 +0200 To: "siprec@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [siprec] Updated architecture 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, 21 Nov 2012 15:59:34 -0000 Hello Sorry for missing Atlanta IETF, hope was fun. I just uploaded updated 07 version of the architecture draft. Main = changes based on the great review from Raj, Charles, Dave and others are = as follows: 1. changes in security section about re-keying in SRC 2. cosmeticalchanges in the text 3. updated references Regards Leon= From andrew.hutton@siemens-enterprise.com Thu Nov 22 04:28: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 CC4BF21F8964 for ; Thu, 22 Nov 2012 04:28:49 -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=[AWL=0.000, 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 MZCyfWrFqqE6 for ; Thu, 22 Nov 2012 04:28:49 -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 3782A21F8958 for ; Thu, 22 Nov 2012 04:28:49 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7DEC823F051F for ; Thu, 22 Nov 2012 13:28:47 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 13:28:45 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Milestones. Thread-Index: Ac3IrOlvJvo1n96lR8iLi4sLjZ7PvQ== Date: Thu, 22 Nov 2012 12:28:44 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0136DB7B@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: [siprec] SIPREC Milestones. 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, 22 Nov 2012 12:28:49 -0000 As discussed during the SIPREC IETF85 meeting we need to update the milesto= nes. Currently the SIPREC Milestones look like this: Jul 2012 Submit Architecture to IESG as Informational RFC =20 Oct 2012 Submit Metadata model and format to IESG as Proposed Standard RF= C =20 Sep 2012 Submit protocol draft to IESG as Proposed Standard RFC I propose the following which includes adding a new milestone for a call fl= ows draft as agreed in Atlanta: Jan 2013 Submit Architecture to IESG as Informational RFC. (Note: Leon Portman has promised an update in the next week which should th= en go to a short WGLC so tere is a chance we could achieve this before the = end of 2012). Apr 2013 Submit protocol draft to IESG as Proposed Standard RFC=20 Jun 2013 Submit Metadata model and format to IESG as Proposed Standard RF= C Aug 2013 Submit SIPREC Call Flows draft to IESG as an informational RFC. Any comments? Regards Andy From pkyzivat@alum.mit.edu Mon Nov 26 06:47: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 A35E121F857E for ; Mon, 26 Nov 2012 06:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 N5-tqZvrLUzR for ; Mon, 26 Nov 2012 06:47:24 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC221F857C for ; Mon, 26 Nov 2012 06:47:23 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta12.westchester.pa.mail.comcast.net with comcast id UDiN1k0040Fqzac5CEnP7Z; Mon, 26 Nov 2012 14:47:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id UEnN1k00p3ZTu2S3UEnP8M; Mon, 26 Nov 2012 14:47:23 +0000 Message-ID: <50B3811E.8020305@alum.mit.edu> Date: Mon, 26 Nov 2012 09:47:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF0136DB7B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0136DB7B@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SIPREC Milestones. 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, 26 Nov 2012 14:47:24 -0000 Andy, I suggest one change: make identical dates for metadata and callflows. I suggest this because a major purpose of the callflows is to verify that the metadata is correct and sufficient. So I think as long as we are working on the callflows we may be finding a need to correct the metadata. Thanks, Paul On 11/22/12 7:28 AM, Hutton, Andrew wrote: > As discussed during the SIPREC IETF85 meeting we need to update the milestones. > > Currently the SIPREC Milestones look like this: > > Jul 2012 Submit Architecture to IESG as Informational RFC > Oct 2012 Submit Metadata model and format to IESG as Proposed Standard RFC > Sep 2012 Submit protocol draft to IESG as Proposed Standard RFC > > > I propose the following which includes adding a new milestone for a call flows draft as agreed in Atlanta: > > Jan 2013 Submit Architecture to IESG as Informational RFC. > (Note: Leon Portman has promised an update in the next week which should then go to a short WGLC so tere is a chance we could achieve this before the end of 2012). > Apr 2013 Submit protocol draft to IESG as Proposed Standard RFC > Jun 2013 Submit Metadata model and format to IESG as Proposed Standard RFC > Aug 2013 Submit SIPREC Call Flows draft to IESG as an informational RFC. > > Any comments? > > Regards > Andy > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Tue Nov 27 01:26:33 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 7819B21F845D for ; Tue, 27 Nov 2012 01:26:30 -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 pwSfpwKK5lG4 for ; Tue, 27 Nov 2012 01:26:25 -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 4F46621F8427 for ; Tue, 27 Nov 2012 01:26:24 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D030E23F059D; Tue, 27 Nov 2012 10:25:58 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 10:25:58 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] SIPREC Milestones. Thread-Index: Ac3IrOlvJvo1n96lR8iLi4sLjZ7PvQDL7tAAACkcnSA= Date: Tue, 27 Nov 2012 09:25:57 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01370E0F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0136DB7B@MCHP04MSX.global-ad.net> <50B3811E.8020305@alum.mit.edu> In-Reply-To: <50B3811E.8020305@alum.mit.edu> 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] SIPREC Milestones. 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, 27 Nov 2012 09:26:33 -0000 Hi Paul, Thanks for the comment I will change both to August 2013. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 26 November 2012 14:48 > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC Milestones. >=20 > Andy, >=20 > I suggest one change: make identical dates for metadata and callflows. > I > suggest this because a major purpose of the callflows is to verify that > the metadata is correct and sufficient. So I think as long as we are > working on the callflows we may be finding a need to correct the > metadata. >=20 > Thanks, > Paul >=20 > On 11/22/12 7:28 AM, Hutton, Andrew wrote: > > As discussed during the SIPREC IETF85 meeting we need to update the > milestones. > > > > Currently the SIPREC Milestones look like this: > > > > Jul 2012 Submit Architecture to IESG as Informational RFC > > Oct 2012 Submit Metadata model and format to IESG as Proposed > Standard RFC > > Sep 2012 Submit protocol draft to IESG as Proposed Standard RFC > > > > > > I propose the following which includes adding a new milestone for a > call flows draft as agreed in Atlanta: > > > > Jan 2013 Submit Architecture to IESG as Informational RFC. > > (Note: Leon Portman has promised an update in the next week which > should then go to a short WGLC so tere is a chance we could achieve > this before the end of 2012). > > Apr 2013 Submit protocol draft to IESG as Proposed Standard RFC > > Jun 2013 Submit Metadata model and format to IESG as Proposed > Standard RFC > > Aug 2013 Submit SIPREC Call Flows draft to IESG as an informational > RFC. > > > > Any comments? > > > > Regards > > Andy > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From trac+siprec@trac.tools.ietf.org Tue Nov 27 05:33: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 0EEAA21F85A1 for ; Tue, 27 Nov 2012 05:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 RJ8U-NY1a8Mx for ; Tue, 27 Nov 2012 05:32:59 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6AB21F845A for ; Tue, 27 Nov 2012 05:32:59 -0800 (PST) Received: from localhost ([127.0.0.1]:48386 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdLHV-0002Nl-7A; Tue, 27 Nov 2012 14:32:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "siprec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: leonp@nice.com, andrew.hutton@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 27 Nov 2012 13:32:57 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/81#comment:3 Message-ID: <070.9258497ee38b6b3f43acbd77dce2edbf@trac.tools.ietf.org> References: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: leonp@nice.com, andrew.hutton@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #81: CS identification in SRS initiated recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 13:33:00 -0000 #81: CS identification in SRS initiated recording Comment (by andrew.hutton@siemens-enterprise.com): The text was finalised following agreement reached during IETF84. See minutes of this meeting http://www.ietf.org/proceedings/84/minutes/minutes-84-siprec. -- ----------------------------+----------------------------- Reporter: leonp@nice.com | Owner: leonp@nice.com Type: defect | Status: new Priority: major | Milestone: Component: Architecture | Version: Severity: - | Resolution: Keywords: | ----------------------------+----------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Tue Nov 27 05:33:18 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 14F5521F8539 for ; Tue, 27 Nov 2012 05:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 VhWyJYAxbt50 for ; Tue, 27 Nov 2012 05:33:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 831C021F8462 for ; Tue, 27 Nov 2012 05:33:17 -0800 (PST) Received: from localhost ([127.0.0.1]:48448 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdLHo-000845-7S; Tue, 27 Nov 2012 14:33:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "siprec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: leonp@nice.com, andrew.hutton@siemens-enterprise.com X-Trac-Project: siprec Date: Tue, 27 Nov 2012 13:33:16 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/81#comment:4 Message-ID: <070.6683aee408c1d07c4f659a2d154d46a0@trac.tools.ietf.org> References: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: leonp@nice.com, andrew.hutton@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #81: CS identification in SRS initiated recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 13:33:18 -0000 #81: CS identification in SRS initiated recording Changes (by andrew.hutton@siemens-enterprise.com): * status: new => closed * resolution: => fixed -- ----------------------------+----------------------------- Reporter: leonp@nice.com | Owner: leonp@nice.com Type: defect | Status: closed Priority: major | Milestone: Component: Architecture | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------+----------------------------- Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Tue Nov 27 05:48: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 2F3AD21F8558 for ; Tue, 27 Nov 2012 05:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 G5F6xa8yGbcd for ; Tue, 27 Nov 2012 05:48: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 2C11F21F854A for ; Tue, 27 Nov 2012 05:48:54 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 12AE723F04F6; Tue, 27 Nov 2012 14:48:53 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 14:48:52 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: WGLC on draft-ietf-siprec-architecture Thread-Index: Ac3Mpe64dh/UOUN3S2CAgVO5Inr5Fw== Date: Tue, 27 Nov 2012 13:48:52 +0000 Message-ID: <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: [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: Tue, 27 Nov 2012 13:48:59 -0000 Hi, As discussed during IETF85 and following the recent update we would like to= start a working group last call on draft-ietf-siprec-architecture. =20 This will be a two week WGLC ending on the 12th of December 2012. Please review the draft and provide comments as soon as possible. The latest version of the draft can be found at: http://tools.ietf.org/html= /draft-ietf-siprec-architecture-07. Regards Andy (SIPREC Co-Chair). From andrew.hutton@siemens-enterprise.com Tue Nov 27 10:31: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 0142721F85DB for ; Tue, 27 Nov 2012 10:31:24 -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.075, 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 f+9LKgnmnqpt for ; Tue, 27 Nov 2012 10:31:23 -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 4FBD321F8700 for ; Tue, 27 Nov 2012 10:31:23 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 6AC2E23F04BC for ; Tue, 27 Nov 2012 19:31:22 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 19:31:22 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Metadata version indicator consensus? Thread-Index: Ac3MzWW9f8PW/dTwSciO4LVM9GZy3w== Date: Tue, 27 Nov 2012 18:31:21 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@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: [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, 27 Nov 2012 18:31:24 -0000 Hi All, Having just read through the thread again and with the possible exception o= f 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 w= ith 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/si= prec/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 e= ach protocol-breaking change. It meant that different teams understood to = what level another had implemented to, and adoption of an I-D phase documen= t to an RFC phase document meant no churn simply because the XSF accepted t= he 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 ver= sion number if we doing something that brakes the backwards compatibility.= =20 Could people please let us know if they agree or disagree with this. Regards Andy (SIPREC Co-Chair). From br@brianrosen.net Tue Nov 27 10:49:48 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 E915E21F8723 for ; Tue, 27 Nov 2012 10:49:48 -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=[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 poxOGzmpCWpg for ; Tue, 27 Nov 2012 10:49:48 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFFA21F8563 for ; Tue, 27 Nov 2012 10:49:48 -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=C49+rOl5MLl+MqNIJM9s7+U+YwZdV90+wLzOLQWYSno=; b=BS+O5uMEr0xNOwGhr8a66ceHDMzcfOomDviDbzU//kgEHvNNITGnpbWduV9Lgkp0XKMlwMgw0qFpp5EBMbGAT1WOQgscbkCtiGgAnFKDzLx+73BrW6hNhH5EAcKNB8Eb; Received: from neustargw.va.neustar.com ([209.173.53.233]:48052 helo=[192.168.133.66]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TdQE7-0002NL-9J; Tue, 27 Nov 2012 13:49:47 -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: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> Date: Tue, 27 Nov 2012 13:49:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" 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: Tue, 27 Nov 2012 18:49:49 -0000 I am fine with this. It means the RFC has some non-zero/non-one version, but that is okay. Brian On Nov 27, 2012, at 1:31 PM, "Hutton, Andrew" = wrote: > 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 >=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 From andrew.hutton@siemens-enterprise.com Tue Nov 27 10:58:25 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 58C0121F85C0 for ; Tue, 27 Nov 2012 10:58:25 -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 VmKaWUZAjUGH for ; Tue, 27 Nov 2012 10:58:24 -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 9415C21F8570 for ; Tue, 27 Nov 2012 10:58:24 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D81941EB8510 for ; Tue, 27 Nov 2012 19:58:23 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 19:58:23 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Metadata version indicator consensus? Thread-Index: Ac3MzWW9f8PW/dTwSciO4LVM9GZy3wAA3CXw Date: Tue, 27 Nov 2012 18:58:23 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01371ABF@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@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] 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, 27 Nov 2012 18:58:25 -0000 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 > 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 From mary.ietf.barnes@gmail.com Tue Nov 27 11:08: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 73DCE21F8724 for ; Tue, 27 Nov 2012 11:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 KYnjGye3KIQn for ; Tue, 27 Nov 2012 11:08:16 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15C21F8727 for ; Tue, 27 Nov 2012 11:08:15 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10511224lah.31 for ; Tue, 27 Nov 2012 11:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6QdSbZi/Y16vWIw55qQaiyZLcrY7LtfMWrIAkCKARAA=; b=cHnBbHEXA7AdDE6VRqc+nlY3A5JyexMW+20MCLSwXhQzD5AVHVIZtBM/HnhqGxk0TH 8kMI5qiPtAdtD3n0CeFKI1G8DTEw1FI/muhUyvmm2KqlrqE2uPPrkpKYwXeNHZZtc194 NHnc1kMmEQVm0z56xja/xqToJSWcgh3BmVxDg95pZFQ7VYNNf9c1VUZECMUDmBbR9108 /e+atp5GZNDZjhG35TStrDYS0mg7/WV8oUi4MTUJ+gmqyF4co3SiGZHNdC/BP/iYKkqS a00v2n4GymW8i+axjDoOUzmeriRB+EBN8jQjuaz+hJifi74xMxfF7SRL0sxZxSEA6BXA yxlA== MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr15424949lab.48.1354043295014; Tue, 27 Nov 2012 11:08:15 -0800 (PST) Received: by 10.114.62.73 with HTTP; Tue, 27 Nov 2012 11:08:14 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> Date: Tue, 27 Nov 2012 13:08:14 -0600 Message-ID: From: Mary Barnes To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=f46d040714af9c1da104cf7ec52b 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: Tue, 27 Nov 2012 19:08:17 -0000 --f46d040714af9c1da104cf7ec52b Content-Type: text/plain; charset=ISO-8859-1 I would still like to understand the intent of the version number as I've asked in several of the threads on this topic. If folks can answer these questions so it's clear what the intended usage and meaning of that version number is, that would address my primary concerns: 1) If the version number is not the same, then is there no intention to try to interop? ["Yes" was the impression I got from what Hadriel said but the subsequent discussion didn't seem to agree with that] 2) Is the expectation for implementations to be backwards compatible - e.g., version 1.1 MUST be able to support 1.0 implementations? [This is my biggest concern. If it's "Yes", then I think there is then a burden added when any changes are made to the schema to minimize the complexity for implementors.] Mary. On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > 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 > --f46d040714af9c1da104cf7ec52b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would still like to understand the intent of the version number as I'= ve asked in several of the threads on this topic. =A0If folks can answer th= ese questions so it's clear what the intended usage and meaning of that= version number is, that would address my primary concerns:
1) =A0If the version number is not the same, then is there no intention to = try to interop? =A0["Yes" was the impression I got from what Hadr= iel said but the subsequent discussion didn't seem to agree with that]<= /div>
2) Is the expectation for implementations to be backwards compatible -= e.g., version 1.1 MUST be able to support 1.0 implementations? =A0[This is= my biggest concern. =A0If it's "Yes", then I think there is = then a burden added when any changes are made to the schema to minimize the= complexity for implementors.]

Mary.=A0



On Tue, Nov 27, 2012 at 12:31 PM, Hutto= n, Andrew <andrew.hutton@siemens-enterprise.com>= wrote:
Hi All,

Having just read through the thread again and with the possible exception o= f Mary I don't think that everyone who contributed to the discussion is= in favour of some kind of version number for metadata. =A0Does anyone disa= gree 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.or= g/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 in= crements with each protocol-breaking change. =A0It meant that different tea= ms 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 t= he XSF accepted the work".

So for SIPREC we would use something like "urn:ietf:params:xml:ns:reco= rding:0" starting with the next update to the draft and then only upda= te the version number if we doing something that brakes the backwards compa= tibility.

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

--f46d040714af9c1da104cf7ec52b-- From andrew.hutton@siemens-enterprise.com Tue Nov 27 11:24: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 ADBB721F867C for ; Tue, 27 Nov 2012 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Ul76NqA-30gz for ; Tue, 27 Nov 2012 11:24:00 -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 CD44921F8658 for ; Tue, 27 Nov 2012 11:23:59 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 18F861EB853F; Tue, 27 Nov 2012 20:23:59 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 20:23:58 +0100 From: "Hutton, Andrew" To: Mary Barnes Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: Ac3MzWW9f8PW/dTwSciO4LVM9GZy3///+YoA///sdnA= Date: Tue, 27 Nov 2012 19:23:58 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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: Tue, 27 Nov 2012 19:24:00 -0000 Hi Mary, See below. Regards Andy > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 27 November 2012 19:08 > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Metadata version indicator consensus? >=20 > I would still like to understand the intent of the version number as > I've asked in several of the threads on this topic. =A0If folks can > answer these questions so it's clear what the intended usage and > meaning of that version number is, that would address my primary > concerns: > 1) =A0If the version number is not the same, then is there no intention > to try to interop? =A0["Yes" was the impression I got from what Hadriel > said but the subsequent discussion didn't seem to agree with that] [AndyH] It was my impression from the discussion that if the version number= is different then there is no intention to interop. > 2) Is the expectation for implementations to be backwards compatible - > e.g., version 1.1 MUST be able to support 1.0 implementations? =A0[This > is my biggest concern. =A0If it's "Yes", then I think there is then a > burden added when any changes are made to the schema to minimize the > complexity for implementors.] >=20 [AndyH] - No I don't believe there is this expectation. The version number = would only be incremented if there is a backwards compatibility issue so I = would hope that such changes are rare. Having said that they are more likel= y to occur whilst the draft is immature which I don't believe is a problem. > Mary. >=20 >=20 > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew > wrote: > 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. > =A0Does 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. =A0It 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 From mary.ietf.barnes@gmail.com Tue Nov 27 11:30:29 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 D7B7721F8686 for ; Tue, 27 Nov 2012 11:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 5MUyYtNGktyQ for ; Tue, 27 Nov 2012 11:30:29 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1221F867B for ; Tue, 27 Nov 2012 11:30:27 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10682176lbk.31 for ; Tue, 27 Nov 2012 11:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BU7h7mMBFYv+EnbIgpq35hYU2nQPzphS/3MvyzaroUQ=; b=guWCArT5M0Puj3RMfnVx/2YaweaJ0uq213PPWMbXgx0sOHzlBv5UCOHlrrisXsZZGh M1Zn2V492NGkB/0Et4pY/pDNti2DrTOrhT/D+V5oDMeRQuogFFvyipLvEb2zaSU51xAT vYIJJfjmApenmw9e6Yzm3gbsXBocy/JRmvkNITLJJpiBG7jTwaRaHQaO7XJf1M97580D wK+ZFJcjAz7+LhJo4kPIpIZzYLdDRmqqZ+mMlQJsqr8KQ6f/s2Yraviw63eywue6L4Yd E1IZ5j9pXuENk0I/458rV+xbGF+14T9tRuZuZMxaoO9SV68CDTBm2LCbDAnVK/truinw BC1A== MIME-Version: 1.0 Received: by 10.112.37.167 with SMTP id z7mr7027530lbj.134.1354044626355; Tue, 27 Nov 2012 11:30:26 -0800 (PST) Received: by 10.114.62.73 with HTTP; Tue, 27 Nov 2012 11:30:26 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> Date: Tue, 27 Nov 2012 13:30:26 -0600 Message-ID: From: Mary Barnes To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=f46d0421a931f6c5cc04cf7f14da 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: Tue, 27 Nov 2012 19:30:29 -0000 --f46d0421a931f6c5cc04cf7f14da Content-Type: text/plain; charset=ISO-8859-1 Given your's and Brian's answers, I think some text should be added around the description of the version number indicating that the intent is to minimize interop problems -i.e., you'll know that the entity you intend to interact with is of the same version number and that there is no expectation for interop between different version numbers and there is no intention to ensure backwards compatibility with previous versions. Thanks, Mary. On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Hi Mary, > > See below. > > Regards > Andy > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 27 November 2012 19:08 > > To: Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Metadata version indicator consensus? > > > > I would still like to understand the intent of the version number as > > I've asked in several of the threads on this topic. If folks can > > answer these questions so it's clear what the intended usage and > > meaning of that version number is, that would address my primary > > concerns: > > 1) If the version number is not the same, then is there no intention > > to try to interop? ["Yes" was the impression I got from what Hadriel > > said but the subsequent discussion didn't seem to agree with that] > > [AndyH] It was my impression from the discussion that if the version > number is different then there is no intention to interop. > > > > 2) Is the expectation for implementations to be backwards compatible - > > e.g., version 1.1 MUST be able to support 1.0 implementations? [This > > is my biggest concern. If it's "Yes", then I think there is then a > > burden added when any changes are made to the schema to minimize the > > complexity for implementors.] > > > > [AndyH] - No I don't believe there is this expectation. The version number > would only be incremented if there is a backwards compatibility issue so I > would hope that such changes are rare. Having said that they are more > likely to occur whilst the draft is immature which I don't believe is a > problem. > > > > Mary. > > > > > > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew > > wrote: > > 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 > > --f46d0421a931f6c5cc04cf7f14da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given your's and Brian's answers, I think some text should be added= around the description of the version number indicating that the intent is= to minimize interop problems =A0-i.e., you'll know that the entity you= intend to interact with is of the same version number and that there is no= expectation for interop between different version numbers and there is no = intention to ensure backwards compatibility with previous versions. =A0
Thanks,
Mary.

On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andre= w <andrew.hutton@siemens-enterprise.com> = wrote:
Hi Mary,

See below.

Regards
Andy

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 27 November 2012 19:08
> To: Hutton, Andrew
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Metadata version indicator consensus?
>
> I would still like to understand the intent of the version number as > I've asked in several of the threads on this topic. =A0If folks ca= n
> answer these questions so it's clear what the intended usage and > meaning of that version number is, that would address my primary
> concerns:
> 1) =A0If the version number is not the same, then is there no intentio= n
> to try to interop? =A0["Yes" was the impression I got from w= hat Hadriel
> said but the subsequent discussion didn't seem to agree with that]=

[AndyH] It was my impression from the discussion that if the version = number is different then there is no intention to interop.


> 2) Is the expectation for implementations to be backwards compatible -=
> e.g., version 1.1 MUST be able to support 1.0 implementations? =A0[Thi= s
> is my biggest concern. =A0If it's "Yes", then I think th= ere is then a
> burden added when any changes are made to the schema to minimize the > complexity for implementors.]
>

[AndyH] - No I don't believe there is this expectation. The versi= on number would only be incremented if there is a backwards compatibility i= ssue so I would hope that such changes are rare. Having said that they are = more likely to occur whilst the draft is immature which I don't believe= is a problem.=A0



> Mary.
>
>
> On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew
> <andrew.hut= ton@siemens-enterprise.com> wrote:
> 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 t= he
> discussion is in favour of some kind of version number for metadata. > =A0Does 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.<= br> >
> So I think we may be able to get consensus to use the mechanism as use= d
> 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 i= n use
> (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 an= d
> increments with each protocol-breaking change. =A0It meant that differ= ent
> teams understood to what level another had implemented to, and adoptio= n
> of an I-D phase document to an RFC phase document meant no churn simpl= y
> 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 somethin= g
> 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


--f46d0421a931f6c5cc04cf7f14da-- From br@brianrosen.net Tue Nov 27 11:48:48 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 12CD621F85FE for ; Tue, 27 Nov 2012 11:48:48 -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.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 szZGG4LkKKbT for ; Tue, 27 Nov 2012 11:48:47 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id DA41221F8769 for ; Tue, 27 Nov 2012 11:48:46 -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:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=wZrHClk3hESe+Ggjxer9J0FpUqMvhZc95tmk+I8jeD0=; b=GrEcmyzUjoXSLv1J6kQi/+OCU8nPskRANxmG6dYU1Az5/UPxW+t59no1OvlgSr7MhZh0gkFB0QVlwZTyOzQSpEGxEL1ZS2erh5WzCG45aWK0itow/9VooOghcx200yCI; Received: from neustargw.va.neustar.com ([209.173.53.233]:48361 helo=[192.168.133.66]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TdR9B-0005yA-3Y; Tue, 27 Nov 2012 14:48:45 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_07FDFB91-25F7-4F97-A5D6-FC614E62B011" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: Date: Tue, 27 Nov 2012 14:48:43 -0500 Message-Id: <12973506-5D70-4AA4-86C9-BF69463719C6@brianrosen.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> To: Mary Barnes 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: Tue, 27 Nov 2012 19:48:48 -0000 --Apple-Mail=_07FDFB91-25F7-4F97-A5D6-FC614E62B011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Seems reasonable to me. Brian On Nov 27, 2012, at 2:30 PM, Mary Barnes = wrote: > Given your's and Brian's answers, I think some text should be added = around the description of the version number indicating that the intent = is to minimize interop problems -i.e., you'll know that the entity you = intend to interact with is of the same version number and that there is = no expectation for interop between different version numbers and there = is no intention to ensure backwards compatibility with previous = versions. =20 >=20 > Thanks, > Mary. >=20 >=20 > On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew = wrote: > Hi Mary, >=20 > See below. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 27 November 2012 19:08 > > To: Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Metadata version indicator consensus? > > > > I would still like to understand the intent of the version number as > > I've asked in several of the threads on this topic. If folks can > > answer these questions so it's clear what the intended usage and > > meaning of that version number is, that would address my primary > > concerns: > > 1) If the version number is not the same, then is there no = intention > > to try to interop? ["Yes" was the impression I got from what = Hadriel > > said but the subsequent discussion didn't seem to agree with that] >=20 > [AndyH] It was my impression from the discussion that if the version = number is different then there is no intention to interop. >=20 >=20 > > 2) Is the expectation for implementations to be backwards compatible = - > > e.g., version 1.1 MUST be able to support 1.0 implementations? = [This > > is my biggest concern. If it's "Yes", then I think there is then a > > burden added when any changes are made to the schema to minimize the > > complexity for implementors.] > > >=20 > [AndyH] - No I don't believe there is this expectation. The version = number would only be incremented if there is a backwards compatibility = issue so I would hope that such changes are rare. Having said that they = are more likely to occur whilst the draft is immature which I don't = believe is a problem.=20 >=20 >=20 >=20 > > Mary. > > > > > > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew > > wrote: > > 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 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec --Apple-Mail=_07FDFB91-25F7-4F97-A5D6-FC614E62B011 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Seems reasonable to me.

Brian

On Nov 27, 2012, at 2:30 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Given your's and Brian's answers, I think some text should be added around the description of the version number indicating that the intent is to minimize interop problems  -i.e., you'll know that the entity you intend to interact with is of the same version number and that there is no expectation for interop between different version numbers and there is no intention to ensure backwards compatibility with previous versions.  

Thanks,
Mary.


On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew <andrew.hutton@siemens-enterprise.com> wrote:
Hi Mary,

See below.

Regards
Andy

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 27 November 2012 19:08
> To: Hutton, Andrew
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Metadata version indicator consensus?
>
> I would still like to understand the intent of the version number as
> I've asked in several of the threads on this topic.  If folks can
> answer these questions so it's clear what the intended usage and
> meaning of that version number is, that would address my primary
> concerns:
> 1)  If the version number is not the same, then is there no intention
> to try to interop?  ["Yes" was the impression I got from what Hadriel
> said but the subsequent discussion didn't seem to agree with that]

[AndyH] It was my impression from the discussion that if the version number is different then there is no intention to interop.


> 2) Is the expectation for implementations to be backwards compatible -
> e.g., version 1.1 MUST be able to support 1.0 implementations?  [This
> is my biggest concern.  If it's "Yes", then I think there is then a
> burden added when any changes are made to the schema to minimize the
> complexity for implementors.]
>

[AndyH] - No I don't believe there is this expectation. The version number would only be incremented if there is a backwards compatibility issue so I would hope that such changes are rare. Having said that they are more likely to occur whilst the draft is immature which I don't believe is a problem. 



> Mary.
>
>
> On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew
> <andrew.hutton@siemens-enterprise.com> wrote:
> 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

--Apple-Mail=_07FDFB91-25F7-4F97-A5D6-FC614E62B011-- From pkyzivat@alum.mit.edu Tue Nov 27 12:07:25 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 1F47B21F8764 for ; Tue, 27 Nov 2012 12:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, 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 juNA8LB7+lmu for ; Tue, 27 Nov 2012 12:07:20 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3373E21F8751 for ; Tue, 27 Nov 2012 12:07:20 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id Ub001k00D1GhbT853k7Krv; Tue, 27 Nov 2012 20:07:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id Uk7K1k00M3ZTu2S3Tk7KxB; Tue, 27 Nov 2012 20:07:19 +0000 Message-ID: <50B51D75.8020709@alum.mit.edu> Date: Tue, 27 Nov 2012 15:07:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> <12973506-5D70-4AA4-86C9-BF69463719C6@brianrosen.net> In-Reply-To: <12973506-5D70-4AA4-86C9-BF69463719C6@brianrosen.net> 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=1354046839; bh=UcuUTkE9ittZPGtbhxE67lxy+v3+ut1PpVtoLKAgGLo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y5xnkEZLKuv46vT9/ZdNFP3HvRApRlpkEzFsjAJ6ZVPjbI8XnLZpy38zhYbv1TalH 2oIPLrc2r1WmtUQbivASn/5CMwuDiicLMZo9v4khM2frXFvh8P/Bq2RBfRvkoZ6LnT orCZkZpqsKNHeRxnmePR+FZkA1epEqEdly1Io9TgcyUJASMyNSXI/Cp0vnUb6xP5Wo AgglkjmFm5db1yOPBTrEXtqg/eXf++lxHy4zSaRJSEAzCO9sCB+A3wl/PODhinZlpY 5pVwizIBpnIH6vhp6f2F4961RlWh2Aq51Ukje0CGn8ojcyOMUZPPFcPGd2+Of3Y761 rNWOZZpOZXHhw== 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, 27 Nov 2012 20:07:25 -0000 I'm ok with this. While I think there should be no *expectation* of interoperability with different version numbers, I also think there is nothing *forbidding* an SRS from supporting SRCs using different versions. Thanks, Paul On 11/27/12 2:48 PM, Brian Rosen wrote: > Seems reasonable to me. > > Brian > > On Nov 27, 2012, at 2:30 PM, Mary Barnes > wrote: > >> Given your's and Brian's answers, I think some text should be added >> around the description of the version number indicating that the >> intent is to minimize interop problems -i.e., you'll know that the >> entity you intend to interact with is of the same version number and >> that there is no expectation for interop between different version >> numbers and there is no intention to ensure backwards compatibility >> with previous versions. >> >> Thanks, >> Mary. >> >> >> On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew >> > > wrote: >> >> Hi Mary, >> >> See below. >> >> Regards >> Andy >> >> > -----Original Message----- >> > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> ] >> > Sent: 27 November 2012 19:08 >> > To: Hutton, Andrew >> > Cc: siprec@ietf.org >> > Subject: Re: [siprec] Metadata version indicator consensus? >> > >> > I would still like to understand the intent of the version number as >> > I've asked in several of the threads on this topic. If folks can >> > answer these questions so it's clear what the intended usage and >> > meaning of that version number is, that would address my primary >> > concerns: >> > 1) If the version number is not the same, then is there no >> intention >> > to try to interop? ["Yes" was the impression I got from what >> Hadriel >> > said but the subsequent discussion didn't seem to agree with that] >> >> [AndyH] It was my impression from the discussion that if the >> version number is different then there is no intention to interop. >> >> >> > 2) Is the expectation for implementations to be backwards >> compatible - >> > e.g., version 1.1 MUST be able to support 1.0 implementations? >> [This >> > is my biggest concern. If it's "Yes", then I think there is then a >> > burden added when any changes are made to the schema to minimize the >> > complexity for implementors.] >> > >> >> [AndyH] - No I don't believe there is this expectation. The >> version number would only be incremented if there is a backwards >> compatibility issue so I would hope that such changes are rare. >> Having said that they are more likely to occur whilst the draft is >> immature which I don't believe is a problem. >> >> >> >> >> > Mary. >> > >> > >> > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew >> > > > wrote: >> > 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 > From mary.ietf.barnes@gmail.com Tue Nov 27 12:37:32 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 2139421F8767 for ; Tue, 27 Nov 2012 12:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 3Q4-iMvd1hvO for ; Tue, 27 Nov 2012 12:37:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC8EB21F8755 for ; Tue, 27 Nov 2012 12:37:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10577720lah.31 for ; Tue, 27 Nov 2012 12:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cdf6fxQLbOrezi6WFB7ZfyRgNg+3haD71W2sOW5Hf9k=; b=ZoONuOk82WLBpgIBmSJsPYfeO4wZgVQcootbx+lxMw7Aw1zX7ecOUHtGSHdQbLDLNf bVFetpTSmQINE7LUWQxfDmcf/WpFMwhrwluWup78UacqDZ2V6OMTQs2Ue9/On0Lq3otz Ew2Ldq0A0iWPsQn8tF0Qd2KpWPUOdYKDtIUpSxeWuOw3TvQv7pfMZ7i8SHUN687Y5qQ6 60ArElYjf2+NTMatf0sq3aPtyT+cEX8BxhDixmr7qqEkbKIwcWQX5k94QVMW6GttcPPZ E69DsJOJKfkooFa9ydnbIjmEVyokT0bM7xEh7HezWBE8Hsd9cgnIjVotoZJTAWCNr9Pg TAgw== MIME-Version: 1.0 Received: by 10.112.37.167 with SMTP id z7mr7098262lbj.134.1354048646652; Tue, 27 Nov 2012 12:37:26 -0800 (PST) Received: by 10.114.62.73 with HTTP; Tue, 27 Nov 2012 12:37:26 -0800 (PST) In-Reply-To: <50B51D75.8020709@alum.mit.edu> References: <9F33F40F6F2CD847824537F3C4E37DDF013716F4@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF01371B93@MCHP04MSX.global-ad.net> <12973506-5D70-4AA4-86C9-BF69463719C6@brianrosen.net> <50B51D75.8020709@alum.mit.edu> Date: Tue, 27 Nov 2012 14:37:26 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0421a93197a43b04cf8004ff 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: Tue, 27 Nov 2012 20:37:32 -0000 --f46d0421a93197a43b04cf8004ff Content-Type: text/plain; charset=ISO-8859-1 Sure - it's not forbidden, but it's not recommended and we don't want people saying the spec is broken because the different versions don't interoperate. Mary. On Tue, Nov 27, 2012 at 2:07 PM, Paul Kyzivat wrote: > I'm ok with this. > > While I think there should be no *expectation* of interoperability with > different version numbers, I also think there is nothing *forbidding* an > SRS from supporting SRCs using different versions. > > Thanks, > Paul > > > On 11/27/12 2:48 PM, Brian Rosen wrote: > >> Seems reasonable to me. >> >> Brian >> >> On Nov 27, 2012, at 2:30 PM, Mary Barnes > >> >> wrote: >> >> Given your's and Brian's answers, I think some text should be added >>> around the description of the version number indicating that the >>> intent is to minimize interop problems -i.e., you'll know that the >>> entity you intend to interact with is of the same version number and >>> that there is no expectation for interop between different version >>> numbers and there is no intention to ensure backwards compatibility >>> with previous versions. >>> >>> Thanks, >>> Mary. >>> >>> >>> On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew >>> >>> >> >>> wrote: >>> >>> Hi Mary, >>> >>> See below. >>> >>> Regards >>> Andy >>> >>> > -----Original Message----- >>> > From: Mary Barnes [mailto:mary.ietf.barnes@**gmail.com >>> >] >>> > Sent: 27 November 2012 19:08 >>> > To: Hutton, Andrew >>> > Cc: siprec@ietf.org >>> > Subject: Re: [siprec] Metadata version indicator consensus? >>> > >>> > I would still like to understand the intent of the version number >>> as >>> > I've asked in several of the threads on this topic. If folks can >>> > answer these questions so it's clear what the intended usage and >>> > meaning of that version number is, that would address my primary >>> > concerns: >>> > 1) If the version number is not the same, then is there no >>> intention >>> > to try to interop? ["Yes" was the impression I got from what >>> Hadriel >>> > said but the subsequent discussion didn't seem to agree with that] >>> >>> [AndyH] It was my impression from the discussion that if the >>> version number is different then there is no intention to interop. >>> >>> >>> > 2) Is the expectation for implementations to be backwards >>> compatible - >>> > e.g., version 1.1 MUST be able to support 1.0 implementations? >>> [This >>> > is my biggest concern. If it's "Yes", then I think there is then a >>> > burden added when any changes are made to the schema to minimize >>> the >>> > complexity for implementors.] >>> > >>> >>> [AndyH] - No I don't believe there is this expectation. The >>> version number would only be incremented if there is a backwards >>> compatibility issue so I would hope that such changes are rare. >>> Having said that they are more likely to occur whilst the draft is >>> immature which I don't believe is a problem. >>> >>> >>> >>> >>> > Mary. >>> > >>> > >>> > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew >>> > >>> >> >>> wrote: >>> > 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 > --f46d0421a93197a43b04cf8004ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure - it's not forbidden, but it's not recommended and we don'= t want people saying the spec is broken because the different versions don&= #39;t interoperate. =A0

Mary.


On Tue, Nov 27, 2012 at 2:07 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
I'm ok with this.

While I think there should be no *expectation* of interoperability with dif= ferent version numbers, I also think there is nothing *forbidding* an SRS f= rom supporting SRCs using different versions.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 11/27/12 2:48 PM, Brian Rosen wrote:
Seems reasonable to me.

Brian

On Nov 27, 2012, at 2:30 PM, Mary Barnes <mary.ietf.barnes@gmail.com
<mailto:= mary.ietf.barnes@gmail.com>> wrote:

Given your's and Brian's answers, I think some text should be added=
around the description of the version number indicating that the
intent is to minimize interop problems =A0-i.e., you'll know that the entity you intend to interact with is of the same version number and
that there is no expectation for interop between different version
numbers and there is no intention to ensure backwards compatibility
with previous versions.

Thanks,
Mary.


On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew
<andrew.hutton@siemens-enterprise.com
<mailto:andrew.hutton@siemens-enterprise.com>> wrote:<= br>
=A0 =A0 Hi Mary,

=A0 =A0 See below.

=A0 =A0 Regards
=A0 =A0 Andy

=A0 =A0 > -----Original Message-----
=A0 =A0 > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 <mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 > Sent: 27 November 2012 19:08
=A0 =A0 > To: Hutton, Andrew
=A0 =A0 > Cc: sipre= c@ietf.org <mailto:siprec@ietf.org>
=A0 =A0 > Subject: Re: [siprec] Metadata version indicator consensus? =A0 =A0 >
=A0 =A0 > I would still like to understand the intent of the version num= ber as
=A0 =A0 > I've asked in several of the threads on this topic. =A0If = folks can
=A0 =A0 > answer these questions so it's clear what the intended usa= ge and
=A0 =A0 > meaning of that version number is, that would address my prima= ry
=A0 =A0 > concerns:
=A0 =A0 > 1) =A0If the version number is not the same, then is there no<= br> =A0 =A0 intention
=A0 =A0 > to try to interop? =A0["Yes" was the impression I go= t from what
=A0 =A0 Hadriel
=A0 =A0 > said but the subsequent discussion didn't seem to agree wi= th that]

=A0 =A0 [AndyH] It was my impression from the discussion that if the
=A0 =A0 version number is different then there is no intention to interop.<= br>

=A0 =A0 > 2) Is the expectation for implementations to be backwards
=A0 =A0 compatible -
=A0 =A0 > e.g., version 1.1 MUST be able to support 1.0 implementations?=
=A0 =A0 =A0[This
=A0 =A0 > is my biggest concern. =A0If it's "Yes", then I = think there is then a
=A0 =A0 > burden added when any changes are made to the schema to minimi= ze the
=A0 =A0 > complexity for implementors.]
=A0 =A0 >

=A0 =A0 [AndyH] - No I don't believe there is this expectation. The
=A0 =A0 version number would only be incremented if there is a backwards =A0 =A0 compatibility issue so I would hope that such changes are rare.
=A0 =A0 Having said that they are more likely to occur whilst the draft is<= br> =A0 =A0 immature which I don't believe is a problem.




=A0 =A0 > Mary.
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew
=A0 =A0 > <andrew.hutton@siemens-enterprise.com
=A0 =A0 <mailto:andrew.hutton@siemens-enterprise.com>> w= rote:
=A0 =A0 > Hi All,
=A0 =A0 >
=A0 =A0 > Having just read through the thread again and with the possibl= e
=A0 =A0 > exception of Mary I don't think that everyone who contribu= ted to the
=A0 =A0 > discussion is in favour of some kind of version number for met= adata.
=A0 =A0 > =A0Does anyone disagree with that?
=A0 =A0 >
=A0 =A0 > I also got the impression that there was a body of opinion tha= t the
=A0 =A0 > version should NOT be automatically incremented on a per draft=
=A0 =A0 basis.
=A0 =A0 >
=A0 =A0 > So I think we may be able to get consensus to use the mechanis= m
=A0 =A0 as used
=A0 =A0 > by XMPP as indicated by Matt Miller in http://www.ietf.org/mail-
=A0 =A0 > archive/web/siprec/current/msg03532.html. In which he s= tated:
=A0 =A0 >
=A0 =A0 > "This led the XSF to use a protocol versioning scheme cur= rently
=A0 =A0 in use
=A0 =A0 > (e.g. "urn:xmpp:carbons:2"), where the number starts= at 0 and
=A0 =A0 > increments with each protocol-breaking change. =A0It meant tha= t
=A0 =A0 different
=A0 =A0 > teams understood to what level another had implemented to, and=
=A0 =A0 adoption
=A0 =A0 > of an I-D phase document to an RFC phase document meant no chu= rn
=A0 =A0 simply
=A0 =A0 > because the XSF accepted the work".
=A0 =A0 >
=A0 =A0 > So for SIPREC we would use something like
=A0 =A0 > "urn:ietf:params:xml:ns:recording:0" starting= with the next
=A0 =A0 update to
=A0 =A0 > the draft and then only update the version number if we doing<= br> =A0 =A0 something
=A0 =A0 > that brakes the backwards compatibility.
=A0 =A0 >
=A0 =A0 > Could people please let us know if they agree or disagree with= this.
=A0 =A0 >
=A0 =A0 > Regards
=A0 =A0 > Andy (SIPREC Co-Chair).
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > _______________________________________________
=A0 =A0 > siprec mailing list
=A0 =A0 > siprec@ie= tf.org <mailto:= siprec@ietf.org>

=A0 =A0 > https://www.ietf.org/mailman/listinfo/siprec


_______________________________________________
siprec mailing list
siprec@ietf.org<= /a> <mailto: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

--f46d0421a93197a43b04cf8004ff-- From eckelcu@cisco.com Tue Nov 27 14:49:43 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 B73A321F8457 for ; Tue, 27 Nov 2012 14:49:43 -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 HI1MC6y7bBgh for ; Tue, 27 Nov 2012 14:49:43 -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 1728721F845D for ; Tue, 27 Nov 2012 14:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1660; q=dns/txt; s=iport; t=1354056583; x=1355266183; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yefvj9ShkjRQ6Lm/6URQG3q4d83NTpDD8isGzf0dQ/w=; b=gOMnOhfgoi5tb/jxTrAoMCLDxuMsLL7dtWnEPfytd/2lbze8sJEWHNZB TWJ2ZsgA7JIVF10ZrHuMA/YxZiisIBVuid7jWzAeqUuSxWh7Ecyft6tJ3 wr7F4NQNslStUIQRoEOr572kqMvdZlbXZIBhtkvO7/sq5BA08Ay79emcV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoLAJRCtVCtJV2Z/2dsb2JhbABFwB8WbAeCIAEEOlEBKhRCHwcBBBuIBAGeRpEPkDSQGmEDpkWCcIFkJBg X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146818587" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2012 22:49:42 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qARMngXH018198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 27 Nov 2012 22:49:42 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; Tue, 27 Nov 2012 16:49:42 -0600 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9w== Date: Tue, 27 Nov 2012 22:49:42 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CA661@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: [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: Tue, 27 Nov 2012 22:49:43 -0000 Hi, I am in the process of updating some sections of the protocol draft 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 and SRS MUST implement TLS mutual authentication for establishing the 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 digest authe= ntication? It seems to me the paragraph on digest authentication should be = removed. Does anyone disagree? Second, section 12.2, RTP handling, currently ends as follows: For SRCs that perform transcoding or mixing of media before sending to the SRS, the SRC MUST negotiate a different security key than the one being used in the CS, to ensure that the security in the CS is not compromised by the SRC when reusing the same security key. During the SIPREC session at IETF 85, there was discussion as to why it is = necessary to negotiate a different security key. I am not sure what else to= put here as justification for this requirement. Any suggestions? If not, I= will leave it as is. Cheers, Charles From br@brianrosen.net Tue Nov 27 14:59: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 8546F21E804A for ; Tue, 27 Nov 2012 14:59:00 -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 wkchLRf4MX5v for ; Tue, 27 Nov 2012 14:59:00 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F121E8049 for ; Tue, 27 Nov 2012 14:58:59 -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=453QrOuLi8vqwQG2xN07zp2jPjsZbZsrId9cPFLN4VA=; b=bRUDxusSv9wqSsYlkymSZCGLjx476v+4FZoi16sm/sZUK6nxfy5OLdNm0FQuN+o81agXQwLjMPTZxZy5ruB5aBXLylwv7GpiQVtLSURh6AmEagLR7xUGuaWxtiyUZOzx; Received: from neustargw.va.neustar.com ([209.173.53.233]:47621 helo=[192.168.133.99]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TdU7G-0003xj-Qm; Tue, 27 Nov 2012 17:58:58 -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: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> Date: Tue, 27 Nov 2012 17:58:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <52376CF1-7A3A-4C21-9D77-9B45CFB06122@brianrosen.net> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> To: Charles Eckel (eckelcu) 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] 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: Tue, 27 Nov 2012 22:59:00 -0000 Transcoding, not so sure. Mixing, you could observe that if SRC used = A's key to encode A+B then, in theory, A could observe A+B and decode = it. in practice, if SRC is mixing A and B, then A can hear/see/type B = anyway. Maybe get rid of the MUST and just say that re-use of keys should = consider if it's possible for the other end, who has the original key, = to get data they shouldn't be able to get. Brian On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) = wrote: > Hi, >=20 > I am in the process of updating some sections of the protocol draft = per the conclusions reached at IETF 85. In working on the security = considerations, I ran into a couple issues. >=20 > First, section 12.1 Authentication and Authorization, reads as = follows: >=20 > 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. >=20 > At the transport level, the recording session uses TLS = authentication > to validate the authenticity of the SRC and SRS. The SRC and SRS > MUST implement TLS mutual authentication for establishing the > recording session, and whether the SRC/SRS chooses to use > authentication is a deployment decision. >=20 > If using mutual TLS authentication, what is the purpose of the digest = authentication? It seems to me the paragraph on digest authentication = should be removed. Does anyone disagree? >=20 > Second, section 12.2, RTP handling, currently ends as follows: >=20 > For SRCs that perform transcoding or mixing of media before sending > to the SRS, the SRC MUST negotiate a different security key than the > one being used in the CS, to ensure that the security in the CS is > not compromised by the SRC when reusing the same security key. >=20 > During the SIPREC session at IETF 85, there was discussion as to why = it is necessary to negotiate a different security key. I am not sure = what else to put here as justification for this requirement. Any = suggestions? If not, I will leave it as is. >=20 > Cheers, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Nov 28 09:35:12 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 0877121F88B6 for ; Wed, 28 Nov 2012 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, 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 OEWFai2w8yvO for ; Wed, 28 Nov 2012 09:35:11 -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 E2DB021F86D6 for ; Wed, 28 Nov 2012 09:35:10 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id V0CJ1k0010EZKEL555bADx; Wed, 28 Nov 2012 17:35:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id V5bA1k00M3ZTu2S3M5bAsj; Wed, 28 Nov 2012 17:35:10 +0000 Message-ID: <50B64B4D.40709@alum.mit.edu> Date: Wed, 28 Nov 2012 12:35:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CA661@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=1354124110; bh=w+4mADHlVrqxJx8sPKlMURptvvRq4wC3I/IG4F9XZbE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F2eb7nCCeKrHHC4lmIQh/sxAEfrYZG/qT78Nt+7itiqixzIc6aLzZikRdzk6jVJOZ +PsDkKUjtWsgwDGqEfoavgAympjFASPPOImKLfGvsPpetUVmXwHZ0jaXVttyMLhMy4 +HvfRMwBWzrUDmNxVSFczeVV32iNyQT0ASNXn+hPnrIXQ/FvAET2O/Hk4APLEYPnqV nf39uMIluCBe7eHROqPABehQetZnrPK6U6uesGME9acUXug6oG1ljLH+u716Oc1+sM rHCKb8lR0Eg7zocX9KlUVAx8FEGJTGWc+Fw2mDM2BvkStg8kTdp5IlNUyiZlYiFtJJ 4KFyyH4ceIImg== 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, 28 Nov 2012 17:35:12 -0000 On 11/27/12 5:49 PM, Charles Eckel (eckelcu) wrote: > Hi, > > I am in the process of updating some sections of the protocol draft 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 and SRS > MUST implement TLS mutual authentication for establishing the > 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 digest 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 From eckelcu@cisco.com Wed Nov 28 17:08:50 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 E488621F895F for ; Wed, 28 Nov 2012 17:08:50 -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 mjr+Ocd0ON-b for ; Wed, 28 Nov 2012 17:08:50 -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 19CA021F895C for ; Wed, 28 Nov 2012 17:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3140; q=dns/txt; s=iport; t=1354151330; x=1355360930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r+2gJ1me3T9UXy4DnkOoUJPN3bJSw31yfQ70zBge3ng=; b=DhTCHMc+IxyNvElxZTIGdCjCBjYZVFEYZJfKSChpDwenftT/0C0hIcYx 9EuCHbja+h8nigCb2+koMnk8wIP5c6fTwW+UgkdUMWWB+7EK3bI5oHcO7 bLz/WiJMgJONuq+J3MAXx1q2kg3GiAPZsyiS05fydQttwtOuvMoNzM6Ng c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHS0tlCtJXHA/2dsb2JhbABFwCQWc4IeAQEBBAEBATc0CwwEAgEIDgMEAQEBChQJBycLFAkIAQEEDgUIiAgMvwIEjD+DYGEDpkWCcoFlJBg X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147304809" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 29 Nov 2012 01:08:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAT18nNs010010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 01:08:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 19:08:49 -0600 From: "Charles Eckel (eckelcu)" To: Brian Rosen Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAM5VyAACmYlgA= Date: Thu, 29 Nov 2012 01:08:49 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CC1B9@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <52376CF1-7A3A-4C21-9D77-9B45CFB06122@brianrosen.net> In-Reply-To: <52376CF1-7A3A-4C21-9D77-9B45CFB06122@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.250] 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: Thu, 29 Nov 2012 01:08:51 -0000 How about if we say: SRCs that modify an encrypted media stream (e.g. transcode or mix) = when relaying=20 it from a CS to an RS SHOULD negotiate a different security key tha= n the one used in the CS, to ensure that it is not possible for someone w= ho has the key from the CS to access data they should not be able to access. Does that cover it clearly? Thanks, Charles > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, November 27, 2012 2:59 PM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] security considerations for protocol draft >=20 > Transcoding, not so sure. Mixing, you could observe that if SRC used A's= key > to encode A+B then, in theory, A could observe A+B and decode it. in > practice, if SRC is mixing A and B, then A can hear/see/type B anyway. >=20 > Maybe get rid of the MUST and just say that re-use of keys should conside= r if > it's possible for the other end, who has the original key, to get data th= ey > shouldn't be able to get. >=20 > Brian >=20 > On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) > wrote: >=20 > > Hi, > > > > I am in the process of updating some sections of the protocol draft 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 and SRS > > MUST implement TLS mutual authentication for establishing the > > 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 digest > authentication? It seems to me the paragraph on digest authentication > should be removed. Does anyone disagree? > > > > Second, section 12.2, RTP handling, currently ends as follows: > > > > For SRCs that perform transcoding or mixing of media before sending > > to the SRS, the SRC MUST negotiate a different security key than the > > one being used in the CS, to ensure that the security in the CS is > > not compromised by the SRC when reusing the same security key. > > > > During the SIPREC session at IETF 85, there was discussion as to why it= is > necessary to negotiate a different security key. I am not sure what else = to > put here as justification for this requirement. Any suggestions? If not, = I will > leave it as is. > > > > Cheers, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From mperumal@cisco.com Thu Nov 29 00:18:04 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 D464C21F8A08 for ; Thu, 29 Nov 2012 00:18:04 -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 IfsBiT56Klkh for ; Thu, 29 Nov 2012 00:18:04 -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 D410C21F89FD for ; Thu, 29 Nov 2012 00:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4164; q=dns/txt; s=iport; t=1354177084; x=1355386684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hBOUfO/W865Dvm3MG/q8CjZm0ShQaGmBCjg0yOBNgcI=; b=fe0pDswP7oIdlPfzvCpg9dHXxCh7UwMr2JOYfpCUZqfvtF3qhTUY/ja0 yHnBGaFa4sRv7smdGRl/erRkTJdahSC84FZJtkZpjKJQHFjjrpe624RAV zMKnkSclVVfUzEyH1z9BXGlcOB28IaA8QZKIlek9bf9i8eSUMEwml8W2J 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGwZt1CtJV2b/2dsb2JhbABEwCMWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQiICAy/LwSMP4NgYQOmRYJygWUkGA X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147489782" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Nov 2012 08:18:03 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAT8I3n5030785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 08:18:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.204]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 02:18:02 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Charles Eckel (eckelcu)" , Brian Rosen Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAM5VyAACmYlgAAD0ApcA== Date: Thu, 29 Nov 2012 08:18:02 +0000 Message-ID: References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <52376CF1-7A3A-4C21-9D77-9B45CFB06122@brianrosen.net> <92B7E61ADAC1BB4F941F943788C08828046CC1B9@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CC1B9@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.108.185] 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: Thu, 29 Nov 2012 08:18:04 -0000 |SRCs that modify an encrypted media stream (e.g. transcode or mix) "modify an encrypted media stream" looks a bit vague. My suggestion: SRCs that decrypt an encrypted CS media stream and re-encrypt it when=20 sending it to the SRS SHOULD use a different key for the RS media strea= m=20 than what is used for the CS media stream, to ensure that it isn't poss= ible for someone who has the key for the CS media stream to access the recor= ded data they aren't authorized to access. Muthu =20 |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf O= f Charles Eckel (eckelcu) |Sent: Thursday, November 29, 2012 6:39 AM |To: Brian Rosen |Cc: siprec@ietf.org |Subject: Re: [siprec] security considerations for protocol draft | |How about if we say: | | SRCs that modify an encrypted media stream (e.g. transcode or mix)= when relaying | it from a CS to an RS SHOULD negotiate a different security key th= an the | one used in the CS, to ensure that it is not possible for someone = who has the key from | the CS to access data they should not be able to access. | |Does that cover it clearly? | |Thanks, |Charles | |> -----Original Message----- |> From: Brian Rosen [mailto:br@brianrosen.net] |> Sent: Tuesday, November 27, 2012 2:59 PM |> To: Charles Eckel (eckelcu) |> Cc: siprec@ietf.org |> Subject: Re: [siprec] security considerations for protocol draft |> |> Transcoding, not so sure. Mixing, you could observe that if SRC used A'= s key |> to encode A+B then, in theory, A could observe A+B and decode it. in |> practice, if SRC is mixing A and B, then A can hear/see/type B anyway. |> |> Maybe get rid of the MUST and just say that re-use of keys should consid= er if |> it's possible for the other end, who has the original key, to get data t= hey |> shouldn't be able to get. |> |> Brian |> |> On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) |> wrote: |> |> > Hi, |> > |> > I am in the process of updating some sections of the protocol draft pe= r the |> conclusions reached at IETF 85. In working on the security consideration= s, 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 carryin= g |> > challenges and credentials. |> > |> > At the transport level, the recording session uses TLS authenticatio= n |> > to validate the authenticity of the SRC and SRS. The SRC and SRS |> > MUST implement TLS mutual authentication for establishing the |> > 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 digest |> authentication? It seems to me the paragraph on digest authentication |> should be removed. Does anyone disagree? |> > |> > Second, section 12.2, RTP handling, currently ends as follows: |> > |> > For SRCs that perform transcoding or mixing of media before sending |> > to the SRS, the SRC MUST negotiate a different security key than the |> > one being used in the CS, to ensure that the security in the CS is |> > not compromised by the SRC when reusing the same security key. |> > |> > During the SIPREC session at IETF 85, there was discussion as to why i= t is |> necessary to negotiate a different security key. I am not sure what else= to |> put here as justification for this requirement. Any suggestions? If not,= I will |> leave it as is. |> > |> > Cheers, |> > Charles |> > _______________________________________________ |> > 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 br@brianrosen.net Thu Nov 29 06:01: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 2282121F8942 for ; Thu, 29 Nov 2012 06:01:14 -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 lWIjrra4+gTN for ; Thu, 29 Nov 2012 06:01:11 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43521F8894 for ; Thu, 29 Nov 2012 06:01:11 -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=rD8ZvDhrW3g9YiLGOQQDCKppihW9r3ja7wVdZzm7IGA=; b=SVUcm48afY+jlVvdn6L2tpbROUkuAAidw5a81uAM4RZlZ9objUvkN5ye5rqrLsZo+wXXnmG5xY5kcCS0BBx9htqOQuRiGzARMZ+xyy8Mxd/qOoTXvolwEtVyXDDqs+aY; Received: from neustargw.va.neustar.com ([209.173.53.233]:44624 helo=[192.168.133.99]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Te4fu-0003Hp-AR; Thu, 29 Nov 2012 09:01:10 -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: Date: Thu, 29 Nov 2012 09:01:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <871FF04E-2A56-461A-91C4-02B4B6C9BB91@brianrosen.net> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <52376CF1-7A3A-4C21-9D77-9B45CFB06122@brianrosen.net> <92B7E61ADAC1BB4F941F943788C08828046CC1B9@xmb-aln-x08.cisco.com> To: Muthu Arul Mozhi Perumal (mperumal) 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] 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: Thu, 29 Nov 2012 14:01:14 -0000 WFM either way Brian On Nov 29, 2012, at 3:18 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: > |SRCs that modify an encrypted media stream (e.g. transcode or mix) >=20 > "modify an encrypted media stream" looks a bit vague. My suggestion: >=20 > SRCs that decrypt an encrypted CS media stream and re-encrypt it = when=20 > sending it to the SRS SHOULD use a different key for the RS media = stream=20 > than what is used for the CS media stream, to ensure that it isn't = possible > for someone who has the key for the CS media stream to access the = recorded > data they aren't authorized to access. >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Charles Eckel (eckelcu) > |Sent: Thursday, November 29, 2012 6:39 AM > |To: Brian Rosen > |Cc: siprec@ietf.org > |Subject: Re: [siprec] security considerations for protocol draft > | > |How about if we say: > | > | SRCs that modify an encrypted media stream (e.g. transcode or = mix) when relaying > | it from a CS to an RS SHOULD negotiate a different security = key than the > | one used in the CS, to ensure that it is not possible for = someone who has the key from > | the CS to access data they should not be able to access. > | > |Does that cover it clearly? > | > |Thanks, > |Charles > | > |> -----Original Message----- > |> From: Brian Rosen [mailto:br@brianrosen.net] > |> Sent: Tuesday, November 27, 2012 2:59 PM > |> To: Charles Eckel (eckelcu) > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] security considerations for protocol draft > |> > |> Transcoding, not so sure. Mixing, you could observe that if SRC = used A's key > |> to encode A+B then, in theory, A could observe A+B and decode it. = in > |> practice, if SRC is mixing A and B, then A can hear/see/type B = anyway. > |> > |> Maybe get rid of the MUST and just say that re-use of keys should = consider if > |> it's possible for the other end, who has the original key, to get = data they > |> shouldn't be able to get. > |> > |> Brian > |> > |> On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) = > |> wrote: > |> > |> > Hi, > |> > > |> > I am in the process of updating some sections of the protocol = draft 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 and = SRS > |> > MUST implement TLS mutual authentication for establishing the > |> > 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 = digest > |> authentication? It seems to me the paragraph on digest = authentication > |> should be removed. Does anyone disagree? > |> > > |> > Second, section 12.2, RTP handling, currently ends as follows: > |> > > |> > For SRCs that perform transcoding or mixing of media before = sending > |> > to the SRS, the SRC MUST negotiate a different security key = than the > |> > one being used in the CS, to ensure that the security in the CS = is > |> > not compromised by the SRC when reusing the same security key. > |> > > |> > During the SIPREC session at IETF 85, there was discussion as to = why it is > |> necessary to negotiate a different security key. I am not sure what = else to > |> put here as justification for this requirement. Any suggestions? If = not, I will > |> leave it as is. > |> > > |> > Cheers, > |> > Charles > |> > _______________________________________________ > |> > 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 Thu Nov 29 08:42: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 8469921F8A9A for ; Thu, 29 Nov 2012 08:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[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 Xel5YEPZA+S2 for ; Thu, 29 Nov 2012 08:42:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB3E121F89EE for ; Thu, 29 Nov 2012 08:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1349; q=dns/txt; s=iport; t=1354207330; x=1355416930; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=VROQ0F7dyn5KRPRJXBSL2RZP/Udrl4jQFkELNL88hxA=; b=IiV0dHD9lMtGGLsTjWmjlgWG8xt+eAfUYK8jMZ7SL7aSgpMNJQWy2Drd XSDow5vlJ5DuvU2ilQqrf19jHDoqKok9RY8y1hyc0B6KKvbww4vxwz7ve GL9LzbwUuccuGJpd1vKBn0PfeA08+sqlwlpKn7WICJSmjv19zUR82Fw8U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKQt1CtJXG9/2dsb2JhbABEwBkWc4IeAQEBAwEBAQE3NBANAQgSEBQ3CxcOAgQBEgiIAgYMvxiMQINgYQOXHY8ognKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147611093" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 29 Nov 2012 16:42:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qATGgAUD002232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:42:10 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:42:10 -0600 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: AQHNzlB5VcvFa8jSy0ivJINJOLP44w== Date: Thu, 29 Nov 2012 16:42:09 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013710D9@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.76.57] 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: Thu, 29 Nov 2012 16:42:13 -0000 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. One question: In section 5 there is this statement at the end "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. Regards, Ram > On 27/11/12 7:18 PM, "Hutton, Andrew" > wrote: >Hi, > >As discussed during IETF85 and following the recent update we would like >to start a working group last call on draft-ietf-siprec-architecture. > >This will be a two week WGLC ending on the 12th of December 2012. > >Please review the draft and provide comments as soon as possible. > >The latest version of the draft can be found at: >http://tools.ietf.org/html/draft-ietf-siprec-architecture-07. > >Regards >Andy (SIPREC Co-Chair). > > > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Thu Nov 29 08:47:01 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 70D9A21F8471 for ; Thu, 29 Nov 2012 08:47:01 -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 Fxu75ZqED2ac for ; Thu, 29 Nov 2012 08:47:00 -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 DFEC021F846F for ; Thu, 29 Nov 2012 08:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5857; q=dns/txt; s=iport; t=1354207620; x=1355417220; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NdpEqkksb5fVVzOH2qpPxoi4KkaeM0jwSgdVqviujN4=; b=BP8faBh6GLqeRyxv5zYDOoltzA6SCry0Gq8/i9p15spUgcl+9NBsSSGQ Rae0YKHGd5Kdy2N9zx1bciVPKB0E0Bm6M8y+WZTKdOwXmeC7H8vP4b03E C1lXQ9neHSOMSaYrF/7xhiXWFh5G454mpmyihaM55SzlX++wEz4FRi8OE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEaRt1CtJXG8/2dsb2JhbABEDoNWvDUWc4IeAQEBAwEBAQE3NBAHBgEIDgMEAQEBChQJKAYLFAkIAgQBEggBh3UDCQYHBbU7DYlUi1dpG4NFYQOULI0JA4UNgjU9gWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147608209" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 16:46:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qATGkqQs029930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:46:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:46:52 -0600 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indicator consensus? Thread-Index: AQHNzlEho0NO8bnKMkSqRzD7twg07A== Date: Thu, 29 Nov 2012 16:46:51 +0000 Message-ID: In-Reply-To: <50B51D75.8020709@alum.mit.edu> 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.76.57] Content-Type: text/plain; charset="us-ascii" Content-ID: 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, 29 Nov 2012 16:47:01 -0000 I am ok with this approach and the recommendation. Ram > On 28/11/12 1:37 AM, "Paul Kyzivat" wrote: >I'm ok with this. > >While I think there should be no *expectation* of interoperability with >different version numbers, I also think there is nothing *forbidding* an >SRS from supporting SRCs using different versions. > > Thanks, > Paul > >On 11/27/12 2:48 PM, Brian Rosen wrote: >> Seems reasonable to me. >> >> Brian >> >> On Nov 27, 2012, at 2:30 PM, Mary Barnes > > wrote: >> >>> Given your's and Brian's answers, I think some text should be added >>> around the description of the version number indicating that the >>> intent is to minimize interop problems -i.e., you'll know that the >>> entity you intend to interact with is of the same version number and >>> that there is no expectation for interop between different version >>> numbers and there is no intention to ensure backwards compatibility >>> with previous versions. >>> >>> Thanks, >>> Mary. >>> >>> >>> On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew >>> >> > wrote: >>> >>> Hi Mary, >>> >>> See below. >>> >>> Regards >>> Andy >>> >>> > -----Original Message----- >>> > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >>> ] >>> > Sent: 27 November 2012 19:08 >>> > To: Hutton, Andrew >>> > Cc: siprec@ietf.org >>> > Subject: Re: [siprec] Metadata version indicator consensus? >>> > >>> > I would still like to understand the intent of the version >>>number as >>> > I've asked in several of the threads on this topic. If folks can >>> > answer these questions so it's clear what the intended usage and >>> > meaning of that version number is, that would address my primary >>> > concerns: >>> > 1) If the version number is not the same, then is there no >>> intention >>> > to try to interop? ["Yes" was the impression I got from what >>> Hadriel >>> > said but the subsequent discussion didn't seem to agree with >>>that] >>> >>> [AndyH] It was my impression from the discussion that if the >>> version number is different then there is no intention to interop. >>> >>> >>> > 2) Is the expectation for implementations to be backwards >>> compatible - >>> > e.g., version 1.1 MUST be able to support 1.0 implementations? >>> [This >>> > is my biggest concern. If it's "Yes", then I think there is >>>then a >>> > burden added when any changes are made to the schema to minimize >>>the >>> > complexity for implementors.] >>> > >>> >>> [AndyH] - No I don't believe there is this expectation. The >>> version number would only be incremented if there is a backwards >>> compatibility issue so I would hope that such changes are rare. >>> Having said that they are more likely to occur whilst the draft is >>> immature which I don't believe is a problem. >>> >>> >>> >>> >>> > Mary. >>> > >>> > >>> > On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew >>> > >> > wrote: >>> > 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 rmohanr@cisco.com Thu Nov 29 08:51:09 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 A3A8A21F8AD6 for ; Thu, 29 Nov 2012 08:51:07 -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 x9xVW8hAzWKo for ; Thu, 29 Nov 2012 08:51:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6622921F8AEF for ; Thu, 29 Nov 2012 08:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4508; q=dns/txt; s=iport; t=1354207866; x=1355417466; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aEv+GutqP/ErTDOis8YM2aowoOArNZkRZj7IFxZYGdA=; b=AB2ZahWtB8IhzUqngrnzV9uvCTbD7yZgk6uYM8SWsp3T8HsZ0fM2RLOx yzueuezWmI3iWetQClxKufBbZ9GpsVAj0k6aSYMRj7NMmeXeHLAvl/wMw HTQ3LCP05Q8fnPuC2OI0bnQouEDt4fd1/KXKXWBc6Tbyf3NKLkcvQuBER Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEaRt1CtJXG8/2dsb2JhbABEwBkWc4IeAQEBAwEBAQE3NAsFBwYBCBEEAQEBChQJLgsUCQgCBAENBQiIAgYMvxgEjECDYGEDpkWCcoFlJBg X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147614651" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 29 Nov 2012 16:51:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qATGp5vo001528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:51:05 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:51:05 -0600 From: "Ram Mohan R (rmohanr)" To: "Muthu Arul Mozhi Perumal (mperumal)" , "Charles Eckel (eckelcu)" , Brian Rosen Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: AQHNzlG4Hyi8RDydWUmv63Cxps/5Aw== Date: Thu, 29 Nov 2012 16:51:04 +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: [10.65.76.57] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Thu, 29 Nov 2012 16:51:09 -0000 Looks good to me. Ram > On 29/11/12 1:48 PM, "Muthu Arul Mozhi Perumal (mperumal)" > wrote: >|SRCs that modify an encrypted media stream (e.g. transcode or mix) > >"modify an encrypted media stream" looks a bit vague. My suggestion: > > SRCs that decrypt an encrypted CS media stream and re-encrypt it when > sending it to the SRS SHOULD use a different key for the RS media >stream=20 > than what is used for the CS media stream, to ensure that it isn't >possible > for someone who has the key for the CS media stream to access the >recorded > data they aren't authorized to access. > >Muthu > =20 >|-----Original Message----- >|From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Charles Eckel (eckelcu) >|Sent: Thursday, November 29, 2012 6:39 AM >|To: Brian Rosen >|Cc: siprec@ietf.org >|Subject: Re: [siprec] security considerations for protocol draft >| >|How about if we say: >| >| SRCs that modify an encrypted media stream (e.g. transcode or >mix) when relaying >| it from a CS to an RS SHOULD negotiate a different security key >than the >| one used in the CS, to ensure that it is not possible for >someone who has the key from >| the CS to access data they should not be able to access. >| >|Does that cover it clearly? >| >|Thanks, >|Charles >| >|> -----Original Message----- >|> From: Brian Rosen [mailto:br@brianrosen.net] >|> Sent: Tuesday, November 27, 2012 2:59 PM >|> To: Charles Eckel (eckelcu) >|> Cc: siprec@ietf.org >|> Subject: Re: [siprec] security considerations for protocol draft >|> >|> Transcoding, not so sure. Mixing, you could observe that if SRC used >A's key >|> to encode A+B then, in theory, A could observe A+B and decode it. in >|> practice, if SRC is mixing A and B, then A can hear/see/type B anyway. >|> >|> Maybe get rid of the MUST and just say that re-use of keys should >consider if >|> it's possible for the other end, who has the original key, to get data >they >|> shouldn't be able to get. >|> >|> Brian >|> >|> On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) > >|> wrote: >|> >|> > Hi, >|> > >|> > I am in the process of updating some sections of the protocol draft >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 and SRS >|> > MUST implement TLS mutual authentication for establishing the >|> > 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 digest >|> authentication? It seems to me the paragraph on digest authentication >|> should be removed. Does anyone disagree? >|> > >|> > Second, section 12.2, RTP handling, currently ends as follows: >|> > >|> > For SRCs that perform transcoding or mixing of media before sending >|> > to the SRS, the SRC MUST negotiate a different security key than >the >|> > one being used in the CS, to ensure that the security in the CS is >|> > not compromised by the SRC when reusing the same security key. >|> > >|> > During the SIPREC session at IETF 85, there was discussion as to why >it is >|> necessary to negotiate a different security key. I am not sure what >else to >|> put here as justification for this requirement. Any suggestions? If >not, I will >|> leave it as is. >|> > >|> > Cheers, >|> > Charles >|> > _______________________________________________ >|> > 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 eckelcu@cisco.com Fri Nov 30 09:06: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 240E621F8B8F for ; Fri, 30 Nov 2012 09:06:08 -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 OdfZdQE0KCmS for ; Fri, 30 Nov 2012 09:06:07 -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 0992621F8B89 for ; Fri, 30 Nov 2012 09:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5178; q=dns/txt; s=iport; t=1354295167; x=1355504767; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V7qfJKRYQ1i0FwSo96SOVtsUvE7wLOb/1XsnCJnFv8c=; b=nGmuxobhvgdoZQHZJpeq6y6GR3e4kuFLJjkpPeV0HjgDmf9jwkZg4KSX hEe0mYgx7A2Mu+1t41kikf7iSv57VYPdLLXHiCuDkiGtZ/c4XWlMhVPJc BBUptcctbozS7KT/3JW0YVzuXmhRTFQBTEvcZBwflMFTisWItg3JJjes9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAADnuFCtJXG+/2dsb2JhbABEwA0Wc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQBDQUIiAcBDL96BIxAg2BhA6ZEgnKBZSQY X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="148039199" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 30 Nov 2012 17:06:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAUH660e002003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 17:06:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 11:06:06 -0600 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Muthu Arul Mozhi Perumal (mperumal)" , Brian Rosen Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAM5VyAACmYlgAAD0ApcAAe41MAACYkqmA= Date: Fri, 30 Nov 2012 17:06:06 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CDF75@xmb-aln-x08.cisco.com> References: In-Reply-To: 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: Fri, 30 Nov 2012 17:06:08 -0000 I will use the improved wording suggested by Muthu. Thanks everyone. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Thursday, November 29, 2012 8:51 AM > To: Muthu Arul Mozhi Perumal (mperumal); Charles Eckel (eckelcu); Brian > Rosen > Cc: siprec@ietf.org > Subject: Re: [siprec] security considerations for protocol draft >=20 > Looks good to me. >=20 > Ram >=20 > > On 29/11/12 1:48 PM, "Muthu Arul Mozhi Perumal (mperumal)" > > wrote: >=20 > >|SRCs that modify an encrypted media stream (e.g. transcode or mix) > > > >"modify an encrypted media stream" looks a bit vague. My suggestion: > > > > SRCs that decrypt an encrypted CS media stream and re-encrypt it whe= n > > sending it to the SRS SHOULD use a different key for the RS media > >stream > > than what is used for the CS media stream, to ensure that it isn't > >possible > > for someone who has the key for the CS media stream to access the > >recorded > > data they aren't authorized to access. > > > >Muthu > > > >|-----Original Message----- > >|From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Charles Eckel (eckelcu) > >|Sent: Thursday, November 29, 2012 6:39 AM > >|To: Brian Rosen > >|Cc: siprec@ietf.org > >|Subject: Re: [siprec] security considerations for protocol draft > >| > >|How about if we say: > >| > >| SRCs that modify an encrypted media stream (e.g. transcode or > >mix) when relaying > >| it from a CS to an RS SHOULD negotiate a different security key > >than the > >| one used in the CS, to ensure that it is not possible for > >someone who has the key from > >| the CS to access data they should not be able to access. > >| > >|Does that cover it clearly? > >| > >|Thanks, > >|Charles > >| > >|> -----Original Message----- > >|> From: Brian Rosen [mailto:br@brianrosen.net] > >|> Sent: Tuesday, November 27, 2012 2:59 PM > >|> To: Charles Eckel (eckelcu) > >|> Cc: siprec@ietf.org > >|> Subject: Re: [siprec] security considerations for protocol draft > >|> > >|> Transcoding, not so sure. Mixing, you could observe that if SRC used > >A's key > >|> to encode A+B then, in theory, A could observe A+B and decode it. in > >|> practice, if SRC is mixing A and B, then A can hear/see/type B anyway= . > >|> > >|> Maybe get rid of the MUST and just say that re-use of keys should > >consider if > >|> it's possible for the other end, who has the original key, to get dat= a > >they > >|> shouldn't be able to get. > >|> > >|> Brian > >|> > >|> On Nov 27, 2012, at 5:49 PM, Charles Eckel (eckelcu) > > > >|> wrote: > >|> > >|> > Hi, > >|> > > >|> > I am in the process of updating some sections of the protocol draft > >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 4= 01 > >|> > 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 and SRS > >|> > MUST implement TLS mutual authentication for establishing the > >|> > 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 dige= st > >|> authentication? It seems to me the paragraph on digest authentication > >|> should be removed. Does anyone disagree? > >|> > > >|> > Second, section 12.2, RTP handling, currently ends as follows: > >|> > > >|> > For SRCs that perform transcoding or mixing of media before sendi= ng > >|> > to the SRS, the SRC MUST negotiate a different security key than > >the > >|> > one being used in the CS, to ensure that the security in the CS i= s > >|> > not compromised by the SRC when reusing the same security key. > >|> > > >|> > During the SIPREC session at IETF 85, there was discussion as to wh= y > >it is > >|> necessary to negotiate a different security key. I am not sure what > >else to > >|> put here as justification for this requirement. Any suggestions? If > >not, I will > >|> leave it as is. > >|> > > >|> > Cheers, > >|> > Charles > >|> > _______________________________________________ > >|> > 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 > > >=20 From eckelcu@cisco.com Fri Nov 30 09:07: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 804C821F8717 for ; Fri, 30 Nov 2012 09:07:46 -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 llgtLsGSccMT for ; Fri, 30 Nov 2012 09:07:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A421F888D for ; Fri, 30 Nov 2012 09:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1354295266; x=1355504866; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yu4iT/M3vKgQHoutOyHt3RXPkrnbfYcOxcZkKCWKy3k=; b=AMOk9aMVHHmA0sznHrlFZ7qSI8gg9LkIAZFVryD6VuU2nkmZuhRRP07F WeMEsEBCHIigf/aoqyUuQEq47qwPXe6Awljb9mZRqZT6W+Qy9AZT/ioVk m4SSsDi0lhAWDOmHsquqZomtlFqp6oPNARfC7hv2CwQA9LHwcJx3FQY9F U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJvmuFCtJXG//2dsb2JhbABEDr9/FnOCHgEBAQQBAQE3NBcEAgEIDgMEAQEBChQJBycLFAkIAQEEARIIiAcBDL99BIxAg2BhA6ZEgjU9gWUkGA X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="148042787" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 30 Nov 2012 17:07:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAUH7jLm017522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 17:07:45 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 11:07:44 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAz4PeAAFcHzOA= Date: Fri, 30 Nov 2012 17:07:44 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CDF85@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <50B64B4D.40709@alum.mit.edu> In-Reply-To: <50B64B4D.40709@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 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: Fri, 30 Nov 2012 17:07:46 -0000 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 >=20 > On 11/27/12 5:49 PM, Charles Eckel (eckelcu) wrote: > > Hi, > > > > I am in the process of updating some sections of the protocol draft 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 request= s > > that are based on HTTP authentication. The mechanism relies on 401 > > and 407 SIP responses as well as other SIP header fields for carryi= ng > > challenges and credentials. > > > > At the transport level, the recording session uses TLS authenticati= on > > to validate the authenticity of the SRC and SRS. The SRC and SRS > > MUST implement TLS mutual authentication for establishing the > > 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 digest > authentication? It seems to me the paragraph on digest authentication > should be removed. Does anyone disagree? >=20 > TLS authentication is hop by hop. Digest authentication is e2e. >=20 > *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. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Fri Nov 30 09:12:57 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 B89A921F89FE for ; Fri, 30 Nov 2012 09:12:57 -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 o9R1ii0U7Zna for ; Fri, 30 Nov 2012 09:12:57 -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 05B0421F88C7 for ; Fri, 30 Nov 2012 09:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2182; q=dns/txt; s=iport; t=1354295577; x=1355505177; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8Oa+FWarhFEYYd2omzxd7zNfRaGZGzLe8ILeewoduJ0=; b=gAEjzNI+RejfgW3cuu4CappytOAWP0m8G/2Ho4kZvhYeoQLwVu6PtrGy wsuj1vyCnscPn7VO1c4mWJI+JoOfH78WvM0gIkZpovw3OTkh+Fgdkd3nt j4IPUFqLrzk/kBw4T5nzl+YKOFB8Q1CTaA3BnlYSSNkPyEb114f2cU6eP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALfouFCtJXHB/2dsb2JhbABEwA0Wc4IeAQEBAwEBAQE3NBcEAgEIEQEDAQEBChQJBycLFAMGCAEBBAESCIgCBQEMwAOMQINgYQOXHI8ognKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="148075314" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 30 Nov 2012 17:12:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAUHCuk8010150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 17:12:56 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 11:12:56 -0600 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: Ac3Mpe64dh/UOUN3S2CAgVO5Inr5FwB3NUaAACavfOA= Date: Fri, 30 Nov 2012 17:12:55 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CDFB1@xmb-aln-x08.cisco.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: 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] 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: Fri, 30 Nov 2012 17:12:57 -0000 Please see inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Ram Mohan R (rmohanr) > Sent: Thursday, November 29, 2012 8:42 AM > To: Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture >=20 > I took a look at the latest revision. The document looks very good and > ready to go. One minor nits. >=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 > 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 retrieva= l > methods when it is mentioned earlier in the document that it is out of > scope. I see no harm and some value in pointing this out. I agree retrieval is lef= t out of scope, but this is a non-normative should, and any details of how = to ensure compliance in this area are appropriately omitted. Just my 2 cents. Cheers, Charles =20 >=20 > Regards, > Ram >=20 > > On 27/11/12 7:18 PM, "Hutton, Andrew" > > wrote: >=20 > >Hi, > > > >As discussed during IETF85 and following the recent update we would like > >to start a working group last call on draft-ietf-siprec-architecture. > > > >This will be a two week WGLC ending on the 12th of December 2012. > > > >Please review the draft and provide comments as soon as possible. > > > >The latest version of the draft can be found at: > >http://tools.ietf.org/html/draft-ietf-siprec-architecture-07. > > > >Regards > >Andy (SIPREC Co-Chair). > > > > > > > >_______________________________________________ > >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 eckelcu@cisco.com Fri Nov 30 10:02:05 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 6C46D21F8983 for ; Fri, 30 Nov 2012 10:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 oPZo2y3+Kf71 for ; Fri, 30 Nov 2012 10:02:04 -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 9332921F897A for ; Fri, 30 Nov 2012 10:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3031; q=dns/txt; s=iport; t=1354298524; x=1355508124; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=E+CAjiEKuQY16gf6HNuUIb/ghEMDOS1jxo7vwj2YaSc=; b=KAhE8TSHbHwgo+A+rBps+pNdJkcESXatqx9vDP3m1kmD/OK5/UAomqtO VMNJU51WZw7qt0y19xgpLkep9dG4J3H44cvKsobXW0FTiluOFx2j6uJju o0Kufg4faNMLEVOb5Fxo3CCfuAISf42XaM1dzYci5susGycPVR32ZmO7H g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJTzuFCtJV2b/2dsb2JhbABEDr9xFnOCHgEBAQQBAQE3NBcEAgEIDgMEAQEBChQJBycLFAkIAQEEARIIiAcBDMAFBIxAg2BhA5JOk3aCNT2BZSQY X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="145062604" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 30 Nov 2012 18:02:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAUI24tW023191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 18:02:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 12:02:03 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAz4PeAAFcHzOAAAa+9MA== Date: Fri, 30 Nov 2012 18:02:03 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CE010@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828046CA661@xmb-aln-x08.cisco.com> <50B64B4D.40709@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828046CDF85@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CDF85@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] 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: Fri, 30 Nov 2012 18:02:05 -0000 Thinking about this more, I'm still a bit dubious of the value of this. For the general case in which the SRC is initiating the RS, the SRS can ch= allenge the INVITE from the SRC with a 401 in order to force the SRC to aut= henticate itself to the SRS. However, we state later on that is really more= important for the SRS to authentication itself to the SRC. The Digest auth= entication mechanism can be used by the SRC for this in the case of SRS ini= tiated RSs, but not for the general case. Am I missing something again? 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 >=20 > Good point. Thanks for clarifying. >=20 > Cheers, > Charles >=20 > > -----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 draft p= er > the > > conclusions reached at IETF 85. In working on the security consideratio= ns, I > > ran into a couple issues. > > > > > > First, section 12.1 Authentication and Authorization, reads as follow= s: > > > > > > The recording session reuses the SIP mechanism to challenge reque= sts > > > that are based on HTTP authentication. The mechanism relies on 4= 01 > > > and 407 SIP responses as well as other SIP header fields for carr= ying > > > challenges and credentials. > > > > > > At the transport level, the recording session uses TLS authentica= tion > > > to validate the authenticity of the SRC and SRS. The SRC and SRS > > > MUST implement TLS mutual authentication for establishing the > > > 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 digest > > 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 Fri Nov 30 10:19: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 038AF21F8A92 for ; Fri, 30 Nov 2012 10:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Kb-fk-09ba2f for ; Fri, 30 Nov 2012 10:19:23 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 454D421F865C for ; Fri, 30 Nov 2012 10:19:23 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta01.westchester.pa.mail.comcast.net with comcast id VsPA1k0060cZkys51uKN78; Fri, 30 Nov 2012 18:19:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id VuKN1k00U3ZTu2S3WuKNBD; Fri, 30 Nov 2012 18:19:22 +0000 Message-ID: <50B8F8A9.1080407@alum.mit.edu> Date: Fri, 30 Nov 2012 13:19:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CE010@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=1354299562; bh=gQd90+oTIkovYsEWljPkGkDvxChD9JSx/Q+0/UqBzJ0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cfKzvQbt9u8M2Kx1yp3o3Z0tSuoddpNZECvY+lJo/X1hX0wUG6pvY55XAGKIiTPdl fHVY2y+U9184s0JhbW2rBXYTuWGTkgnI+EnRGOoyw+03XaDvDEftipfy4egROzzYFu nbx3PU8ymCKZdkqtemjdh07L1xRpiio2T+kunHeWMv4iB1kXv7yJUceTFTO5NgThi1 Rhzzik9rXQ/p3awRzxVZnF56lhnT/KzoRHvyoMrj82OayrigSydgYA61bDgTR7vD7f hnH0ZMOSh3PkKhJXmuxZsVw2swvrw28jbQeHxyibxL5QmYpYO93ynVem9hTLctk3oj jNHz/iql541wg== 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: Fri, 30 Nov 2012 18:19:24 -0000 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 this. > 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 really 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 of SRS initiated RSs, but not for the general case. Am I missing something again? 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 draft 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 and SRS >>>> MUST implement TLS mutual authentication for establishing the >>>> 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 digest >>> 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 eckelcu@cisco.com Fri Nov 30 11:32:10 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 8D30E21F888F for ; Fri, 30 Nov 2012 11:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 k1+a+1vZrRfV for ; Fri, 30 Nov 2012 11:32:08 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 984AC21F8675 for ; Fri, 30 Nov 2012 11:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4428; q=dns/txt; s=iport; t=1354303927; x=1355513527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dsXPt978qq7BtJUQTXvyptctKx2x1HYWrCbqvou3aS4=; b=jkIQRgBdhfzWH6tdiqR00mu9c3WFaE27B80k/YIspiytsoDa8LjtkYsB UzQZZYBpyWMu55NY0xhoM/FFGck4qED8yXnjEMlxVoHD9YdOM/9CAg8b1 hdnTmXoVmteyBOQUoNivenIa3GevTgnMvDTxD7Ol5kcf5KsXxyiMlsQYq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOUIuVCtJXHA/2dsb2JhbABEDr9xFnOCHgEBAQMBAQEBNzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgBAQQOBQiIAgUBDL94BIxAg2BhA5JOk3aCNT2BZSQY X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="148093296" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 30 Nov 2012 19:32:07 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAUJW6Y0011897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 19:32:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 13:32:06 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat Thread-Topic: [siprec] security considerations for protocol draft Thread-Index: Ac3M8Xz54e5AfWAIT8GHI0VbZaVo9wAz4PeAAFcHzOAAAa+9MAANaNmAAAolb6A= Date: Fri, 30 Nov 2012 19:32:06 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CE0CC@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> In-Reply-To: <50B8F8A9.1080407@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: Fri, 30 Nov 2012 19:32:10 -0000 I am leaning back toward my original proposal, of dropping the discussion a= bout digest authentication entirely and relying on TLS. For cases in which = there is an intermediary, transitive trust comes into play. If an SRS or SR= C wants to use digest authentication, it can, but we do not need to say any= thing specific about it in SIPREC. 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 >=20 > 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 this. > > For the general case in which the SRC is initiating the RS, the SRS ca= n > 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 really= 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 of S= RS > initiated RSs, but not for the general case. Am I missing something again= ? >=20 > 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.) >=20 > 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= . >=20 > Is it plausible that we require a direct connection without > intermediaries? (Probably not.) >=20 > I wish this had come up sooner, rather than now. :-( >=20 > Thanks, > Paul >=20 > > 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 draft = 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 follo= ws: > >>>> > >>>> 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 ca= rrying > >>>> challenges and credentials. > >>>> > >>>> At the transport level, the recording session uses TLS authenti= cation > >>>> to validate the authenticity of the SRC and SRS. The SRC and S= RS > >>>> MUST implement TLS mutual authentication for establishing the > >>>> 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 diges= t > >>> 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 Fri Nov 30 12:22:47 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 3343821F85FA for ; Fri, 30 Nov 2012 12:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, 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 60Tqbhdnnz5u for ; Fri, 30 Nov 2012 12:22:46 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4209621F8543 for ; Fri, 30 Nov 2012 12:22:45 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id Vn0N1k00B0mv7h053wNlao; Fri, 30 Nov 2012 20:22:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id VwNl1k00M3ZTu2S3XwNlGt; Fri, 30 Nov 2012 20:22:45 +0000 Message-ID: <50B91594.1060909@alum.mit.edu> Date: Fri, 30 Nov 2012 15:22:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CE0CC@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=1354306965; bh=q7hAkSUAqBpm/IRzgOouC7a+emL/seduzGcMwUvB4tU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TYrk+vE6hpT+U7360m/ZS5i4+FgbQWBe+iEwPpeFCfK/hmCNxoDK6Xu6W8zTh37JT 7XxRx5yZGP+CMz8bth7OzfglXPaKE0CIDFow8olqixbzJVl6krg90n7pbzjGvRnqDo FPdLUGeBp8gwXOqWhVI8fuz0TmBE+0c9J0bcA7GOBjyWfOrOZxNZ81KD2YXJ5InTBt i3DC3sXLtJ7jYXKUfoq534IWvPPdeYutDvAt2nP7cbgmfpnuRTtWgX+hwk8j7EWPj9 v+UqkR1lblQcqUsH717dA5+dW+ytF4MhSN/FG7Gq0uICvUGhuTaIefw3e4n4UkXcjv FaeunX1FJJYDw== 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: Fri, 30 Nov 2012 20:22:47 -0000 On 11/30/12 2:32 PM, Charles Eckel (eckelcu) wrote: > I am leaning back toward my original proposal, of dropping the discussion about digest authentication entirely and relying on TLS. For cases in which 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. 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. 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.) I expect if we don't have something reasonably robust to recommend then we will have trouble with security review. Thanks, Paul > 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 this. >>> 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 really 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 of SRS >> initiated RSs, but not for the general case. Am I missing something again? >> >> 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 draft 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 and SRS >>>>>> MUST implement TLS mutual authentication for establishing the >>>>>> 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 digest >>>>> 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 >>> > >