From nobody Fri Sep 19 01:13:36 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61421A0011 for ; Fri, 19 Sep 2014 01:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a86ysuPXWoNj for ; Fri, 19 Sep 2014 01:13:32 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 84F4A1A0010 for ; Fri, 19 Sep 2014 01:13:32 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 2669A23F050D for ; Fri, 19 Sep 2014 10:13:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 10:13:30 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF91 SIPREC Meeting Thread-Index: Ac/T4Zhd26Sy94gZRGe/WNqN1yRzTw== Date: Fri, 19 Sep 2014 08:13:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5A7543@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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E5A7543MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/97BEU_CnM5vBbwmWOuI038UbJfA Subject: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 19 Sep 2014 08:13:34 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5A7543MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The deadline for requesting an IETF91 meeting slot is next week (26th of Se= pt). Please let the chairs know if you believe a SIPREC meeting at IETF91 is nee= ded and why and whether you have anything to present. Given that there has no list discussion I am thinking that maybe there is n= o need for a SIPREC meeting this time. Regards Andy (SIPREC Co-Chair). --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5A7543MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
The deadline for requesting an IETF91 meeting slot is next week (26th = of Sept).
 
Please let the chairs know if you believe a SIPREC meeting at IETF91 i= s needed and why and whether you have anything to present.
 
Given that there has no list discussion I am thinking that maybe there= is no need for a SIPREC meeting this time.
 
Regards
Andy (SIPREC Co-Chair).
 
 
--_000_9F33F40F6F2CD847824537F3C4E37DDF1E5A7543MCHP04MSXglobal_-- From nobody Fri Sep 19 09:44:27 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613B81A0331 for ; Fri, 19 Sep 2014 09:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrxu8RhLMoEr for ; Fri, 19 Sep 2014 09:44:25 -0700 (PDT) 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 00A4F1A0326 for ; Fri, 19 Sep 2014 09:44:23 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta12.westchester.pa.mail.comcast.net with comcast id t4JB1o0020SCNGk5C4kPmc; Fri, 19 Sep 2014 16:44:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta09.westchester.pa.mail.comcast.net with comcast id t4kP1o0053Ge9ey3V4kPop; Fri, 19 Sep 2014 16:44:23 +0000 Message-ID: <541C5D67.8010806@alum.mit.edu> Date: Fri, 19 Sep 2014 12:44:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF1E5A7543@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5A7543@MCHP04MSX.global-ad.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=q20140121; t=1411145063; bh=Gx/0AIpJUhy3Ib0YebgjVixdX+wM1a0npEKXgqC4QGw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C0bO4r7bsueQnzJRD6FalduE9l6SCRii7qtvO5ZllGYi90Gic5IEsbfyzuETj1rAc xVq8YBQlXZFBCoPRlfbU/7UtgjnLSEKLM5V+3g2AJvJ6yqFLIQVDuIjAwFu/0qhSYp TopUtgbHi3CF54g8xazYRSrP49IS6/HbWQSzTYJtVXM85Q2qy0dCpBWWWtWdEoun45 MHO2v0m3WFxfr5KT3aZhfNUZsFyxe7KM5a6zu44gN8AI9kIOoWHs6HPJkEHt5l57Io XbjUBh1zbDdKjxdSpAj5tP+fCIAHoOqJX81kZLx4a7u4dyfyHa9SGxPmawEFXfWGT+ 0sKfYXLrtwpmg== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/yxvsXbSu8G5JJVCd2oHGnbB3OqA Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 19 Sep 2014 16:44:26 -0000 On 9/19/14 4:13 AM, Hutton, Andrew wrote: > Hi All, > The deadline for requesting an IETF91 meeting slot is next week (26^th > of Sept). > Please let the chairs know if you believe a SIPREC meeting at IETF91 is > needed and why and whether you have anything to present. > Given that there has no list discussion I am thinking that maybe there > is no need for a SIPREC meeting this time. > Regards > Andy (SIPREC Co-Chair). I have been *trying* to get list discussion going! I submitted an updated version of the msrp recording draft, and then posted a request for review/comments several different times. I haven't gotten any. I got much of my best feedback at the last meeting. Thanks, Paul From nobody Sun Sep 21 08:54:39 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA211A0120 for ; Sun, 21 Sep 2014 08:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Jjtt-NClqY for ; Sun, 21 Sep 2014 08:54:35 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B891A011F for ; Sun, 21 Sep 2014 08:54:33 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by resqmta-ch2-08v.sys.comcast.net with comcast id trt61o00517dt5G01ruYnW; Sun, 21 Sep 2014 15:54:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta13.westchester.pa.mail.comcast.net with comcast id truY1o00G3Ge9ey3ZruYYS; Sun, 21 Sep 2014 15:54:32 +0000 Message-ID: <541EF4B8.7080603@alum.mit.edu> Date: Sun, 21 Sep 2014 11:54:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "siprec@ietf.org" References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> In-Reply-To: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> X-Forwarded-Message-Id: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> Content-Type: multipart/mixed; boundary="------------070407030203010008040106" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411314873; bh=yqcs601oM4L/ksRz1hn5hoTWWOttGlRRoVOVN09Hq4k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JbL/0i279TsfrAN+5S4jyM5+LlY4aRKY//nQy3IG+ZgziUhH92IzvirJEaZn3QQyC XkFKWtu+T85aicBWvOqeXUTDA2pB/IVVn0LB02BvX7khv6Cz4sxmiL74XzB+cwqi2g cCsTWPqxxgyojru5cPcqMRwOu/M37awqrGT4Wmd1UjiEumrDJDHaKDC49TentuwnfO APrnN+bQ8R0rgZsFWiFxU6wzyL2tXlPytvRq+zRYgPGeAgmPpRzXpwfdO6lql0wT0d 4Z4xH9k4I74cL34osOcnsE3dVG2kPBB4c1eXH911AEMTI9X2cK26y7HMrdCBsarCc8 k9gOwaqG0pfjg== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/y8S8yqfb5jtQ0uhFA9pYg8KvmyI Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 15:54:38 -0000 This is a multi-part message in MIME format. --------------070407030203010008040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I got permission from Adrian to post this private reply to the list for discussion. -------- Original Message -------- Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt Date: Sat, 13 Sep 2014 22:30:40 -0300 From: Adrian Georgescu To: Paul Kyzivat Hi Paul, I had a look at it. I am an engineer and look at practical maters. I use MSRP chat and file transfers almost every day with Blink and Blink uses OTR by default. That means that media is end-to end encrypted and this happens by default rather than users having to enable it. If someone tampers with the encryption, user is alerted and will he/she is likely to bail out of the conversation if is intercepted. Therefore scenario 3.2 where an MSRP relay is used for intercept purpose does not hold because of possible usage of end-to-end encryption in the clients. Unless you control at least one of the end-points, you cannot intercept. Mandating that MSRP relays support a feature it cannot enforce is kind of flaw. I would leave it out or explaining why it does not work. The scenario where recording makes most sense is multi-party chat conversations. There you explicitly give up on privacy for the sake of sharing capabilities and recording is a useful feature. If an MSRP switch is used, than the relay is not mandatory so again scenario 3.2 is not realistic. I would but scenario 3.3 in pole position in the document. Last, I would like to see a provision in the draft to make possible for an end-user to indicate that it does not want its message to be stored by the other side (the reverse feature of a party initiating interception and telling the other side about it). We use this feature in Blink today and I find it useful as sometimes I want to write something that I know that the other party would not save in its history database like a password or other data that need to be consumed and not reused latter. Adrian On 02 Sep 2014, at 11:20, Paul Kyzivat > wrote: > Adrian, > > I've been working on a draft for the siprec wg about the recording of > msrp. > > Ben Campbell suggested that I contact you because you have more > real-life experience with msrp than most people. > > I would appreciate any comments you have on this draft. > > For context, if you haven't followed siprec, you may have to look at > some of the previous siprec drafts to understand what it is about. And > I'll be happy to answer any questions you might have. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: [siprec] New Version Notification for > draft-yan-siprec-msrp-recording-02.txt > Date: Wed, 27 Aug 2014 16:28:41 -0400 > From: Paul Kyzivat > > To: siprec@ietf.org > > > I just submitted a revised version of the MSRP recording draft. > > The following is a summary of what is different in this version. (It is > in the draft too.) > > This version addresses comments received on the -01 version, both on > the mailing list and at IETF90. The following is my list of things > to address: > > o Define a new MIME type that is used to wrap the CS MSRP messages > that are being recorded. This allows the original message to be > left as-is, so it is always clear what it was. While CPIM could > be used for this, defining a new type will allow capturing other > necessary metadata. > > o Need to further consider the need to track message timing. Can > the timing of messages received by the SRS on the RS MSRP stream > be considered a sufficient proxy for the timing of messages in the > CS, or should we explicitly pass timestamps of messages as > received on the CS? (The issue was raised but not decided.) > > o We need to clarify that there is no guarantee that messages > received on the CS have been recorded. > > o It was agreed that there is no need to record the MSRP URIs that > are used to establish the CS MSRP session. > > o It is important that we maintain a 1:1 consistency between MSRP > MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used > in the RS. But we should not violate MSRP by using the same > MESSAGE-IDs. We came up with the idea of adding an SRC-specific > prefix to the CS message ids to create unique ones for the RS. > This should be done in a standard way so that the SRS can recover > the original CS message ids, in order to support correlation > across redundant SRCs. > > o Will need to work out the details of what happens when a CS MSRP > session is terminated with an incomplete message. It will be > necessary to send the incomplete message to the SRS, but must it > appear to be incomplete within the SRS MSRP session? > > o There are a variety of reasons why the SRC may not want, or be > able to, record individual messages in the CS session. (One > example is because the message size is greater than the maximum > indicated by the SRS. Another is because the mime type of the > message is a type that the SRS did not indicate support for.) > There should be a type of placeholder message that can be sent to > the SRS to indicate a message has been dropped, why, and some key > attributes about the message. The new SIPREC wrapper mime type > could be designed to serve this purpose. > > o REPORT messages on the CS can't be sent directly on the RS. The > new SIPREC wrapper mime type could also serve as a way to > encapsulate those. > > The primary change is to introduce a new wrapper MIME type > ("application/msrp-recording") that is used in RS MSRP sessions for > all CS MSRP messages that are to be recorded. This is used with SEND > messages whether they have a CPIM wrapper or not. It also allows > non-SEND messages from the CS to be sent intact in the RS for > recording. And it provides a vehicle for carrying other data as > needed. > > Adding another layer of wrapper could substantially increase the > total amount of data send on the RS session, relative to what is > present on the CS. I've tried to mitigate that via the details of > the design. For SEND messages, only the body of the SEND message is > wrapped. And From and To headers in this wrapper can be omitted in > cases where that information is redundant. I've assumed that > messages other than SEND should in general be infrequent enough that > extra overhead when sending them isn't worth a lot of concern. > > This wrapper can carry a DateTime header. This provides a mechanism > to address the timestamp issues. I've left it as optional to use. > > I clarified the non-guarantee of recording in the architecture > section. > > I've provided a special header in the wrapper to carry the MESSAGE-ID > from SEND messages in the CS. And SEND messages will get a separate > MESSAGE-ID on the RS MSRP session when sent to the SRS. This > provides the SRS with enough information to solve the correlation > problem when a message is incomplete in one CS MSRP session and is > resumed on another. (The problem of reassembly is left to the SRS.) > > The wrapper format includes a mechanism for the SRC to report dropped > messages to the SRS. > > The wrapper format also includes a mechanism for encapsulating CS > REPORT messages for sending to the SRS. > > I realized that this level of wrapping provides an opportunity to > multiplex unrelated CS MSRP sessions on a single RS MSRP session. To > allow this I've provided a way to include the session-id from the > metadata, that identifies the particular CS MSRP session, as a value > in the wrapper of the message sent on the RS. But I also made that > optional when it is redundant. This gives a choice: multiplex but > make the messages bigger, or create a separate RS MSRP session for > each CS MSRP session and keep the messages smaller. I've included > this as a trial balloon for discussion. I'm undecided about it. > > The formatting of all of this could be better. But for now I just > wanted to get the basic concepts down for review. Once the approach > is reasonably well worked out I'll try to improve the formatting. > > There are many places here where I am uncertain what normative > strength to apply to individual requirements. I've indicated this > inline for many of those. Please comment on this. > > I believe this is in line with what was discussed in Toronto. > > I especially want to hear whether people find this an acceptable > direction, as well as thoughts on the details. And anything I might have > overlooked that still needs to be addressed. > > Thanks, > Paul > > -------- Original Message -------- > Subject: New Version Notification for > draft-yan-siprec-msrp-recording-02.txt > Date: Wed, 27 Aug 2014 13:19:15 -0700 > From: internet-drafts@ietf.org > To: Michael Yan >, "Paul H. Kyzivat" > >, > "Michael Yan" >, > "Paul Kyzivat" > > > > A new version of I-D, draft-yan-siprec-msrp-recording-02.txt > has been successfully submitted by Paul H. Kyzivat and posted to the > IETF repository. > > Name:draft-yan-siprec-msrp-recording > Revision:02 > Title:Overview for MSRP Recording based on SIPREC > Document date:2014-08-27 > Group:Individual Submission > Pages:17 > URL: > http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt > Status: > https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ > Htmlized: > http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02 > > Abstract: > SIPREC is capable of recording interactive text media that is > transmitted via RTP. However that format is not commonly used for > message or chat scenarios. There is also a need for recording text > media carried via MSRP. One case of note is exchange of text between > hearing-impaired users and emergence service bureaus. Also, > recording support is needed for MSRP used in chat conferences and > multimedia conferences. > > This document describes how to achieve MSRP channel recording within > the mechanism of SIP Recording (SIPREC). > > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > -- Adrian --------------070407030203010008040106 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KQ29tbWVudDogR1BHVG9vbHMgLSBodHRw Oi8vZ3BndG9vbHMub3JnCgppRVlFQVJFQ0FBWUZBbFFVNzhFQUNna1FCV2RwcVZFWnRHZXE4 d0NndWUvbWVUdWRXb2RiWlZaK282dFVNdXZaCm1EMEFuM2svSTIyNGFJaU1leVE4dDNCMFN3 TFg3WXI4Cj1oTjJsCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQoK --------------070407030203010008040106-- From nobody Sun Sep 21 09:17:33 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559AD1A0127 for ; Sun, 21 Sep 2014 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNjYOgOJfoeQ for ; Sun, 21 Sep 2014 09:17:26 -0700 (PDT) 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 EDB071A0108 for ; Sun, 21 Sep 2014 09:17:22 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id trPs1o0020ldTLk51sHNvk; Sun, 21 Sep 2014 16:17:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta04.westchester.pa.mail.comcast.net with comcast id tsHM1o00X3Ge9ey01sHNQW; Sun, 21 Sep 2014 16:17:22 +0000 Message-ID: <541EFA11.5030200@alum.mit.edu> Date: Sun, 21 Sep 2014 12:17:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> In-Reply-To: <541EF4B8.7080603@alum.mit.edu> 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=q20140121; t=1411316242; bh=CAhWO2eRTQ64pSwLGqoEQRJtD7B2nm/B0a1U4uuPxFg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mjOvbY89UTdbACsoxnsNT+0v22n4yePB+0pnN4Vd6vNz/0tEBFGLbLONTqfMubmrz E/eARsyyfOXPoRebaTVm7XyFuISElOPcMKMtieLr1ss8hJPgG3VssWZrzrEgv7vkRp RrwX8P3APqGvfYLfgzkonngxYQkQFFqNnIwRoC1otbrTnRvSEmahRqdCwxWuSCAMYF B8Rjy6caRKf/6KQJUNPFuPo2YKrQOzzfWt5PTqZcwgAy1ku/OEYFxuAq/GswC7Losa 2uw6vfUV3ekGmrFrzb4ZK2WxmLIs7L2F78gTUMShXSipdNzQQcNHWtLIR5FWZGUWsQ N8zkdf934uDKA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/o1JOFDf_YTP7iY4ESEHMSmPOKAs Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 16:17:28 -0000 Adrian, Thanks for commenting. Responses inline. > From: Adrian Georgescu > Hi Paul, > > I had a look at it. I am an engineer and look at practical maters. I use > MSRP chat and file transfers almost every day with Blink and Blink uses > OTR by default. That means that media is end-to end encrypted and this > happens by default rather than users having to enable it. If someone > tampers with the encryption, user is alerted and will he/she is likely > to bail out of the conversation if is intercepted. Therefore scenario > 3.2 where an MSRP relay is used for intercept purpose does not hold > because of possible usage of end-to-end encryption in the clients. > Unless you control at least one of the end-points, you cannot intercept. > Mandating that MSRP relays support a feature it cannot enforce is kind > of flaw. I would leave it out or explaining why it does not work. I'm not familiar with OTR other than what wikipedia tells me, and it doesn't say how it works with MSRP. I'm guessing that it is just encrypting the body of messages? (So that MSRP relays can still be used - but can't understand the content of the body.) If so, then I don't think this changes much. A relay could still record what it gets, even if the recorded content is unintelligible to most. Suppose that were the case. Would the recorded content be decodable by full knowledge of the keys of sender and receiver? Also, we don't mandate which elements do recording. We only try to describe possibilities. So perhaps in the your case useful recordings could only be done by the endpoints. (That might be the desired effect for those using OTR.) If so, perhaps that deserves some consideration. As currently described, the recording is applied to the MSRP messages, as seen by *somebody* in the path those messages traverse. If those messages are encrypted, then perhaps that is the wrong strategy. Perhaps in that case it is the *unencrypted* messages that need to be recorded. (Possibly encrypted again for the recorder.) That would require some changes to the proposal. > The scenario where recording makes most sense is multi-party chat > conversations. There you explicitly give up on privacy for the sake of > sharing capabilities and recording is a useful feature. If an MSRP > switch is used, than the relay is not mandatory so again scenario 3.2 is > not realistic. I would but scenario 3.3 in pole position in the document. > > Last, I would like to see a provision in the draft to make possible for > an end-user to indicate that it does not want its message to be stored > by the other side (the reverse feature of a party initiating > interception and telling the other side about it). Are you familiar with the base siprec drafts? (Particularly draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to indicate a preference for recording, or for *not* recording. It applies to audio and video, and with the msrp-recording draft it will apply also to that. Thanks, Paul > We use this feature > in Blink today and I find it useful as sometimes I want to write > something that I know that the other party would not save in its history > database like a password or other data that need to be consumed and not > reused latter. > > Adrian > > On 02 Sep 2014, at 11:20, Paul Kyzivat > wrote: > >> Adrian, >> >> I've been working on a draft for the siprec wg about the recording of >> msrp. >> >> Ben Campbell suggested that I contact you because you have more >> real-life experience with msrp than most people. >> >> I would appreciate any comments you have on this draft. >> >> For context, if you haven't followed siprec, you may have to look at >> some of the previous siprec drafts to understand what it is about. And >> I'll be happy to answer any questions you might have. >> >> Thanks, >> Paul >> >> >> -------- Original Message -------- >> Subject: [siprec] New Version Notification for >> draft-yan-siprec-msrp-recording-02.txt >> Date: Wed, 27 Aug 2014 16:28:41 -0400 >> From: Paul Kyzivat > >> To: siprec@ietf.org > > >> >> I just submitted a revised version of the MSRP recording draft. >> >> The following is a summary of what is different in this version. (It is >> in the draft too.) >> >> This version addresses comments received on the -01 version, both on >> the mailing list and at IETF90. The following is my list of things >> to address: >> >> o Define a new MIME type that is used to wrap the CS MSRP messages >> that are being recorded. This allows the original message to be >> left as-is, so it is always clear what it was. While CPIM could >> be used for this, defining a new type will allow capturing other >> necessary metadata. >> >> o Need to further consider the need to track message timing. Can >> the timing of messages received by the SRS on the RS MSRP stream >> be considered a sufficient proxy for the timing of messages in the >> CS, or should we explicitly pass timestamps of messages as >> received on the CS? (The issue was raised but not decided.) >> >> o We need to clarify that there is no guarantee that messages >> received on the CS have been recorded. >> >> o It was agreed that there is no need to record the MSRP URIs that >> are used to establish the CS MSRP session. >> >> o It is important that we maintain a 1:1 consistency between MSRP >> MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used >> in the RS. But we should not violate MSRP by using the same >> MESSAGE-IDs. We came up with the idea of adding an SRC-specific >> prefix to the CS message ids to create unique ones for the RS. >> This should be done in a standard way so that the SRS can recover >> the original CS message ids, in order to support correlation >> across redundant SRCs. >> >> o Will need to work out the details of what happens when a CS MSRP >> session is terminated with an incomplete message. It will be >> necessary to send the incomplete message to the SRS, but must it >> appear to be incomplete within the SRS MSRP session? >> >> o There are a variety of reasons why the SRC may not want, or be >> able to, record individual messages in the CS session. (One >> example is because the message size is greater than the maximum >> indicated by the SRS. Another is because the mime type of the >> message is a type that the SRS did not indicate support for.) >> There should be a type of placeholder message that can be sent to >> the SRS to indicate a message has been dropped, why, and some key >> attributes about the message. The new SIPREC wrapper mime type >> could be designed to serve this purpose. >> >> o REPORT messages on the CS can't be sent directly on the RS. The >> new SIPREC wrapper mime type could also serve as a way to >> encapsulate those. >> >> The primary change is to introduce a new wrapper MIME type >> ("application/msrp-recording") that is used in RS MSRP sessions for >> all CS MSRP messages that are to be recorded. This is used with SEND >> messages whether they have a CPIM wrapper or not. It also allows >> non-SEND messages from the CS to be sent intact in the RS for >> recording. And it provides a vehicle for carrying other data as >> needed. >> >> Adding another layer of wrapper could substantially increase the >> total amount of data send on the RS session, relative to what is >> present on the CS. I've tried to mitigate that via the details of >> the design. For SEND messages, only the body of the SEND message is >> wrapped. And From and To headers in this wrapper can be omitted in >> cases where that information is redundant. I've assumed that >> messages other than SEND should in general be infrequent enough that >> extra overhead when sending them isn't worth a lot of concern. >> >> This wrapper can carry a DateTime header. This provides a mechanism >> to address the timestamp issues. I've left it as optional to use. >> >> I clarified the non-guarantee of recording in the architecture >> section. >> >> I've provided a special header in the wrapper to carry the MESSAGE-ID >> from SEND messages in the CS. And SEND messages will get a separate >> MESSAGE-ID on the RS MSRP session when sent to the SRS. This >> provides the SRS with enough information to solve the correlation >> problem when a message is incomplete in one CS MSRP session and is >> resumed on another. (The problem of reassembly is left to the SRS.) >> >> The wrapper format includes a mechanism for the SRC to report dropped >> messages to the SRS. >> >> The wrapper format also includes a mechanism for encapsulating CS >> REPORT messages for sending to the SRS. >> >> I realized that this level of wrapping provides an opportunity to >> multiplex unrelated CS MSRP sessions on a single RS MSRP session. To >> allow this I've provided a way to include the session-id from the >> metadata, that identifies the particular CS MSRP session, as a value >> in the wrapper of the message sent on the RS. But I also made that >> optional when it is redundant. This gives a choice: multiplex but >> make the messages bigger, or create a separate RS MSRP session for >> each CS MSRP session and keep the messages smaller. I've included >> this as a trial balloon for discussion. I'm undecided about it. >> >> The formatting of all of this could be better. But for now I just >> wanted to get the basic concepts down for review. Once the approach >> is reasonably well worked out I'll try to improve the formatting. >> >> There are many places here where I am uncertain what normative >> strength to apply to individual requirements. I've indicated this >> inline for many of those. Please comment on this. >> >> I believe this is in line with what was discussed in Toronto. >> >> I especially want to hear whether people find this an acceptable >> direction, as well as thoughts on the details. And anything I might have >> overlooked that still needs to be addressed. >> >> Thanks, >> Paul >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-yan-siprec-msrp-recording-02.txt >> Date: Wed, 27 Aug 2014 13:19:15 -0700 >> From: internet-drafts@ietf.org >> To: Michael Yan > >, "Paul H. Kyzivat" >> >, >> "Michael Yan" > >, >> "Paul Kyzivat" > > >> >> >> A new version of I-D, draft-yan-siprec-msrp-recording-02.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the >> IETF repository. >> >> Name:draft-yan-siprec-msrp-recording >> Revision:02 >> Title:Overview for MSRP Recording based on SIPREC >> Document date:2014-08-27 >> Group:Individual Submission >> Pages:17 >> URL: >> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ >> Htmlized: >> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02 >> >> Abstract: >> SIPREC is capable of recording interactive text media that is >> transmitted via RTP. However that format is not commonly used for >> message or chat scenarios. There is also a need for recording text >> media carried via MSRP. One case of note is exchange of text between >> hearing-impaired users and emergence service bureaus. Also, >> recording support is needed for MSRP used in chat conferences and >> multimedia conferences. >> >> This document describes how to achieve MSRP channel recording within >> the mechanism of SIP Recording (SIPREC). >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> >> >> > > -- > Adrian > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Sun Sep 21 09:21:13 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9277A1A014B for ; Sun, 21 Sep 2014 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcYHQ5ybIdRi for ; Sun, 21 Sep 2014 09:21:09 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE91A0146 for ; Sun, 21 Sep 2014 09:21:08 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id tsBL1o0010xGWP851sM82R; Sun, 21 Sep 2014 16:21:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta12.westchester.pa.mail.comcast.net with comcast id tsM71o00U3Ge9ey3YsM7Nt; Sun, 21 Sep 2014 16:21:08 +0000 Message-ID: <541EFAF3.5000904@alum.mit.edu> Date: Sun, 21 Sep 2014 12:21:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Georgescu References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> In-Reply-To: <541EF4B8.7080603@alum.mit.edu> 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=q20140121; t=1411316468; bh=Q/L61C08v7Nl14CbfLKvr5/f1zMsjxxmlyyYdgwqOsI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jnTLj7/9a2QoPPAgch0mE4MknlSELdmkyBlnK+63twvLCdQjx9BT+KiTsDeUrRJYt unbb7pNGYMh+T4UblJSuKTUExbet012Gtqa+A5I6Gfd7eKJWDbC7tCV0ZELqpU5j66 0eXNEyz6rlj4gexELb8ofp1uA7iWnNnCE+M1btHbD7hEAiLEszZvF5zv9fIVmM2H2D Bc5K2GDH2ARFbFb5svHFjsCk1MF6n9dW7mUsZ+IimbWr2/k7zCC9x+X2ss3M0/UWUM qsmg2pSv+3Thf8yAtwSXoQBlz0+GCsFoxql/IaaYuqGR0ZYYJVRpN+dswygBT+6D3b sIi/pyaolGfQQ== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/7RiHtGbme3397dpNQsehxV084EY Cc: siprec@ietf.org Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 16:21:11 -0000 [resending, including Adrian since I don't think he is on the siprec list. Please reply to this one so he is included.] Adrian, Thanks for commenting. Responses inline. > From: Adrian Georgescu > Hi Paul, > > I had a look at it. I am an engineer and look at practical maters. I use > MSRP chat and file transfers almost every day with Blink and Blink uses > OTR by default. That means that media is end-to end encrypted and this > happens by default rather than users having to enable it. If someone > tampers with the encryption, user is alerted and will he/she is likely > to bail out of the conversation if is intercepted. Therefore scenario > 3.2 where an MSRP relay is used for intercept purpose does not hold > because of possible usage of end-to-end encryption in the clients. > Unless you control at least one of the end-points, you cannot intercept. > Mandating that MSRP relays support a feature it cannot enforce is kind > of flaw. I would leave it out or explaining why it does not work. I'm not familiar with OTR other than what wikipedia tells me, and it doesn't say how it works with MSRP. I'm guessing that it is just encrypting the body of messages? (So that MSRP relays can still be used - but can't understand the content of the body.) If so, then I don't think this changes much. A relay could still record what it gets, even if the recorded content is unintelligible to most. Suppose that were the case. Would the recorded content be decodable by full knowledge of the keys of sender and receiver? Also, we don't mandate which elements do recording. We only try to describe possibilities. So perhaps in the your case useful recordings could only be done by the endpoints. (That might be the desired effect for those using OTR.) If so, perhaps that deserves some consideration. As currently described, the recording is applied to the MSRP messages, as seen by *somebody* in the path those messages traverse. If those messages are encrypted, then perhaps that is the wrong strategy. Perhaps in that case it is the *unencrypted* messages that need to be recorded. (Possibly encrypted again for the recorder.) That would require some changes to the proposal. > The scenario where recording makes most sense is multi-party chat > conversations. There you explicitly give up on privacy for the sake of > sharing capabilities and recording is a useful feature. If an MSRP > switch is used, than the relay is not mandatory so again scenario 3.2 is > not realistic. I would but scenario 3.3 in pole position in the document. > > Last, I would like to see a provision in the draft to make possible for > an end-user to indicate that it does not want its message to be stored > by the other side (the reverse feature of a party initiating > interception and telling the other side about it). Are you familiar with the base siprec drafts? (Particularly draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to indicate a preference for recording, or for *not* recording. It applies to audio and video, and with the msrp-recording draft it will apply also to that. Thanks, Paul > We use this feature > in Blink today and I find it useful as sometimes I want to write > something that I know that the other party would not save in its history > database like a password or other data that need to be consumed and not > reused latter. > > Adrian > > On 02 Sep 2014, at 11:20, Paul Kyzivat > wrote: > >> Adrian, >> >> I've been working on a draft for the siprec wg about the recording of >> msrp. >> >> Ben Campbell suggested that I contact you because you have more >> real-life experience with msrp than most people. >> >> I would appreciate any comments you have on this draft. >> >> For context, if you haven't followed siprec, you may have to look at >> some of the previous siprec drafts to understand what it is about. And >> I'll be happy to answer any questions you might have. >> >> Thanks, >> Paul >> >> >> -------- Original Message -------- >> Subject: [siprec] New Version Notification for >> draft-yan-siprec-msrp-recording-02.txt >> Date: Wed, 27 Aug 2014 16:28:41 -0400 >> From: Paul Kyzivat > >> To: siprec@ietf.org > > >> >> I just submitted a revised version of the MSRP recording draft. >> >> The following is a summary of what is different in this version. (It is >> in the draft too.) >> >> This version addresses comments received on the -01 version, both on >> the mailing list and at IETF90. The following is my list of things >> to address: >> >> o Define a new MIME type that is used to wrap the CS MSRP messages >> that are being recorded. This allows the original message to be >> left as-is, so it is always clear what it was. While CPIM could >> be used for this, defining a new type will allow capturing other >> necessary metadata. >> >> o Need to further consider the need to track message timing. Can >> the timing of messages received by the SRS on the RS MSRP stream >> be considered a sufficient proxy for the timing of messages in the >> CS, or should we explicitly pass timestamps of messages as >> received on the CS? (The issue was raised but not decided.) >> >> o We need to clarify that there is no guarantee that messages >> received on the CS have been recorded. >> >> o It was agreed that there is no need to record the MSRP URIs that >> are used to establish the CS MSRP session. >> >> o It is important that we maintain a 1:1 consistency between MSRP >> MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used >> in the RS. But we should not violate MSRP by using the same >> MESSAGE-IDs. We came up with the idea of adding an SRC-specific >> prefix to the CS message ids to create unique ones for the RS. >> This should be done in a standard way so that the SRS can recover >> the original CS message ids, in order to support correlation >> across redundant SRCs. >> >> o Will need to work out the details of what happens when a CS MSRP >> session is terminated with an incomplete message. It will be >> necessary to send the incomplete message to the SRS, but must it >> appear to be incomplete within the SRS MSRP session? >> >> o There are a variety of reasons why the SRC may not want, or be >> able to, record individual messages in the CS session. (One >> example is because the message size is greater than the maximum >> indicated by the SRS. Another is because the mime type of the >> message is a type that the SRS did not indicate support for.) >> There should be a type of placeholder message that can be sent to >> the SRS to indicate a message has been dropped, why, and some key >> attributes about the message. The new SIPREC wrapper mime type >> could be designed to serve this purpose. >> >> o REPORT messages on the CS can't be sent directly on the RS. The >> new SIPREC wrapper mime type could also serve as a way to >> encapsulate those. >> >> The primary change is to introduce a new wrapper MIME type >> ("application/msrp-recording") that is used in RS MSRP sessions for >> all CS MSRP messages that are to be recorded. This is used with SEND >> messages whether they have a CPIM wrapper or not. It also allows >> non-SEND messages from the CS to be sent intact in the RS for >> recording. And it provides a vehicle for carrying other data as >> needed. >> >> Adding another layer of wrapper could substantially increase the >> total amount of data send on the RS session, relative to what is >> present on the CS. I've tried to mitigate that via the details of >> the design. For SEND messages, only the body of the SEND message is >> wrapped. And From and To headers in this wrapper can be omitted in >> cases where that information is redundant. I've assumed that >> messages other than SEND should in general be infrequent enough that >> extra overhead when sending them isn't worth a lot of concern. >> >> This wrapper can carry a DateTime header. This provides a mechanism >> to address the timestamp issues. I've left it as optional to use. >> >> I clarified the non-guarantee of recording in the architecture >> section. >> >> I've provided a special header in the wrapper to carry the MESSAGE-ID >> from SEND messages in the CS. And SEND messages will get a separate >> MESSAGE-ID on the RS MSRP session when sent to the SRS. This >> provides the SRS with enough information to solve the correlation >> problem when a message is incomplete in one CS MSRP session and is >> resumed on another. (The problem of reassembly is left to the SRS.) >> >> The wrapper format includes a mechanism for the SRC to report dropped >> messages to the SRS. >> >> The wrapper format also includes a mechanism for encapsulating CS >> REPORT messages for sending to the SRS. >> >> I realized that this level of wrapping provides an opportunity to >> multiplex unrelated CS MSRP sessions on a single RS MSRP session. To >> allow this I've provided a way to include the session-id from the >> metadata, that identifies the particular CS MSRP session, as a value >> in the wrapper of the message sent on the RS. But I also made that >> optional when it is redundant. This gives a choice: multiplex but >> make the messages bigger, or create a separate RS MSRP session for >> each CS MSRP session and keep the messages smaller. I've included >> this as a trial balloon for discussion. I'm undecided about it. >> >> The formatting of all of this could be better. But for now I just >> wanted to get the basic concepts down for review. Once the approach >> is reasonably well worked out I'll try to improve the formatting. >> >> There are many places here where I am uncertain what normative >> strength to apply to individual requirements. I've indicated this >> inline for many of those. Please comment on this. >> >> I believe this is in line with what was discussed in Toronto. >> >> I especially want to hear whether people find this an acceptable >> direction, as well as thoughts on the details. And anything I might have >> overlooked that still needs to be addressed. >> >> Thanks, >> Paul >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-yan-siprec-msrp-recording-02.txt >> Date: Wed, 27 Aug 2014 13:19:15 -0700 >> From: internet-drafts@ietf.org >> To: Michael Yan > >, "Paul H. Kyzivat" >> >, >> "Michael Yan" > >, >> "Paul Kyzivat" > > >> >> >> A new version of I-D, draft-yan-siprec-msrp-recording-02.txt >> has been successfully submitted by Paul H. Kyzivat and posted to the >> IETF repository. >> >> Name:draft-yan-siprec-msrp-recording >> Revision:02 >> Title:Overview for MSRP Recording based on SIPREC >> Document date:2014-08-27 >> Group:Individual Submission >> Pages:17 >> URL: >> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ >> Htmlized: >> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02 >> >> Abstract: >> SIPREC is capable of recording interactive text media that is >> transmitted via RTP. However that format is not commonly used for >> message or chat scenarios. There is also a need for recording text >> media carried via MSRP. One case of note is exchange of text between >> hearing-impaired users and emergence service bureaus. Also, >> recording support is needed for MSRP used in chat conferences and >> multimedia conferences. >> >> This document describes how to achieve MSRP channel recording within >> the mechanism of SIP Recording (SIPREC). >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> >> >> > > -- > Adrian > > > > > > > > _______________________________________________ > 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 nobody Mon Sep 22 14:08:47 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E781A1A67 for ; Mon, 22 Sep 2014 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwqTk9jM607b for ; Mon, 22 Sep 2014 14:08:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CE41A6EE7 for ; Mon, 22 Sep 2014 14:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4263; q=dns/txt; s=iport; t=1411420086; x=1412629686; h=from:to:subject:date:message-id:mime-version; bh=C1BKgZ1QA/1YDNhUsiJPfmgBrY52B+oBIAOcp7cWedM=; b=l4hUvH+fGYex47TvrzFLW16BYf4F9z24OKecZng+F+h7pO2qmqOxsay6 5b208R1mnkA2dCPdywzd+o3TB58kkjZKs7cLIRTrtETz5HAbsB17QjCiS 3wzJ3IE7i1y5t32HZt3zCgu6mQU4I8+qdcTDqcU0Kw9NjlwqC4tjVjz7b 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHGPIFStJA2I/2dsb2JhbABggkhGU1cEylGGeVSBFRYBeoQDAQIELV4BCAQNAwECKDkUCQoEARIJiDUNxHsBF481AQErE4RjBZFXiz+VUoNhbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,574,1406592000"; d="scan'208,217";a="357261944" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 22 Sep 2014 21:08:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8ML85QP020006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 21:08:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 16:08:05 -0500 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP1qlM11j7Hi15Ak6WsE96kWAaQw== Date: Mon, 22 Sep 2014 21:08:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.16] Content-Type: multipart/alternative; boundary="_000_D045CA94334EDeckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/pzBBKn6cB-pXG91wajQCZZia-sY Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 22 Sep 2014 21:08:26 -0000 --_000_D045CA94334EDeckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, I posted an update to the protocol draft 4 weeks ago. http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html I believe this version addresses all comments and issues; however, there ha= s not been confirmation by reviewers yet. If the chairs think it would be h= elpful, I can present the latest changes at IETF 91 Cheers, Charles From: , Andrew > Date: Friday, September 19, 2014 at 1:13 AM To: "siprec@ietf.org" > Subject: [siprec] IETF91 SIPREC Meeting Hi All, The deadline for requesting an IETF91 meeting slot is next week (26th of Se= pt). Please let the chairs know if you believe a SIPREC meeting at IETF91 is nee= ded and why and whether you have anything to present. Given that there has no list discussion I am thinking that maybe there is n= o need for a SIPREC meeting this time. Regards Andy (SIPREC Co-Chair). --_000_D045CA94334EDeckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Andy,

I posted an update to the protocol draft 4 weeks ago.

I believe this version addresses all comments and issues; however, the= re has not been confirmation by reviewers yet. If the chairs think it would= be helpful, I can present the latest changes at IETF 91

Cheers,
Charles

From: <Hutton>, Andrew <andrew.hutton@unify.com> Date: Friday, September 19, 2014 at= 1:13 AM
To: "siprec@ietf.org" <= siprec@ietf.org>
Subject: [siprec] IETF91 SIPREC Mee= ting

Hi All,
 
The deadline for requesting an IETF91 meeting slot is next week (26th = of Sept).
 
Please let the chairs know if you believe a SIPREC meeting at IETF91 i= s needed and why and whether you have anything to present.
 
Given that there has no list discussion I am thinking that maybe there= is no need for a SIPREC meeting this time.
 
Regards
Andy (SIPREC Co-Chair).
 
 
--_000_D045CA94334EDeckelcuciscocom_-- From nobody Tue Sep 23 19:50:14 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C341A1A58 for ; Tue, 23 Sep 2014 19:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo9EfASz7Llb for ; Tue, 23 Sep 2014 19:50:11 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CD91A19EA for ; Tue, 23 Sep 2014 19:50:11 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-01v.sys.comcast.net with comcast id uqps1o0055AAYLo01qqB0C; Wed, 24 Sep 2014 02:50:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id uqq91o00S3Ge9ey01qqAsT; Wed, 24 Sep 2014 02:50:10 +0000 Message-ID: <54223161.8030106@alum.mit.edu> Date: Tue, 23 Sep 2014 22:50:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411527011; bh=oFtCesyWTayNNFUtrwk6jhOXE9DqQCdSx3KvOlM/gZI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CD7d0yAZwtDlBo04ifDnWaUqFMBGike3JBnhTomWo6sWsJKEiwyblEIVBAY01p6M6 W2Qnf7uOiSHmlWtuZ7YBNZoekkuqxGKF18LgfHGrssBPjAf7yL5XFw0mnX0mX078mG OYHFpJGliwhHzOjkrEu+XiH8haEtL44kOXpLRy4LPJZl/gW/N4ShpaPqX1p+v9YA30 Vr/SrPBEQMaOEF7Llsr2TLYnB0a0J2sZQeZnx/4007OB6/Vt47wZBJiZVLwfcGHhQe +Q2v7CxxmcVQpeHiRvWTm26v6uDMFmMm5satwpd2MGnBb+IXFEGXwzP7SjB5b58xw1 bFUvTLDIkVoDA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/Rcx0p2zkCHe8Cjj6MaS0IaGAiHA Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 02:50:13 -0000 Can we please try to *finish* the base siprec drafts before or at this meeting??? On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: > Hi Andy, > > I posted an update to the protocol draft 4 weeks ago. > http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html > > I believe this version addresses all comments and issues; however, there > has not been confirmation by reviewers yet. If the chairs think it would > be helpful, I can present the latest changes at IETF 91 > > Cheers, > Charles > > From: , Andrew > > Date: Friday, September 19, 2014 at 1:13 AM > To: "siprec@ietf.org " > > Subject: [siprec] IETF91 SIPREC Meeting > > Hi All, > The deadline for requesting an IETF91 meeting slot is next week > (26^th of Sept). > Please let the chairs know if you believe a SIPREC meeting at IETF91 > is needed and why and whether you have anything to present. > Given that there has no list discussion I am thinking that maybe > there is no need for a SIPREC meeting this time. > Regards > Andy (SIPREC Co-Chair). > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Wed Sep 24 06:58:04 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62F11A013B for ; Wed, 24 Sep 2014 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlIYo-_xXh3u for ; Wed, 24 Sep 2014 06:58:02 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0A1A0110 for ; Wed, 24 Sep 2014 06:58:01 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 802791EB8558; Wed, 24 Sep 2014 15:58:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 15:58:00 +0200 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , Alan Johnston , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-14.txt Thread-Index: AQHPwJK2ZkkDqfq+BEeyb41Yw7oH5Jvhi1kAgC7szcA= Date: Wed, 24 Sep 2014 13:57:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5AC590@MCHP04MSX.global-ad.net> References: <20140825183038.4220.17752.idtracker@ietfa.amsl.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/txKaUscBkR1Ihh78T3NTKcxgCIg Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-14.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 13:58:03 -0000 I looked through the latest updates and as far as I can see they are all co= me from Alan's comments and he agreed to your suggested updated so hopefull= y this is not a big issue and I hope we don't need meeting time to discuss = this. Alan, can you confirm you are happy with the updates. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel (eckelcu) > Sent: 25 August 2014 20:02 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-14.txt >=20 > This update includes the changes agreed to previously on the list: > http://www.ietf.org/mail-archive/web/siprec/current/msg03995.html >=20 > It also updates the reference to the architecture draft, which is now > RFC > 7245, and replaced =B3inband=B2 with =B3in-band=B2 to make the spell chec= ker > happy. >=20 > Cheers, > Charles >=20 >=20 > On 8/25/14, 11:30 AM, "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the SIP Recording Working Group of the > IETF. > > > > Title : Session Recording Protocol > > Authors : Leon Portman > > Henry Lum > > Charles Eckel > > Alan Johnston > > Andrew Hutton > > Filename : draft-ietf-siprec-protocol-14.txt > > Pages : 43 > > Date : 2014-08-25 > > > >Abstract: > > This document specifies the use of the Session Initiation Protocol > > (SIP), the Session Description Protocol (SDP), and the Real Time > > Protocol (RTP) for delivering real-time media and metadata from a > > Communication Session (CS) to a recording device. The Session > > Recording Protocol specifies the use of SIP, SDP, and RTP to > > establish a Recording Session (RS) between the Session Recording > > Client (SRC), which is on the path of the CS, and a Session > Recording > > Server (SRS) at the recording device. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-siprec-protocol-14 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-14 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >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 nobody Wed Sep 24 07:52:07 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC0C1A0114 for ; Wed, 24 Sep 2014 07:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEKoou0QLnVc for ; Wed, 24 Sep 2014 07:52:01 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD521A0079 for ; Wed, 24 Sep 2014 07:52:01 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 6633A23F062E for ; Wed, 24 Sep 2014 16:52:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 16:52:00 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC @ IETF91 Thread-Index: Ac/YBxe0s/e873zcTwiCtwJei2F17A== Date: Wed, 24 Sep 2014 14:51:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5AC700@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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E5AC700MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/9VWNn4lkVI_djhs6n1EVnfSKfuY Subject: [siprec] SIPREC @ IETF91 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 14:52:06 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5AC700MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have requested a one hour meeting slot for SIPREC during the IETF91 meeti= ng. Regards Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5AC700MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have requested a one hour meeting slot for SIPREC during the IETF91 = meeting.
 
Regards
Andy
 
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5AC700MCHP04MSXglobal_-- From nobody Wed Sep 24 09:10:09 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C181A00DE for ; Wed, 24 Sep 2014 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz0wEZCDVWjP for ; Wed, 24 Sep 2014 09:09:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438CF1A0115 for ; Wed, 24 Sep 2014 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1925; q=dns/txt; s=iport; t=1411574995; x=1412784595; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vIJXGJ/M97AiLw2VMF7ekX2uAvudVCpRFhMW0c3jUyw=; b=YH05YscscHXSgB/iJi54w/nGkGTCYVNhel56ysfFNe8gnIXMw06/9Obi X4NwkfHooohbo58FtgTnZ4i5+Yz9E6WIk8Drttrc+xFIStJqfDRotCuVh pT+gO81QUNnhs8b0dXgBFjkWwuJdOS6sxFWqafZhfZ+8hxnFRZE3ayPTo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADTsIlStJA2B/2dsb2JhbABgDoMAU1cEyjoKhnlUAYEHFgF6hAMBAQEEAQEBNzQXBAIBCA4DAwECAR4JBycLFAkIAgQBEgmINQ3DWQEXj00BASQtBQaERQWEXYx+iHGCUZVUgyJAbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,590,1406592000"; d="scan'208";a="357865492" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 24 Sep 2014 16:09:54 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8OG9sMY017545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 16:09:54 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 11:09:54 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP2BH67Qeka4F0NkuKFkgjMT7ljg== Date: Wed, 24 Sep 2014 16:09:54 +0000 Message-ID: References: <54223161.8030106@alum.mit.edu> In-Reply-To: <54223161.8030106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.73.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/c0x2TyLtlbXJPxg3IMRqlx5w9K0 Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 16:09:59 -0000 +1 I also second Paul. Can we please get some attention on the base drafts (protocol, metadata, call flows) and try to finish them at this meeting ? Ram -----Original Message----- From: Paul Kyzivat Date: Wednesday, 24 September 2014 8:20 am To: "siprec@ietf.org" Subject: Re: [siprec] IETF91 SIPREC Meeting >Can we please try to *finish* the base siprec drafts before or at this >meeting??? > >On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: >> Hi Andy, >> >> I posted an update to the protocol draft 4 weeks ago. >> http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html >> >> I believe this version addresses all comments and issues; however, there >> has not been confirmation by reviewers yet. If the chairs think it would >> be helpful, I can present the latest changes at IETF 91 >> >> Cheers, >> Charles >> >> From: , Andrew > > >> Date: Friday, September 19, 2014 at 1:13 AM >> To: "siprec@ietf.org " > > >> Subject: [siprec] IETF91 SIPREC Meeting >> >> Hi All, >> The deadline for requesting an IETF91 meeting slot is next week >> (26^th of Sept). >> Please let the chairs know if you believe a SIPREC meeting at IETF91 >> is needed and why and whether you have anything to present. >> Given that there has no list discussion I am thinking that maybe >> there is no need for a SIPREC meeting this time. >> 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 From nobody Wed Sep 24 09:29:14 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163791A010E for ; Wed, 24 Sep 2014 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neZbenFbtxZJ for ; Wed, 24 Sep 2014 09:29:11 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF2C1A00D2 for ; Wed, 24 Sep 2014 09:27:12 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-01v.sys.comcast.net with comcast id v4SY1o0045FMDhs014TBmz; Wed, 24 Sep 2014 16:27:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id v4TA1o00Y3Ge9ey014TAUg; Wed, 24 Sep 2014 16:27:11 +0000 Message-ID: <5422F0DE.4060906@alum.mit.edu> Date: Wed, 24 Sep 2014 12:27:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF1E5AC700@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5AC700@MCHP04MSX.global-ad.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=q20140121; t=1411576031; bh=Az5nbpo2bpslf7Tr2Hz/KM/xD2CZOefVXDs4QRpYgPc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b0/WRIESYZDtXUdSt0un5DvXVp1ISjXzVySXrBV1DD56Cg1BgYCwogVs0JtMEp5C2 +L94fHR3PtS96vWBSLGyvtEEqoxyLMgg8kTZvNC/JXa8wa5D6EtAHXapJSMKyd9o7i ivYc2LNAGQdIAnFpBnVDYcDjxnNUtoSn4vqy7EXW9Rh4CSRhP1RteK1UPPrjt2roql OkcOHXk63Lb7QKxt4aohra5N+24L0vD+hi48yQaArB6QsoNZKjf+kwFbZOXBF6HuSM k/HtQ6fNj261Z8SlHbFJb/3rqIV8tFsHB122Y8sBrTZh5tzg14NbruTtxcBdI4/NzY OvcHtIQcotfXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/dyyz1QYzv875KqngMkZZunxxy10 Subject: Re: [siprec] SIPREC @ IETF91 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 16:29:12 -0000 Maybe we'll be lucky and it won't be last thing Friday afternoon! On 9/24/14 10:51 AM, Hutton, Andrew wrote: > I have requested a one hour meeting slot for SIPREC during the IETF91 > meeting. > Regards > Andy > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Fri Sep 26 01:21:45 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2C1A00EF for ; Thu, 25 Sep 2014 16:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KbQi-pjFtmh for ; Thu, 25 Sep 2014 16:25:05 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 17EA11A00E7 for ; Thu, 25 Sep 2014 16:25:04 -0700 (PDT) Received: from [192.168.8.3] (r179-29-152-158.dialup.mobile.ancel.net.uy [179.29.152.158]) by mail.sipthor.net (Postfix) with ESMTPSA id 38A9D16DC6DE; Fri, 26 Sep 2014 01:24:57 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_9D386010-95DF-4ECB-82FF-B6A26A46DC5A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Adrian Georgescu In-Reply-To: <541EFAF3.5000904@alum.mit.edu> Date: Thu, 25 Sep 2014 20:24:42 -0300 Message-Id: <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> To: siprec@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/U60qY38Ze0R9qPFFMPgyNp6bVb4 X-Mailman-Approved-At: Fri, 26 Sep 2014 01:21:33 -0700 Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2014 23:25:10 -0000 --Apple-Mail=_9D386010-95DF-4ECB-82FF-B6A26A46DC5A Content-Type: multipart/alternative; boundary="Apple-Mail=_E8B8CCB1-9EC5-4976-8C3B-21269693D297" --Apple-Mail=_E8B8CCB1-9EC5-4976-8C3B-21269693D297 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 Sep 2014, at 13:21, Paul Kyzivat wrote: > [resending, including Adrian since I don't think he is on the siprec = list. Please reply to this one so he is included.] >=20 > Adrian, >=20 > Thanks for commenting. Responses inline. >=20 >> From: Adrian Georgescu >=20 >> Hi Paul, >>=20 >> I had a look at it. I am an engineer and look at practical maters. I = use >> MSRP chat and file transfers almost every day with Blink and Blink = uses >> OTR by default. That means that media is end-to end encrypted and = this >> happens by default rather than users having to enable it. If someone >> tampers with the encryption, user is alerted and will he/she is = likely >> to bail out of the conversation if is intercepted. Therefore scenario >> 3.2 where an MSRP relay is used for intercept purpose does not hold >> because of possible usage of end-to-end encryption in the clients. >> Unless you control at least one of the end-points, you cannot = intercept. >> Mandating that MSRP relays support a feature it cannot enforce is = kind >> of flaw. I would leave it out or explaining why it does not work. >=20 > I'm not familiar with OTR other than what wikipedia tells me, and it = doesn't say how it works with MSRP. >=20 > I'm guessing that it is just encrypting the body of messages? (So that = MSRP relays can still be used - but can't understand the content of the = body.) Correct. Same as RTP relays can store RTP with zRTP encrypted data where = the encryption key is not known by the SIP server as the key is not = exchanged in clear text inside signalling. >=20 > If so, then I don't think this changes much. A relay could still = record what it gets, even if the recorded content is unintelligible to = most. Yes, technically they could stored the encrypted data. >=20 > Suppose that were the case. Would the recorded content be decodable by = full knowledge of the keys of sender and receiver? >=20 Not always or not likely depending on implementation. Not when using a = forward secrecy mechanism for example. One cannot decode future = communication with an old key: https://en.wikipedia.org/wiki/Perfect_forward_secrecy > Also, we don't mandate which elements do recording. We only try to = describe possibilities. This is why possibilities likely to fail deterministically should be = dismissed. > So perhaps in the your case useful recordings could only be done by = the endpoints. (That might be the desired effect for those using OTR.) >=20 > If so, perhaps that deserves some consideration. As currently = described, the recording is applied to the MSRP messages, as seen by = *somebody* in the path those messages traverse. If those messages are = encrypted, then perhaps that is the wrong strategy. Perhaps in that case = it is the *unencrypted* messages that need to be recorded. (Possibly = encrypted again for the recorder.) That would require some changes to = the proposal. One relay can guess if OTR is negotiated as the data is cleartext inside = the MSRP data but beyond this, if the relay tries to interfere with the = initial OTR negotiation, both end-points will know. >> The scenario where recording makes most sense is multi-party chat >> conversations. There you explicitly give up on privacy for the sake = of >> sharing capabilities and recording is a useful feature. If an MSRP >> switch is used, than the relay is not mandatory so again scenario 3.2 = is >> not realistic. I would but scenario 3.3 in pole position in the = document. >>=20 >> Last, I would like to see a provision in the draft to make possible = for >> an end-user to indicate that it does not want its message to be = stored >> by the other side (the reverse feature of a party initiating >> interception and telling the other side about it). >=20 > Are you familiar with the base siprec drafts? (Particularly = draft-ietf-siprec-protocol-14.) There is a mechanism (a=3Drecordpref) to = indicate a preference for recording, or for *not* recording. It applies = to audio and video, and with the msrp-recording draft it will apply also = to that. This requires a re-INVITE, which may fail later in the middle of the = session, or be out of sync with media plane, while the media continues = to flow. It is a bad strategy as signalling and data are disconnected. = So mandating to use SIP packet that may get lost to control MSRP chat = messages in progress, is not gonna work properly. I want to know = deterministically that my next MSRP message is not going to be stored = (or fail to send at all), regardless of the SIP signalling or other = middle box protocols that helped setup the MSRP media in the first = place. >=20 > Thanks, > Paul >=20 >> We use this feature >> in Blink today and I find it useful as sometimes I want to write >> something that I know that the other party would not save in its = history >> database like a password or other data that need to be consumed and = not >> reused latter. >>=20 >> Adrian >>=20 >> On 02 Sep 2014, at 11:20, Paul Kyzivat > > wrote: >>=20 >>> Adrian, >>>=20 >>> I've been working on a draft for the siprec wg about the recording = of >>> msrp. >>>=20 >>> Ben Campbell suggested that I contact you because you have more >>> real-life experience with msrp than most people. >>>=20 >>> I would appreciate any comments you have on this draft. >>>=20 >>> For context, if you haven't followed siprec, you may have to look at >>> some of the previous siprec drafts to understand what it is about. = And >>> I'll be happy to answer any questions you might have. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: [siprec] New Version Notification for >>> draft-yan-siprec-msrp-recording-02.txt >>> Date: Wed, 27 Aug 2014 16:28:41 -0400 >>> From: Paul Kyzivat > >>> To: siprec@ietf.org >> > >>>=20 >>> I just submitted a revised version of the MSRP recording draft. >>>=20 >>> The following is a summary of what is different in this version. (It = is >>> in the draft too.) >>>=20 >>> This version addresses comments received on the -01 version, both = on >>> the mailing list and at IETF90. The following is my list of things >>> to address: >>>=20 >>> o Define a new MIME type that is used to wrap the CS MSRP messages >>> that are being recorded. This allows the original message to be >>> left as-is, so it is always clear what it was. While CPIM could >>> be used for this, defining a new type will allow capturing other >>> necessary metadata. >>>=20 >>> o Need to further consider the need to track message timing. Can >>> the timing of messages received by the SRS on the RS MSRP stream >>> be considered a sufficient proxy for the timing of messages in = the >>> CS, or should we explicitly pass timestamps of messages as >>> received on the CS? (The issue was raised but not decided.) >>>=20 >>> o We need to clarify that there is no guarantee that messages >>> received on the CS have been recorded. >>>=20 >>> o It was agreed that there is no need to record the MSRP URIs that >>> are used to establish the CS MSRP session. >>>=20 >>> o It is important that we maintain a 1:1 consistency between MSRP >>> MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs = used >>> in the RS. But we should not violate MSRP by using the same >>> MESSAGE-IDs. We came up with the idea of adding an SRC-specific >>> prefix to the CS message ids to create unique ones for the RS. >>> This should be done in a standard way so that the SRS can = recover >>> the original CS message ids, in order to support correlation >>> across redundant SRCs. >>>=20 >>> o Will need to work out the details of what happens when a CS MSRP >>> session is terminated with an incomplete message. It will be >>> necessary to send the incomplete message to the SRS, but must it >>> appear to be incomplete within the SRS MSRP session? >>>=20 >>> o There are a variety of reasons why the SRC may not want, or be >>> able to, record individual messages in the CS session. (One >>> example is because the message size is greater than the maximum >>> indicated by the SRS. Another is because the mime type of the >>> message is a type that the SRS did not indicate support for.) >>> There should be a type of placeholder message that can be sent = to >>> the SRS to indicate a message has been dropped, why, and some = key >>> attributes about the message. The new SIPREC wrapper mime type >>> could be designed to serve this purpose. >>>=20 >>> o REPORT messages on the CS can't be sent directly on the RS. The >>> new SIPREC wrapper mime type could also serve as a way to >>> encapsulate those. >>>=20 >>> The primary change is to introduce a new wrapper MIME type >>> ("application/msrp-recording") that is used in RS MSRP sessions for >>> all CS MSRP messages that are to be recorded. This is used with = SEND >>> messages whether they have a CPIM wrapper or not. It also allows >>> non-SEND messages from the CS to be sent intact in the RS for >>> recording. And it provides a vehicle for carrying other data as >>> needed. >>>=20 >>> Adding another layer of wrapper could substantially increase the >>> total amount of data send on the RS session, relative to what is >>> present on the CS. I've tried to mitigate that via the details of >>> the design. For SEND messages, only the body of the SEND message = is >>> wrapped. And =46rom and To headers in this wrapper can be omitted = in >>> cases where that information is redundant. I've assumed that >>> messages other than SEND should in general be infrequent enough = that >>> extra overhead when sending them isn't worth a lot of concern. >>>=20 >>> This wrapper can carry a DateTime header. This provides a = mechanism >>> to address the timestamp issues. I've left it as optional to use. >>>=20 >>> I clarified the non-guarantee of recording in the architecture >>> section. >>>=20 >>> I've provided a special header in the wrapper to carry the = MESSAGE-ID >>> from SEND messages in the CS. And SEND messages will get a = separate >>> MESSAGE-ID on the RS MSRP session when sent to the SRS. This >>> provides the SRS with enough information to solve the correlation >>> problem when a message is incomplete in one CS MSRP session and is >>> resumed on another. (The problem of reassembly is left to the = SRS.) >>>=20 >>> The wrapper format includes a mechanism for the SRC to report = dropped >>> messages to the SRS. >>>=20 >>> The wrapper format also includes a mechanism for encapsulating CS >>> REPORT messages for sending to the SRS. >>>=20 >>> I realized that this level of wrapping provides an opportunity to >>> multiplex unrelated CS MSRP sessions on a single RS MSRP session. = To >>> allow this I've provided a way to include the session-id from the >>> metadata, that identifies the particular CS MSRP session, as a = value >>> in the wrapper of the message sent on the RS. But I also made that >>> optional when it is redundant. This gives a choice: multiplex but >>> make the messages bigger, or create a separate RS MSRP session for >>> each CS MSRP session and keep the messages smaller. I've included >>> this as a trial balloon for discussion. I'm undecided about it. >>>=20 >>> The formatting of all of this could be better. But for now I just >>> wanted to get the basic concepts down for review. Once the = approach >>> is reasonably well worked out I'll try to improve the formatting. >>>=20 >>> There are many places here where I am uncertain what normative >>> strength to apply to individual requirements. I've indicated this >>> inline for many of those. Please comment on this. >>>=20 >>> I believe this is in line with what was discussed in Toronto. >>>=20 >>> I especially want to hear whether people find this an acceptable >>> direction, as well as thoughts on the details. And anything I might = have >>> overlooked that still needs to be addressed. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-yan-siprec-msrp-recording-02.txt >>> Date: Wed, 27 Aug 2014 13:19:15 -0700 >>> From: internet-drafts@ietf.org >>> To: Michael Yan >> >, "Paul H. Kyzivat" >>> >, >>> "Michael Yan" >> >, >>> "Paul Kyzivat" >> > >>>=20 >>>=20 >>> A new version of I-D, draft-yan-siprec-msrp-recording-02.txt >>> has been successfully submitted by Paul H. Kyzivat and posted to the >>> IETF repository. >>>=20 >>> Name:draft-yan-siprec-msrp-recording >>> Revision:02 >>> Title:Overview for MSRP Recording based on SIPREC >>> Document date:2014-08-27 >>> Group:Individual Submission >>> Pages:17 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt= >>>=20 >>> Status: >>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-02 >>>=20 >>> Abstract: >>> SIPREC is capable of recording interactive text media that is >>> transmitted via RTP. However that format is not commonly used for >>> message or chat scenarios. There is also a need for recording text >>> media carried via MSRP. One case of note is exchange of text = between >>> hearing-impaired users and emergence service bureaus. Also, >>> recording support is needed for MSRP used in chat conferences and >>> multimedia conferences. >>>=20 >>> This document describes how to achieve MSRP channel recording = within >>> the mechanism of SIP Recording (SIPREC). >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Adrian >>=20 >>=20 >>=20 >>=20 >>=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 -- Adrian --Apple-Mail=_E8B8CCB1-9EC5-4976-8C3B-21269693D297 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 21 Sep 2014, at 13:21, Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

[resending, including Adrian since I don't think he is on = the siprec list. Please reply to this one so he is = included.]

Adrian,

Thanks for commenting. Responses = inline.

From: =     Adrian Georgescu <ag@ag-projects.com>

Hi Paul,

I had a look at it. I = am an engineer and look at practical maters. I use
MSRP chat and file = transfers almost every day with Blink and Blink uses
OTR by default. = That means that media is end-to end encrypted and this
happens by = default rather than users having to enable it. If someone
tampers = with the encryption, user is alerted and will he/she is likely
to = bail out of the conversation if is intercepted. Therefore = scenario
3.2 where an MSRP relay is used for intercept purpose does = not hold
because of possible usage of end-to-end encryption in the = clients.
Unless you control at least one of the end-points, you = cannot intercept.
Mandating that MSRP relays support a feature it = cannot enforce is kind
of flaw. I would leave it out or explaining = why it does not work.

I'm not familiar with OTR = other than what wikipedia tells me, and it doesn't say how it works with = MSRP.

I'm guessing that it is just encrypting the body of = messages? (So that MSRP relays can still be used - but can't understand = the content of the body.)

Correct. = Same as RTP relays can store RTP with zRTP encrypted data where the = encryption key is not known by the SIP server as the key is not = exchanged in clear text inside = signalling.


If so, = then I don't think this changes much. A relay could still record what it = gets, even if the recorded content is unintelligible to = most.

Yes, technically they could = stored the encrypted data.


Suppose = that were the case. Would the recorded content be decodable by full = knowledge of the keys of sender and = receiver?


Not always or not = likely depending on implementation. Not when using a forward secrecy = mechanism for example. One cannot decode future communication with an = old key:



Also, we don't mandate which elements do = recording. We only try to describe possibilities. =

This is why possibilities likely to = fail deterministically should be dismissed.

So perhaps in the your case useful recordings could only = be done by the endpoints. (That might be the desired effect for those = using OTR.)

If so, perhaps that deserves some consideration. As = currently described, the recording is applied to the MSRP messages, as = seen by *somebody* in the path those messages traverse. If those = messages are encrypted, then perhaps that is the wrong strategy. Perhaps = in that case it is the *unencrypted* messages that need to be recorded. = (Possibly encrypted again for the recorder.) That would require some = changes to the proposal.

One relay = can guess if OTR is negotiated as the data is cleartext inside the MSRP = data but beyond this, if the relay tries to interfere with the initial = OTR negotiation, both end-points will = know.


The scenario where recording makes most sense is = multi-party chat
conversations. There you explicitly give up on = privacy for the sake of
sharing capabilities and recording is a = useful feature. If an MSRP
switch is used, than the relay is not = mandatory so again scenario 3.2 is
not realistic.  I would but = scenario 3.3 in pole position in the document.

Last, I would like = to see a provision in the draft to make possible for
an end-user to = indicate that it does not want its message to be stored
by the other = side (the reverse feature of a party initiating
interception and = telling the other side about it).

Are you familiar = with the base siprec drafts? (Particularly = draft-ietf-siprec-protocol-14.) There is a mechanism (a=3Drecordpref) to = indicate a preference for recording, or for *not* recording. It applies = to audio and video, and with the msrp-recording draft it will apply also = to that.

This requires a re-INVITE, = which may fail later in the middle of the session, or be out of sync = with media plane, while the media continues to flow. It is a bad = strategy as signalling and data are disconnected. So mandating to use = SIP packet that may get lost to control MSRP chat messages in progress, = is not gonna work properly. I want to know deterministically that my = next MSRP message is not going to be stored (or fail to send at all), = regardless of the SIP signalling or other middle box protocols that = helped setup the MSRP media in the first place.


Thanks,
= Paul

We use this feature
in = Blink today and I find it useful as sometimes I want to = write
something that I know that the other party would not save in = its history
database like a password or other data that need to be = consumed and not
reused latter.

Adrian

On 02 Sep 2014, = at 11:20, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

Adrian,

I've been = working on a draft for the siprec wg about the recording = of
msrp.

Ben Campbell suggested that I contact you because you = have more
real-life experience with msrp than most people.

I = would appreciate any comments you have on this draft.

For = context, if you haven't followed siprec, you may have to look at
some = of the previous siprec drafts to understand what it is about. = And
I'll be happy to answer any questions you might = have.

Thanks,
Paul


-------- Original Message = --------
Subject: [siprec] New Version Notification = for
draft-yan-siprec-msrp-recording-02.txt
Date: Wed, 27 Aug 2014 = 16:28:41 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>= >
To: siprec@ietf.org = <mailto:siprec@ietf.org> = <siprec@ietf.org
<mailto:siprec@ietf.org>>

= I just submitted a revised version of the MSRP recording = draft.

The following is a summary of what is different in this = version. (It is
in the draft too.)

 This version = addresses comments received on the -01 version, both on
 the = mailing list and at IETF90.  The following is my list of things
=  to address:

 o  Define a new MIME type that is = used to wrap the CS MSRP messages
    that are = being recorded.  This allows the original message to be
=     left as-is, so it is always clear what it was. =  While CPIM could
    be used for this, = defining a new type will allow capturing other
=     necessary metadata.

 o  Need = to further consider the need to track message timing.  Can
=     the timing of messages received by the SRS on = the RS MSRP stream
    be considered a = sufficient proxy for the timing of messages in the
=     CS, or should we explicitly pass timestamps of = messages as
    received on the CS?  (The = issue was raised but not decided.)

 o  We need to = clarify that there is no guarantee that messages
=     received on the CS have been recorded.

=  o  It was agreed that there is no need to record the MSRP = URIs that
    are used to establish the CS MSRP = session.

 o  It is important that we maintain a 1:1 = consistency between MSRP
    MESSAGE-IDs used in = recorded CS sessions and the MESSAGE-IDs used
=     in the RS.  But we should not violate MSRP = by using the same
    MESSAGE-IDs.  We came = up with the idea of adding an SRC-specific
=     prefix to the CS message ids to create unique = ones for the RS.
    This should be done in a = standard way so that the SRS can recover
    the = original CS message ids, in order to support correlation
=     across redundant SRCs.

 o =  Will need to work out the details of what happens when a CS = MSRP
    session is terminated with an = incomplete message.  It will be
=     necessary to send the incomplete message to the = SRS, but must it
    appear to be incomplete = within the SRS MSRP session?

 o  There are a variety = of reasons why the SRC may not want, or be
=     able to, record individual messages in the CS = session.  (One
    example is because the = message size is greater than the maximum
=     indicated by the SRS.  Another is because = the mime type of the
    message is a type that = the SRS did not indicate support for.)
    There = should be a type of placeholder message that can be sent to
=     the SRS to indicate a message has been dropped, = why, and some key
    attributes about the = message.  The new SIPREC wrapper mime type
=     could be designed to serve this purpose.

=  o  REPORT messages on the CS can't be sent directly on the = RS.  The
    new SIPREC wrapper mime type = could also serve as a way to
    encapsulate = those.

 The primary change is to introduce a new wrapper = MIME type
 ("application/msrp-recording") that is used in RS = MSRP sessions for
 all CS MSRP messages that are to be = recorded.  This is used with SEND
 messages whether they = have a CPIM wrapper or not.  It also allows
 non-SEND = messages from the CS to be sent intact in the RS for
=  recording.  And it provides a vehicle for carrying other data = as
 needed.

 Adding another layer of wrapper could = substantially increase the
 total amount of data send on the RS = session, relative to what is
 present on the CS.  I've = tried to mitigate that via the details of
 the design. =  For SEND messages, only the body of the SEND message is
=  wrapped.  And =46rom and To headers in this wrapper can be = omitted in
 cases where that information is redundant. =  I've assumed that
 messages other than SEND should in = general be infrequent enough that
 extra overhead when sending = them isn't worth a lot of concern.

 This wrapper can carry = a DateTime header.  This provides a mechanism
 to address = the timestamp issues.  I've left it as optional to use.

=  I clarified the non-guarantee of recording in the architecture
=  section.

 I've provided a special header in the = wrapper to carry the MESSAGE-ID
 from SEND messages in the CS. =  And SEND messages will get a separate
 MESSAGE-ID on the = RS MSRP session when sent to the SRS.  This
 provides the = SRS with enough information to solve the correlation
 problem = when a message is incomplete in one CS MSRP session and is
=  resumed on another.  (The problem of reassembly is left to = the SRS.)

 The wrapper format includes a mechanism for the = SRC to report dropped
 messages to the SRS.

 The = wrapper format also includes a mechanism for encapsulating CS
=  REPORT messages for sending to the SRS.

 I realized = that this level of wrapping provides an opportunity to
=  multiplex unrelated CS MSRP sessions on a single RS MSRP session. =  To
 allow this I've provided a way to include the = session-id from the
 metadata, that identifies the particular = CS MSRP session, as a value
 in the wrapper of the message sent = on the RS.  But I also made that
 optional when it is = redundant.  This gives a choice: multiplex but
 make the = messages bigger, or create a separate RS MSRP session for
 each = CS MSRP session and keep the messages smaller.  I've included
=  this as a trial balloon for discussion.  I'm undecided about = it.

 The formatting of all of this could be better. =  But for now I just
 wanted to get the basic concepts down = for review.  Once the approach
 is reasonably well worked = out I'll try to improve the formatting.

 There are many = places here where I am uncertain what normative
 strength to = apply to individual requirements.  I've indicated this
=  inline for many of those.  Please comment on this.

I = believe this is in line with what was discussed in Toronto.

I = especially want to hear whether people find this an = acceptable
direction, as well as thoughts on the details. And = anything I might have
overlooked that still needs to be = addressed.

Thanks,
Paul

-------- Original Message = --------
Subject: New Version Notification = for
draft-yan-siprec-msrp-recording-02.txt
Date: Wed, 27 Aug 2014 = 13:19:15 -0700
From: internet-drafts@ietf.org = <mailto:internet-drafts@ietf.org>
To: Michael Yan <michael.yan@huawei.com
<<= a = href=3D"mailto:michael.yan@huawei.com">mailto:michael.yan@huawei.com&g= t;>,        "Paul H. = Kyzivat"
<pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>= >,
      "Michael Yan" <michael.yan@huawei.com
<<= a = href=3D"mailto:michael.yan@huawei.com">mailto:michael.yan@huawei.com&g= t;>,
     "Paul Kyzivat" <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= >


A new version of I-D, = draft-yan-siprec-msrp-recording-02.txt
has been successfully = submitted by Paul H. Kyzivat and posted to the
IETF = repository.

Name:draft-yan-siprec-msrp-recording
Revision:02
= Title:Overview for MSRP Recording based on SIPREC
Document = date:2014-08-27
Group:Individual Submission
Pages:17
URL:
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-record= ing-02.txt

Status:
https://datatracker.ietf.org/doc/draft-ya= n-siprec-msrp-recording/
Htmlized:
http://tools.ietf.org/html/draft-= yan-siprec-msrp-recording-02
Diff:
http://www.ietf.org/rfcdiff?url2=3D= draft-yan-siprec-msrp-recording-02

Abstract:
 SIPREC is = capable of recording interactive text media that is
=  transmitted via RTP.  However that format is not commonly = used for
 message or chat scenarios.  There is also a need = for recording text
 media carried via MSRP.  One case of = note is exchange of text between
 hearing-impaired users and = emergence service bureaus.  Also,
 recording support is = needed for MSRP used in chat conferences and
 multimedia = conferences.

 This document describes how to achieve MSRP = channel recording within
 the mechanism of SIP Recording = (SIPREC).






Please note that it may take a = couple of minutes from the time of
submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat




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



--
Adrian







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


________________________= _______________________
siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec


encryption and verification part. Keeping records of the conversations > is in my view a separate feature from the end user point of view which > does not necessarily require OTR. > >> >> Thanks, >> Paul >> > > -- > Adrian > > > From nobody Sat Sep 27 10:16:25 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F0F1A1BEE for ; Sat, 27 Sep 2014 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yen6P9AgsUyT for ; Sat, 27 Sep 2014 10:16:20 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19BF1A0174 for ; Sat, 27 Sep 2014 10:16:20 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with comcast id wHGL1o0064tLnxL01HGL41; Sat, 27 Sep 2014 17:16:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id wHGK1o00C3Ge9ey01HGK0f; Sat, 27 Sep 2014 17:16:20 +0000 Message-ID: <5426F0E3.4070601@alum.mit.edu> Date: Sat, 27 Sep 2014 13:16:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Georgescu References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> In-Reply-To: <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.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=q20140121; t=1411838180; bh=D0kmSzAlW4xEKm9S7Xu19dyBnUwFoYD1hLjpa+n7uEQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Is21uqUlRd2TveZ/SlZ18tcp/1qmFw0LU2zcBY7fAeSS0Zd4hEvb8Q3444rXJCAwd ctxcdaeTNVh8wHwETJ9DvwhIoPI2AbCIPYy0hJknkuv//hDUVyq6fgYBP/hiVVv9YE xTtJNxA3yZTF/RHn6Ni6lN+f0QIKycECzpvx6v0oQ1OFBnwu5dzHFeZPQiFEpbysS2 n5cYrBljySnwx9GqqoyoS2Jt4FVGlybsQ0v0eMTPhO1TTowMBYL80ML6VG4fgRMHnA 1di42aOqRiyBG4/XPp3xvDTqtRLSp7Ndn2Vvyi756j0OPGqHSXICwx4vFtDm4a/Bjz 44THuI9Qvk1NA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/fwHffC7n4cGwgmjKHfeY9aOlbdc Cc: siprec@ietf.org Subject: [siprec] MSRP privacy issues X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Sep 2014 17:16:21 -0000 On 9/27/14 7:39 AM, Adrian Georgescu wrote: > > On 26 Sep 2014, at 13:54, Paul Kyzivat > wrote: >> How is OTR integrated into MSRP? >> How is it negotiated? > > Inside the message chat stream, is just ascii like any normal message. > Once the MSRP stream is up any party can start negotiating OTR at any > point during the lifetime of the session. > >> Does it use a new wrapper MIME type? > > No > >> Is the key exchange done in SDP or in MSRP messages? > > Plain MSRP chat stream I guess I should have asked if you use any new MIME types. Presumably you need to send messages for key exchange. These need to be processed differently from messages that are supposed to be displayed to the end user. How are these special messages identified? > The support for this feature is negotiated in the SDP of the MSRP media > block, e.g.: > > Offer: > > o=- 3620806345 3620806345 IN IP4 192.168.8.3 > s=Blink 4.7.4 (MacOSX) > m=message 2855 TCP/TLS/MSRP * > c=IN IP4 192.168.8.3 > a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp > a=accept-types:message/cpim text/* application/im-iscomposing+xml > a=accept-wrapped-types:* > a=setup:active > a=features:history-control icon > > Answer: > > o=- 3620806346 3620806347 IN IP4 10.0.0.139 > s=SylkServer-2.6.0 > c=IN IP4 10.0.0.139 > m=message 51634 TCP/TLS/MSRP * > a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp > a=accept-types:message/cpim > a=accept-wrapped-types:* > a=setup:passive > a=chatroom:nickname private-messages com.ag-projects.screen-sharing The above says that the offerer proposes - message/cpim is the only accepted wrapper type, - all subtypes of text are accepted unwrapped - application/im-iscomposing+xml is accepted unwrapped - any type is accepted when wrapped with a CPIM wrapper I must assume that is sufficient for you to negotiate privacy and do key exchange. So I guess you don't use any other unwrapped mime types for that. But I can't determine if you might use special types that have been wrapped with cpim. And a general question about all of this: is it a proprietary mechanism? Or is it public? Thanks, Paul From nobody Sat Sep 27 10:25:59 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983061A1BF3 for ; Sat, 27 Sep 2014 10:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPtcW2bC-dTk for ; Sat, 27 Sep 2014 10:25:56 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A291A1BF2 for ; Sat, 27 Sep 2014 10:25:56 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-09v.sys.comcast.net with comcast id wHRd1o0035BUCh401HRw8l; Sat, 27 Sep 2014 17:25:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id wHRu1o00y3Ge9ey01HRvhR; Sat, 27 Sep 2014 17:25:55 +0000 Message-ID: <5426F322.3060407@alum.mit.edu> Date: Sat, 27 Sep 2014 13:25:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Georgescu References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> In-Reply-To: <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.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=q20140121; t=1411838756; bh=f8V9n0iU7qLYG4gJcD7dczjtdL9oV/xcVJ8bnntXsYU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Lhkg6XgV6h9e+mhwb4vRb1VOreeYLAQLdDXn8h3gzxAfEoBNT0yiLMB90HtMUmuPZ gt9EkUtPWpgSCxzMtQ6lYnn3ziReQIELtOc+MTnkfaFgnKS5XoKnb3PDABPnAZmLNk 3fqc7bKivL8BlPqjusMJzZhufOX4/oDaUIR0DSJk67BM3CgzpRaP1U1tSubDrtQ0Dc 1G/ly+YCsK07VzYjjj4fAWoxJTGx40v2uHsWnmdK6kvd3hpqjfY0gycGnAyuf1uUM0 YSoBwGXeDPa/TCNnNRWDNlN2Hj+Gei3xCCW5+gyrTrI2D38c0QPayvRo/Awse639Ez TCvx8NtJOeqbA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ztuvtpFCV-tOmt9Y3Xd7CDR7C_0 Cc: siprec@ietf.org Subject: [siprec] Declaring desired MSRP recording status within MSRP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Sep 2014 17:25:57 -0000 On 9/27/14 7:39 AM, Adrian Georgescu wrote: > > On 26 Sep 2014, at 13:54, Paul Kyzivat > wrote: >>>> Are you familiar with the base siprec drafts? (Particularly >>>> draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to >>>> indicate a preference for recording, or for *not* recording. It >>>> applies to audio and video, and with the msrp-recording draft it will >>>> apply also to that. >>> >>> This requires a re-INVITE, which may fail later in the middle of the >>> session, or be out of sync with media plane, while the media continues >>> to flow. It is a bad strategy as signalling and data are disconnected. >> >> Well, this is what was mandated for audio and video. For those, AFAIK >> there is no way to carry the signaling for this in the media. > > MSRP is different as each message can carry by design any type of media > described by its content-type inside the CPIM envelope. > >> >>> So mandating to use SIP packet that may get lost to control MSRP chat >>> messages in progress, is not gonna work properly. I want to know >>> deterministically that my next MSRP message is not going to be stored >>> (or fail to send at all), regardless of the SIP signalling or other >>> middle box protocols that helped setup the MSRP media in the first place. >> >> With the current siprec mechanism, the do-not-record indication on the >> CS is a *request* from a UA to the SRC. The SRC doesn't have to honor >> it. However it is required to signal its actual >> recording/not-recording state. So the requesting UA can decide not to >> transmit sensitive information (or terminate the session) if it >> doesn't get an indication that recording has stopped. And similarly if >> the re-INVITE fails. > > For RTP sounds reasonable. For MSRP however is not ideal as it is much > safer and reliable to send a MSRP message for which there is end-to-end > integrity, sequencing and delivery reporting capability. >> So how do you do this? Have you defined an MSRP or CPIM extension? Or >> have you defined a special MIME type for a body that communicates this? > > I just send a CPIM message like these: > > content_type='application/history-on' > > or > > content_type='application/history-off' > > The support for this feature is negotiated in the SDP of the MSRP media > block, e.g.: > > Offer: > > o=- 3620806345 3620806345 IN IP4 192.168.8.3 > s=Blink 4.7.4 (MacOSX) > m=message 2855 TCP/TLS/MSRP * > c=IN IP4 192.168.8.3 > a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp > a=accept-types:message/cpim text/* application/im-iscomposing+xml > a=accept-wrapped-types:* > a=setup:active > a=features:history-control icon > > Answer: > > o=- 3620806346 3620806347 IN IP4 10.0.0.139 > s=SylkServer-2.6.0 > c=IN IP4 10.0.0.139 > m=message 51634 TCP/TLS/MSRP * > a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp > a=accept-types:message/cpim > a=accept-wrapped-types:* > a=setup:passive > a=chatroom:nickname private-messages com.ag-projects.screen-sharing IIUC, a message with content type of application/history-off would not be valid within the MSRP session negotiated above. (Unless it was sent within a CPIM wrapper.) Ignoring that, what are the semantics? Are you sending an *empty* message with this content type, to set a mode? Or is this the type of a message containing a body that is to be displayed but not added to the history? If the latter, then how do you know the actual type of the content? How normative is this? Is it advisory to the recipient? Or binding? Doe it need to be acknowledged? Thanks, Paul From nobody Sun Sep 28 08:16:39 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFAA1A1AE8 for ; Sat, 27 Sep 2014 04:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsqtNaiU-Gc4 for ; Sat, 27 Sep 2014 04:40:11 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 675D41A1AD1 for ; Sat, 27 Sep 2014 04:40:11 -0700 (PDT) Received: from [192.168.8.3] (r167-108-88-18.dialup.mobile.ancel.net.uy [167.108.88.18]) by mail.sipthor.net (Postfix) with ESMTPSA id BAEBB16DC720; Sat, 27 Sep 2014 13:40:05 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_CE3C76A4-E8B9-4B35-80C8-6119B67E2E30"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Adrian Georgescu In-Reply-To: <54259A33.5010503@alum.mit.edu> Date: Sat, 27 Sep 2014 08:39:53 -0300 Message-Id: <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/dijH299_EM3GAYbiOewmuEuy8EQ X-Mailman-Approved-At: Sun, 28 Sep 2014 08:16:34 -0700 Cc: siprec@ietf.org Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Sep 2014 11:40:15 -0000 --Apple-Mail=_CE3C76A4-E8B9-4B35-80C8-6119B67E2E30 Content-Type: multipart/alternative; boundary="Apple-Mail=_F64B3BFC-F047-4093-ACBC-9FD3F6D8946B" --Apple-Mail=_F64B3BFC-F047-4093-ACBC-9FD3F6D8946B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 26 Sep 2014, at 13:54, Paul Kyzivat wrote: > Adrian, >=20 > Thanks for your input. Please find more comments inline. >=20 > On 9/25/14 7:24 PM, Adrian Georgescu wrote: > [snip] >>>> I had a look at it. I am an engineer and look at practical maters. = I use >>>> MSRP chat and file transfers almost every day with Blink and Blink = uses >>>> OTR by default. That means that media is end-to end encrypted and = this >>>> happens by default rather than users having to enable it. If = someone >>>> tampers with the encryption, user is alerted and will he/she is = likely >>>> to bail out of the conversation if is intercepted. Therefore = scenario >>>> 3.2 where an MSRP relay is used for intercept purpose does not hold >>>> because of possible usage of end-to-end encryption in the clients. >>>> Unless you control at least one of the end-points, you cannot = intercept. >>>> Mandating that MSRP relays support a feature it cannot enforce is = kind >>>> of flaw. I would leave it out or explaining why it does not work. >>>=20 >>> I'm not familiar with OTR other than what wikipedia tells me, and it >>> doesn't say how it works with MSRP. >>>=20 >>> I'm guessing that it is just encrypting the body of messages? (So = that >>> MSRP relays can still be used - but can't understand the content of >>> the body.) >>=20 >> Correct. Same as RTP relays can store RTP with zRTP encrypted data = where >> the encryption key is not known by the SIP server as the key is not >> exchanged in clear text inside signalling. >=20 > How is OTR integrated into MSRP? > How is it negotiated? Inside the message chat stream, is just ascii like any normal message. = Once the MSRP stream is up any party can start negotiating OTR at any = point during the lifetime of the session.=20 > Does it use a new wrapper MIME type? No > Is the key exchange done in SDP or in MSRP messages? Plain MSRP chat stream >=20 >>> If so, then I don't think this changes much. A relay could still >>> record what it gets, even if the recorded content is unintelligible = to >>> most. >>=20 >> Yes, technically they could stored the encrypted data. >>=20 >>>=20 >>> Suppose that were the case. Would the recorded content be decodable = by >>> full knowledge of the keys of sender and receiver? >>>=20 >>=20 >> Not always or not likely depending on implementation. Not when using = a >> forward secrecy mechanism for example. One cannot decode future >> communication with an old key: >>=20 >> https://en.wikipedia.org/wiki/Perfect_forward_secrecy >>=20 >>=20 >>> Also, we don't mandate which elements do recording. We only try to >>> describe possibilities. >>=20 >> This is why possibilities likely to fail deterministically should be >> dismissed. >=20 > Well, that judgement may be right in cases where OTR is in use. But I = don't think we can assume that it always is. The actual choice of if, = where and how to install SRCs in middleboxes will be made by = administrators who have some knowledge of how the system is being used. >=20 > But based on this discussion I think we should probably add some text = noting that this case will not be useful if e2e encryption of messages = is being used. >=20 >>> So perhaps in the your case useful recordings could only be done by >>> the endpoints. (That might be the desired effect for those using = OTR.) >>>=20 >>> If so, perhaps that deserves some consideration. As currently >>> described, the recording is applied to the MSRP messages, as seen by >>> *somebody* in the path those messages traverse. If those messages = are >>> encrypted, then perhaps that is the wrong strategy. Perhaps in that >>> case it is the *unencrypted* messages that need to be recorded. >>> (Possibly encrypted again for the recorder.) That would require some >>> changes to the proposal. >>=20 >> One relay can guess if OTR is negotiated as the data is cleartext = inside >> the MSRP data but beyond this, if the relay tries to interfere with = the >> initial OTR negotiation, both end-points will know. >=20 > I must not have been clear enough. I was assuming that when OTR is in = use that recording could only be done by the endpoints (who have access = to the unencrypted form of the messages). The existing text talks about = recording of the body of the SEND messages. In the case of encrypted = messages, it would have to be the unencrypted form of the body. >=20 > Also, the base siprec specs say that the protection of the RS must = always be at least as strong as that of the CS. When using OTR on the = CS, will that mean also using OTR on the RS? >=20 >>>> The scenario where recording makes most sense is multi-party chat >>>> conversations. There you explicitly give up on privacy for the sake = of >>>> sharing capabilities and recording is a useful feature. If an MSRP >>>> switch is used, than the relay is not mandatory so again scenario = 3.2 is >>>> not realistic. I would but scenario 3.3 in pole position in the >>>> document. >>>>=20 >>>> Last, I would like to see a provision in the draft to make possible = for >>>> an end-user to indicate that it does not want its message to be = stored >>>> by the other side (the reverse feature of a party initiating >>>> interception and telling the other side about it). >>>=20 >>> Are you familiar with the base siprec drafts? (Particularly >>> draft-ietf-siprec-protocol-14.) There is a mechanism (a=3Drecordpref) = to >>> indicate a preference for recording, or for *not* recording. It >>> applies to audio and video, and with the msrp-recording draft it = will >>> apply also to that. >>=20 >> This requires a re-INVITE, which may fail later in the middle of the >> session, or be out of sync with media plane, while the media = continues >> to flow. It is a bad strategy as signalling and data are = disconnected. >=20 > Well, this is what was mandated for audio and video. For those, AFAIK = there is no way to carry the signaling for this in the media. MSRP is different as each message can carry by design any type of media = described by its content-type inside the CPIM envelope. >=20 >> So mandating to use SIP packet that may get lost to control MSRP chat >> messages in progress, is not gonna work properly. I want to know >> deterministically that my next MSRP message is not going to be stored >> (or fail to send at all), regardless of the SIP signalling or other >> middle box protocols that helped setup the MSRP media in the first = place. >=20 > With the current siprec mechanism, the do-not-record indication on the = CS is a *request* from a UA to the SRC. The SRC doesn't have to honor = it. However it is required to signal its actual recording/not-recording = state. So the requesting UA can decide not to transmit sensitive = information (or terminate the session) if it doesn't get an indication = that recording has stopped. And similarly if the re-INVITE fails. For RTP sounds reasonable. For MSRP however is not ideal as it is much = safer and reliable to send a MSRP message for which there is end-to-end = integrity, sequencing and delivery reporting capability.=20 >=20 > We *could* define a different mechanism for use with with MSRP = recording. That would require defining an extension to MSRP for the = purpose. That is a possibility, though it raises the bar a bit. >=20 >>>> We use this feature >>>> in Blink today and I find it useful as sometimes I want to write >>>> something that I know that the other party would not save in its = history >>>> database like a password or other data that need to be consumed and = not >>>> reused latter. >=20 > So how do you do this? Have you defined an MSRP or CPIM extension? Or = have you defined a special MIME type for a body that communicates this? I just send a CPIM message like these: content_type=3D'application/history-on' or content_type=3D'application/history-off' The support for this feature is negotiated in the SDP of the MSRP media = block, e.g.: Offer: o=3D- 3620806345 3620806345 IN IP4 192.168.8.3 s=3DBlink 4.7.4 (MacOSX) m=3Dmessage 2855 TCP/TLS/MSRP * c=3DIN IP4 192.168.8.3 a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml a=3Daccept-wrapped-types:* a=3Dsetup:active a=3Dfeatures:history-control icon Answer: o=3D- 3620806346 3620806347 IN IP4 10.0.0.139 s=3DSylkServer-2.6.0 c=3DIN IP4 10.0.0.139 m=3Dmessage 51634 TCP/TLS/MSRP * a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp a=3Daccept-types:message/cpim a=3Daccept-wrapped-types:* a=3Dsetup:passive a=3Dchatroom:nickname private-messages com.ag-projects.screen-sharing PS. OTR stands for "Off The Record" but I really mean the end-to-end = encryption and verification part. Keeping records of the conversations = is in my view a separate feature from the end user point of view which = does not necessarily require OTR.=20 >=20 > Thanks, > Paul >=20 -- Adrian --Apple-Mail=_F64B3BFC-F047-4093-ACBC-9FD3F6D8946B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 26 Sep 2014, at 13:54, Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

Adrian,

Thanks for your input. Please find more = comments inline.

On 9/25/14 7:24 PM, Adrian Georgescu = wrote:
[snip]
I had a look at it. I am an = engineer and look at practical maters. I use
MSRP chat and file = transfers almost every day with Blink and Blink uses
OTR by default. = That means that media is end-to end encrypted and this
happens by = default rather than users having to enable it. If someone
tampers = with the encryption, user is alerted and will he/she is likely
to = bail out of the conversation if is intercepted. Therefore = scenario
3.2 where an MSRP relay is used for intercept purpose does = not hold
because of possible usage of end-to-end encryption in the = clients.
Unless you control at least one of the end-points, you = cannot intercept.
Mandating that MSRP relays support a feature it = cannot enforce is kind
of flaw. I would leave it out or explaining = why it does not work.

I'm not familiar with OTR = other than what wikipedia tells me, and it
doesn't say how it works = with MSRP.

I'm guessing that it is just encrypting the body of = messages? (So that
MSRP relays can still be used - but can't = understand the content of
the body.)

Correct. = Same as RTP relays can store RTP with zRTP encrypted data where
the = encryption key is not known by the SIP server as the key is = not
exchanged in clear text inside = signalling.

How is OTR integrated into MSRP?
How = is it negotiated?

Inside the message = chat stream, is just ascii like any normal message. Once the MSRP stream = is up any party can start negotiating OTR at any point during the = lifetime of the session. 

Does = it use a new wrapper MIME = type?

No

Is the key exchange done in SDP or in MSRP = messages?

Plain MSRP chat = stream


If so, then I don't think this = changes much. A relay could still
record what it gets, even if the = recorded content is unintelligible to
most.

Yes, = technically they could stored the encrypted data.


Suppose that were the case. Would the recorded content = be decodable by
full knowledge of the keys of sender and = receiver?


Not always or not likely depending on = implementation. Not when using a
forward secrecy mechanism for = example. One cannot decode future
communication with an old = key:

https://en.= wikipedia.org/wiki/Perfect_forward_secrecy


Also, we don't mandate which elements do recording. We = only try to
describe possibilities.

This is why = possibilities likely to fail deterministically should = be
dismissed.

Well, that judgement may be right = in cases where OTR is in use. But I don't think we can assume that it = always is. The actual choice of if, where and how to install SRCs in = middleboxes will be made by administrators who have some knowledge of = how the system is being used.

But based on this discussion I = think we should probably add some text noting that this case will not be = useful if e2e encryption of messages is being used.

So perhaps in the your case = useful recordings could only be done by
the endpoints. (That might be = the desired effect for those using OTR.)

If so, perhaps that = deserves some consideration. As currently
described, the recording is = applied to the MSRP messages, as seen by
*somebody* in the path those = messages traverse. If those messages are
encrypted, then perhaps that = is the wrong strategy. Perhaps in that
case it is the *unencrypted* = messages that need to be recorded.
(Possibly encrypted again for the = recorder.) That would require some
changes to the = proposal.

One relay can guess if OTR is negotiated = as the data is cleartext inside
the MSRP data but beyond this, if the = relay tries to interfere with the
initial OTR negotiation, both = end-points will know.

I must not have been clear = enough. I was assuming that when OTR is in use that recording could only = be done by the endpoints (who have access to the unencrypted form of the = messages). The existing text talks about recording of the body of the = SEND messages. In the case of encrypted messages, it would have to be = the unencrypted form of the body.

Also, the base siprec specs say = that the protection of the RS must always be at least as strong as that = of the CS. When using OTR on the CS, will that mean also using OTR on = the RS?

The scenario where recording = makes most sense is multi-party chat
conversations. There you = explicitly give up on privacy for the sake of
sharing capabilities = and recording is a useful feature. If an MSRP
switch is used, than = the relay is not mandatory so again scenario 3.2 is
not realistic. =  I would but scenario 3.3 in pole position in = the
document.

Last, I would like to see a provision in the = draft to make possible for
an end-user to indicate that it does not = want its message to be stored
by the other side (the reverse feature = of a party initiating
interception and telling the other side about = it).

Are you familiar with the base siprec drafts? = (Particularly
draft-ietf-siprec-protocol-14.) There is a mechanism = (a=3Drecordpref) to
indicate a preference for recording, or for *not* = recording. It
applies to audio and video, and with the msrp-recording = draft it will
apply also to that.

This requires a = re-INVITE, which may fail later in the middle of the
session, or be = out of sync with media plane, while the media continues
to flow. It = is a bad strategy as signalling and data are = disconnected.

Well, this is what was mandated for = audio and video. For those, AFAIK there is no way to carry the signaling = for this in the media.

MSRP is different = as each message can carry by design any type of media described by its = content-type inside the CPIM envelope.


So mandating to use SIP = packet that may get lost to control MSRP chat
messages in progress, = is not gonna work properly. I want to know
deterministically that my = next MSRP message is not going to be stored
(or fail to send at all), = regardless of the SIP signalling or other
middle box protocols that = helped setup the MSRP media in the first place.

With = the current siprec mechanism, the do-not-record indication on the CS is = a *request* from a UA to the SRC. The SRC doesn't have to honor it. = However it is required to signal its actual recording/not-recording = state. So the requesting UA can decide not to transmit sensitive = information (or terminate the session) if it doesn't get an indication = that recording has stopped. And similarly if the re-INVITE = fails.

For RTP sounds reasonable. = For MSRP however is not ideal as it is much safer and reliable to send a = MSRP message for which there is end-to-end integrity, sequencing and = delivery reporting capability. 


We *could* define a different mechanism for use with = with MSRP recording. That would require defining an extension to MSRP = for the purpose. That is a possibility, though it raises the bar a = bit.

We use this feature
in Blink = today and I find it useful as sometimes I want to write
something = that I know that the other party would not save in its = history
database like a password or other data that need to be = consumed and not
reused = latter.

So how do you do = this? Have you defined an MSRP or CPIM extension? Or have you defined a = special MIME type for a body that communicates = this?

I just send a CPIM message = like these:

content_type=3D'application/history-on'

or

content_type=3D'application/history-off'

<= div>The support for this feature is negotiated in the SDP of the MSRP = media block, = e.g.:

Offer:

o=3D- = 3620806345 3620806345 IN IP4 192.168.8.3
s=3DBlink 4.7.4 = (MacOSX)
m=3Dmessage 2855 TCP/TLS/MSRP *
c=3DIN IP4 = 192.168.8.3
a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp
a=3Daccept-types:message/cpim text/* = application/im-iscomposing+xml
a=3Daccept-wrapped-types:*
a=3Dsetup:active
a=3Dfeatures:history-control icon

Answer:

o=3D- 3620806346 3620806347 IN IP4 = 10.0.0.139
s=3DSylkServer-2.6.0
c=3DIN IP4 10.0.0.139
m=3Dmessage 51634 TCP/TLS/MSRP *
a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
<= div style=3D"margin: 0px;">a=3Daccept-types:message/cpim
a=3Daccept-wrapped-types:*
a=3Dsetup:passive
a=3Dchatroom:nickname private-messages = com.ag-projects.screen-sharing


PS.

OTR stands for "Off The Record" but I = really mean the end-to-end encryption and verification part. Keeping = records of the conversations is in my view a separate feature from the = end user point of view which does not necessarily require = OTR. 


= Thanks,
= Paul


In-Reply-To: <5426F0E3.4070601@alum.mit.edu> Date: Sat, 27 Sep 2014 14:47:57 -0300 Message-Id: References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> <5426F0E3.4070601@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/cdfQ9v9tIxRu-Xa31tqmO7oZuSk X-Mailman-Approved-At: Sun, 28 Sep 2014 08:16:34 -0700 Cc: siprec@ietf.org Subject: Re: [siprec] MSRP privacy issues X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Sep 2014 17:48:12 -0000 --Apple-Mail=_6C152162-22FA-4D74-9CF0-37753A748897 Content-Type: multipart/alternative; boundary="Apple-Mail=_ADF8F608-8772-4F76-BFD8-A73306EE7716" --Apple-Mail=_ADF8F608-8772-4F76-BFD8-A73306EE7716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 27 Sep 2014, at 14:16, Paul Kyzivat wrote: > On 9/27/14 7:39 AM, Adrian Georgescu wrote: >>=20 >> On 26 Sep 2014, at 13:54, Paul Kyzivat > > wrote: >=20 >>> How is OTR integrated into MSRP? >>> How is it negotiated? >>=20 >> Inside the message chat stream, is just ascii like any normal = message. >> Once the MSRP stream is up any party can start negotiating OTR at any >> point during the lifetime of the session. >>=20 >>> Does it use a new wrapper MIME type? >>=20 >> No >>=20 >>> Is the key exchange done in SDP or in MSRP messages? >>=20 >> Plain MSRP chat stream >=20 > I guess I should have asked if you use any new MIME types. No > Presumably you need to send messages for key exchange. These need to = be processed differently from messages that are supposed to be displayed = to the end user. How are these special messages identified? OTR protocol defined special sequence of chars like ?OTRv2? >> The support for this feature is negotiated in the SDP of the MSRP = media >> block, e.g.: >>=20 >> Offer: >>=20 >> o=3D- 3620806345 3620806345 IN IP4 192.168.8.3 >> s=3DBlink 4.7.4 (MacOSX) >> m=3Dmessage 2855 TCP/TLS/MSRP * >> c=3DIN IP4 192.168.8.3 >> a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp >> a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml >> a=3Daccept-wrapped-types:* >> a=3Dsetup:active >> a=3Dfeatures:history-control icon >>=20 >> Answer: >>=20 >> o=3D- 3620806346 3620806347 IN IP4 10.0.0.139 >> s=3DSylkServer-2.6.0 >> c=3DIN IP4 10.0.0.139 >> m=3Dmessage 51634 TCP/TLS/MSRP * >> a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp >> a=3Daccept-types:message/cpim >> a=3Daccept-wrapped-types:* >> a=3Dsetup:passive >> a=3Dchatroom:nickname private-messages com.ag-projects.screen-sharing >=20 > The above says that the offerer proposes > - message/cpim is the only accepted wrapper type, > - all subtypes of text are accepted unwrapped > - application/im-iscomposing+xml is accepted unwrapped > - any type is accepted when wrapped with a CPIM wrapper >=20 > I must assume that is sufficient for you to negotiate privacy and do = key exchange. So I guess you don't use any other unwrapped mime types = for that. But I can't determine if you might use special types that have = been wrapped with cpim. >=20 > And a general question about all of this: is it a proprietary = mechanism? Or is it public? Above have nothing to do with any any key exchange. Is only signalling = the support for toggle history feature. >> a=3Dfeatures:history-control It is proprietary but probably it should be defined in these siprec = drafts. >=20 > Thanks, > Paul >=20 -- Adrian --Apple-Mail=_ADF8F608-8772-4F76-BFD8-A73306EE7716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 27 Sep 2014, at 14:16, Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

On 9/27/14 7:39 AM, Adrian Georgescu wrote:

On 26 Sep 2014, at 13:54, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

How is OTR integrated into MSRP?
How is it = negotiated?

Inside the message chat stream, is just = ascii like any normal message.
Once the MSRP stream is up any party = can start negotiating OTR at any
point during the lifetime of the = session.

Does it use a new wrapper MIME = type?

No

Is the key = exchange done in SDP or in MSRP messages?

Plain MSRP = chat stream

I guess I should have asked if you use = any new MIME = types.

No

Presumably you need to send messages for key exchange. = These need to be processed differently from messages that are supposed = to be displayed to the end user. How are these special messages = identified?

OTR protocol defined = special sequence of chars like ?OTRv2?


The support for this feature is = negotiated in the SDP of the MSRP media
block, = e.g.:

Offer:

o=3D- 3620806345 3620806345 IN IP4 = 192.168.8.3
s=3DBlink 4.7.4 (MacOSX)
m=3Dmessage 2855 TCP/TLS/MSRP = *
c=3DIN IP4 = 192.168.8.3
a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp<= br>a=3Daccept-types:message/cpim text/* = application/im-iscomposing+xml
a=3Daccept-wrapped-types:*
a=3Dsetup:= active
a=3Dfeatures:history-control icon

Answer:

o=3D- = 3620806346 3620806347 IN IP4 10.0.0.139
s=3DSylkServer-2.6.0
c=3DIN = IP4 10.0.0.139
m=3Dmessage 51634 TCP/TLS/MSRP = *
a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
a=3D= accept-types:message/cpim
a=3Daccept-wrapped-types:*
a=3Dsetup:passi= ve
a=3Dchatroom:nickname private-messages = com.ag-projects.screen-sharing

The above says that = the offerer proposes
- message/cpim is the only accepted wrapper = type,
- all subtypes of text are accepted unwrapped
- = application/im-iscomposing+xml is accepted unwrapped
- any type is = accepted when wrapped with a CPIM wrapper

I must assume that is = sufficient for you to negotiate privacy and do key exchange. So I guess = you don't use any other unwrapped mime types for that. But I can't = determine if you might use special types that have been wrapped with = cpim.

And a general question about all of this: is it a = proprietary mechanism? Or is it = public?

Above have nothing to do = with any any key exchange. Is only signalling the support for toggle = history feature.

a=3Dfeatures:history-control
=

It is proprietary but probably it should be defined = in these siprec drafts.



Thanks,
= Paul


In-Reply-To: <5426F322.3060407@alum.mit.edu> Date: Sat, 27 Sep 2014 14:53:32 -0300 Message-Id: <40C7B392-22C2-46CB-BA34-8FC5A519F9BF@ag-projects.com> References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> <5426F322.3060407@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/WArwQ-XoaNt5auvuc45vtN5lWzY X-Mailman-Approved-At: Sun, 28 Sep 2014 08:16:35 -0700 Cc: siprec@ietf.org Subject: Re: [siprec] Declaring desired MSRP recording status within MSRP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Sep 2014 17:53:46 -0000 --Apple-Mail=_E16648FE-9676-4CF3-B55E-82121E114635 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A9789CD-C602-4A76-B99C-1252428CE062" --Apple-Mail=_7A9789CD-C602-4A76-B99C-1252428CE062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 27 Sep 2014, at 14:25, Paul Kyzivat wrote: > On 9/27/14 7:39 AM, Adrian Georgescu wrote: >>=20 >> On 26 Sep 2014, at 13:54, Paul Kyzivat > > wrote: >=20 >>>>> Are you familiar with the base siprec drafts? (Particularly >>>>> draft-ietf-siprec-protocol-14.) There is a mechanism = (a=3Drecordpref) to >>>>> indicate a preference for recording, or for *not* recording. It >>>>> applies to audio and video, and with the msrp-recording draft it = will >>>>> apply also to that. >>>>=20 >>>> This requires a re-INVITE, which may fail later in the middle of = the >>>> session, or be out of sync with media plane, while the media = continues >>>> to flow. It is a bad strategy as signalling and data are = disconnected. >>>=20 >>> Well, this is what was mandated for audio and video. For those, = AFAIK >>> there is no way to carry the signaling for this in the media. >>=20 >> MSRP is different as each message can carry by design any type of = media >> described by its content-type inside the CPIM envelope. >>=20 >>>=20 >>>> So mandating to use SIP packet that may get lost to control MSRP = chat >>>> messages in progress, is not gonna work properly. I want to know >>>> deterministically that my next MSRP message is not going to be = stored >>>> (or fail to send at all), regardless of the SIP signalling or other >>>> middle box protocols that helped setup the MSRP media in the first = place. >>>=20 >>> With the current siprec mechanism, the do-not-record indication on = the >>> CS is a *request* from a UA to the SRC. The SRC doesn't have to = honor >>> it. However it is required to signal its actual >>> recording/not-recording state. So the requesting UA can decide not = to >>> transmit sensitive information (or terminate the session) if it >>> doesn't get an indication that recording has stopped. And similarly = if >>> the re-INVITE fails. >>=20 >> For RTP sounds reasonable. For MSRP however is not ideal as it is = much >> safer and reliable to send a MSRP message for which there is = end-to-end >> integrity, sequencing and delivery reporting capability. >=20 >>> So how do you do this? Have you defined an MSRP or CPIM extension? = Or >>> have you defined a special MIME type for a body that communicates = this? >>=20 >> I just send a CPIM message like these: >>=20 >> content_type=3D'application/history-on' >>=20 >> or >>=20 >> content_type=3D'application/history-off' >>=20 >> The support for this feature is negotiated in the SDP of the MSRP = media >> block, e.g.: >>=20 >> Offer: >>=20 >> o=3D- 3620806345 3620806345 IN IP4 192.168.8.3 >> s=3DBlink 4.7.4 (MacOSX) >> m=3Dmessage 2855 TCP/TLS/MSRP * >> c=3DIN IP4 192.168.8.3 >> a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp >> a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml >> a=3Daccept-wrapped-types:* >> a=3Dsetup:active >> a=3Dfeatures:history-control icon >>=20 >> Answer: >>=20 >> o=3D- 3620806346 3620806347 IN IP4 10.0.0.139 >> s=3DSylkServer-2.6.0 >> c=3DIN IP4 10.0.0.139 >> m=3Dmessage 51634 TCP/TLS/MSRP * >> a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp >> a=3Daccept-types:message/cpim >> a=3Daccept-wrapped-types:* >> a=3Dsetup:passive >> a=3Dchatroom:nickname private-messages com.ag-projects.screen-sharing >=20 > IIUC, a message with content type of application/history-off would not = be valid within the MSRP session negotiated above. (Unless it was sent = within a CPIM wrapper.) It is within the CPIM. > Ignoring that, what are the semantics? Are you sending an *empty* = message with this content type, to set a mode? Or is this the type of a = message containing a body that is to be displayed but not added to the = history? It asks the remote party to toggle its save to history on or off. Is a = switch that can be toggled remotely (if the recipient want to honour = it). >=20 > If the latter, then how do you know the actual type of the content? >=20 > How normative is this? Is it advisory to the recipient? Or binding? = Doe it need to be acknowledged? It is advisory as there is no way for force the other recipient to = comply with such directive. You cannot control what a remote party will = really save in its history database, is a gentlemen's agreement. >=20 > Thanks, > Paul >=20 -- Adrian --Apple-Mail=_7A9789CD-C602-4A76-B99C-1252428CE062 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 27 Sep 2014, at 14:25, Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

On 9/27/14 7:39 AM, Adrian Georgescu wrote:

On 26 Sep 2014, at 13:54, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

Are = you familiar with the base siprec drafts? = (Particularly
draft-ietf-siprec-protocol-14.) There is a mechanism = (a=3Drecordpref) to
indicate a preference for recording, or for *not* = recording. It
applies to audio and video, and with the msrp-recording = draft it will
apply also to that.

This requires a = re-INVITE, which may fail later in the middle of the
session, or be = out of sync with media plane, while the media continues
to flow. It = is a bad strategy as signalling and data are = disconnected.

Well, this is what was mandated for = audio and video. For those, AFAIK
there is no way to carry the = signaling for this in the media.

MSRP is different = as each message can carry by design any type of media
described by = its content-type inside the CPIM envelope.


So mandating to use SIP = packet that may get lost to control MSRP chat
messages in progress, = is not gonna work properly. I want to know
deterministically that my = next MSRP message is not going to be stored
(or fail to send at all), = regardless of the SIP signalling or other
middle box protocols that = helped setup the MSRP media in the first place.

With = the current siprec mechanism, the do-not-record indication on the
CS = is a *request* from a UA to the SRC. The SRC doesn't have to = honor
it. However it is required to signal its = actual
recording/not-recording state. So the requesting UA can decide = not to
transmit sensitive information (or terminate the session) if = it
doesn't get an indication that recording has stopped. And = similarly if
the re-INVITE fails.

For RTP sounds = reasonable. For MSRP however is not ideal as it is much
safer and = reliable to send a MSRP message for which there is = end-to-end
integrity, sequencing and delivery reporting = capability.

So how do you do this? Have you defined an MSRP or CPIM = extension? Or
have you defined a special MIME type for a body that = communicates this?

I just send a CPIM message like = these:

content_type=3D'application/history-on'

or

con= tent_type=3D'application/history-off'

The support for this = feature is negotiated in the SDP of the MSRP media
block, = e.g.:

Offer:

o=3D- 3620806345 3620806345 IN IP4 = 192.168.8.3
s=3DBlink 4.7.4 (MacOSX)
m=3Dmessage 2855 TCP/TLS/MSRP = *
c=3DIN IP4 = 192.168.8.3
a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp<= br>a=3Daccept-types:message/cpim text/* = application/im-iscomposing+xml
a=3Daccept-wrapped-types:*
a=3Dsetup:= active
a=3Dfeatures:history-control icon

Answer:

o=3D- = 3620806346 3620806347 IN IP4 10.0.0.139
s=3DSylkServer-2.6.0
c=3DIN = IP4 10.0.0.139
m=3Dmessage 51634 TCP/TLS/MSRP = *
a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
a=3D= accept-types:message/cpim
a=3Daccept-wrapped-types:*
a=3Dsetup:passi= ve
a=3Dchatroom:nickname private-messages = com.ag-projects.screen-sharing

IIUC, a message with = content type of application/history-off would not be valid within the = MSRP session negotiated above. (Unless it was sent within a CPIM = wrapper.)

It is within the = CPIM.


Ignoring that, what are the semantics? Are you sending an = *empty* message with this content type, to set a mode? Or is this the = type of a message containing a body that is to be displayed but not = added to the history?

It asks the = remote party to toggle its save to history on or off. Is a switch that = can be toggled remotely (if the recipient want to honour = it).



If the = latter, then how do you know the actual type of the content?

How = normative is this? Is it advisory to the recipient? Or binding? Doe it = need to be acknowledged?

It is = advisory as there is no way for force the other recipient to comply with = such directive. You cannot control what a remote party will really save = in its history database, is a gentlemen's = agreement.


= Thanks,
= Paul


To: "Ram Mohan R (rmohanr)" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP2BH626Sy94gZRGe/WNqN1yRzT5wZgcwA Date: Tue, 30 Sep 2014 10:40:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> References: <54223161.8030106@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/DDiChiLbI_1kfFsEqufwkqTzcRY Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2014 10:40:26 -0000 The meeting time should be used to discuss open issues with the documents t= hat have not been resolved on the list. The protocol document should be going to the IESG shortly hopefully Brian i= s working on the write-up. Regarding the metadata and call flows then there has been no discussion on = these for some time and my thinking is that these will move forward once we= have made some progress with the protocol draft which is the main SIPREC s= pec.=20 Alissa informs me that we are likely to get lots of IESG feedback on the pr= otocol draft so my thinking is that we should get this feedback before prog= ressing the other drafts.=20 Does that sound like a plan? I have a meeting with Brian and Alissa coming up so will discuss it again w= ith them. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: 24 September 2014 17:10 > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] IETF91 SIPREC Meeting >=20 > +1 >=20 > I also second Paul. Can we please get some attention on the base drafts > (protocol, metadata, call flows) and try to finish them at this meeting > ? >=20 > Ram >=20 > -----Original Message----- > From: Paul Kyzivat > Date: Wednesday, 24 September 2014 8:20 am > To: "siprec@ietf.org" > Subject: Re: [siprec] IETF91 SIPREC Meeting >=20 > >Can we please try to *finish* the base siprec drafts before or at this > >meeting??? > > > >On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: > >> Hi Andy, > >> > >> I posted an update to the protocol draft 4 weeks ago. > >> http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html > >> > >> I believe this version addresses all comments and issues; however, > there > >> has not been confirmation by reviewers yet. If the chairs think it > would > >> be helpful, I can present the latest changes at IETF 91 > >> > >> Cheers, > >> Charles > >> > >> From: , Andrew >> > > >> Date: Friday, September 19, 2014 at 1:13 AM > >> To: "siprec@ietf.org " >> > > >> Subject: [siprec] IETF91 SIPREC Meeting > >> > >> Hi All, > >> The deadline for requesting an IETF91 meeting slot is next week > >> (26^th of Sept). > >> Please let the chairs know if you believe a SIPREC meeting at > IETF91 > >> is needed and why and whether you have anything to present. > >> Given that there has no list discussion I am thinking that maybe > >> there is no need for a SIPREC meeting this time. > >> 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 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From nobody Tue Sep 30 03:41:45 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C0D1A0327 for ; Tue, 30 Sep 2014 03:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl79y2iC1Y-m for ; Tue, 30 Sep 2014 03:41:43 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF91A031B for ; Tue, 30 Sep 2014 03:41:43 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 1336223F0422; Tue, 30 Sep 2014 12:41:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 12:41:42 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] SIPREC @ IETF91 Thread-Index: Ac/YBxe0s/e873zcTwiCtwJei2F17P//+RAA//bRRrA= Date: Tue, 30 Sep 2014 10:41:42 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B1C22@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E5AC700@MCHP04MSX.global-ad.net> <5422F0DE.4060906@alum.mit.edu> In-Reply-To: <5422F0DE.4060906@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 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/R2SWvfwjQHFvdAAdn-WTFJjK88A Subject: Re: [siprec] SIPREC @ IETF91 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2014 10:41:44 -0000 I was promised after the last meeting schedule was published that we would = not be given a Friday afternoon slow. Lets see what happens. Andy > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 September 2014 17:27 > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC @ IETF91 >=20 > Maybe we'll be lucky and it won't be last thing Friday afternoon! >=20 > On 9/24/14 10:51 AM, Hutton, Andrew wrote: > > I have requested a one hour meeting slot for SIPREC during the IETF91 > > meeting. > > 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 nobody Tue Sep 30 05:04:12 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BAF1A02FF for ; Tue, 30 Sep 2014 05:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOeBwg1u9QEM for ; Tue, 30 Sep 2014 05:04:09 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4831A03AA for ; Tue, 30 Sep 2014 05:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4099; q=dns/txt; s=iport; t=1412078648; x=1413288248; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E+UusFyUvn8Q+RIvOh4FWCQmssjYyJxf+j7f/l5Ff4Q=; b=N+W7YvH+AL9eO0ewOD3zffmdnPnNgYZ7AXiX3Wd+kP2oSGfIGkOAYxsy VDt5KzhEl176n2YhDtCiXafael4k6sXu4CtrSjmW4Go+3nz9JDhAMoht9 MCXle6sCaKfiGeAjYaWWf+UZtuNv+NnQijhJ2s5pQtKdrJijcI9tfMOEt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAEubKlStJA2E/2dsb2JhbABgDoMAU1cEyhkKhnlUAoEQFgF7hAMBAQEEAQEBNzQXBAIBCBEDAQEBAR4JBycLFAkIAgQBEgmINQ2/NgEXj00BASQtBQaERQWEYY0JiHSCUZVwgyNAbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208";a="82677570" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 30 Sep 2014 12:04:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UC46nv032717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 12:04:06 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 07:04:06 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP3KaiqVz6v01bTEmkQ6Wk+LAX3A== Date: Tue, 30 Sep 2014 12:04:06 +0000 Message-ID: References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@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.4.3.140616 x-originating-ip: [10.65.41.47] Content-Type: text/plain; charset="us-ascii" Content-ID: <011EADB1066C5240A35A029A19758ED5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/JwNn8GAw9H6SNLR-NhQj2yrzWgg Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2014 12:04:10 -0000 Hi Andy, Overall it Sounds a good plan. If possible we can start the WGLC for metadata in parallel while we get feedback for protocol draft from IESG unless we expect some changes in metadata as a result of IESG review of protocol draft. We can keep the WGLC for metadata draft open till we finish the protocol draft. In that way we would give the WG sufficient time to review and give any LC feedback they have on the metadata draft. Regards, Ram -----Original Message----- From: , Andrew Date: Tuesday, 30 September 2014 4:10 pm To: Cisco Employee , Paul Kyzivat , "siprec@ietf.org" Subject: RE: [siprec] IETF91 SIPREC Meeting >The meeting time should be used to discuss open issues with the documents >that have not been resolved on the list. > >The protocol document should be going to the IESG shortly hopefully Brian >is working on the write-up. > >Regarding the metadata and call flows then there has been no discussion >on these for some time and my thinking is that these will move forward >once we have made some progress with the protocol draft which is the main >SIPREC spec.=20 > >Alissa informs me that we are likely to get lots of IESG feedback on the >protocol draft so my thinking is that we should get this feedback before >progressing the other drafts. > >Does that sound like a plan? > >I have a meeting with Brian and Alissa coming up so will discuss it again >with them. > >Regards >Andy (SIPREC Co-Chair). > > > >> -----Original Message----- >> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >> Sent: 24 September 2014 17:10 >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] IETF91 SIPREC Meeting >>=20 >> +1 >>=20 >> I also second Paul. Can we please get some attention on the base drafts >> (protocol, metadata, call flows) and try to finish them at this meeting >> ? >>=20 >> Ram >>=20 >> -----Original Message----- >> From: Paul Kyzivat >> Date: Wednesday, 24 September 2014 8:20 am >> To: "siprec@ietf.org" >> Subject: Re: [siprec] IETF91 SIPREC Meeting >>=20 >> >Can we please try to *finish* the base siprec drafts before or at this >> >meeting??? >> > >> >On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: >> >> Hi Andy, >> >> >> >> I posted an update to the protocol draft 4 weeks ago. >> >> http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html >> >> >> >> I believe this version addresses all comments and issues; however, >> there >> >> has not been confirmation by reviewers yet. If the chairs think it >> would >> >> be helpful, I can present the latest changes at IETF 91 >> >> >> >> Cheers, >> >> Charles >> >> >> >> From: , Andrew > >> > >> >> Date: Friday, September 19, 2014 at 1:13 AM >> >> To: "siprec@ietf.org " > >> > >> >> Subject: [siprec] IETF91 SIPREC Meeting >> >> >> >> Hi All, >> >> The deadline for requesting an IETF91 meeting slot is next week >> >> (26^th of Sept). >> >> Please let the chairs know if you believe a SIPREC meeting at >> IETF91 >> >> is needed and why and whether you have anything to present. >> >> Given that there has no list discussion I am thinking that maybe >> >> there is no need for a SIPREC meeting this time. >> >> 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 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec