From nobody Tue Jun 3 05:54:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D71A01F9 for ; Tue, 3 Jun 2014 05:54:34 -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_20=-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 6so-bN0K-hlN for ; Tue, 3 Jun 2014 05:54:33 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4E11A01F6 for ; Tue, 3 Jun 2014 05:54:33 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id 9nAg1o00217dt5G54ouTPE; Tue, 03 Jun 2014 12:54:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 9ouT1o00M3ZTu2S3ZouTGJ; Tue, 03 Jun 2014 12:54:27 +0000 Message-ID: <538DC583.2040401@alum.mit.edu> Date: Tue, 03 Jun 2014 08:54:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: CLUE 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=1401800067; bh=3ooDz61JwBGWEEMWW3StsLG+AZLQo0eJLs8qPmH4WFA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qR12GRrw4XgzT6NG3/Zz/T2sVfS2tqZkWbaYl4ZKJH+mE+LhbAiH/j3AWKR54rIlc 4RLvAdxMD+mAJqhylys0Y/T064C52PuyEmfUlGLNVZkGKVFT/JSdT4wedUoPKXQxBB ctDupF/tQXojRCRh30Dq0KF5Cb+1YKFK3bf9ySM+c/yc3iJ92KgDK/f7ToglvSRV9i YEyXgVtIEOeGkQIvxIPOr9Kw2dyTRe4Enbmw2sZVMSQHGSLLJYpQTy43AQf0Ucx/o9 LpiRD6yYTiuAtLGf4TQmJ46aACtt/xzrh3QCmUEZp3KccbnufwTwgwzt/38GOa3Yzw Z1fEiwnYRqEqw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lhxwya-oLVfYV-WG0SdMg0Eohvk Subject: [clue] No design team meeting today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:54:35 -0000 We have no topic for today, so we won't be having the call. Thanks, Paul From nobody Fri Jun 6 08:16:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C9D1A007C for ; Fri, 6 Jun 2014 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SrHcP9_zSzg for ; Fri, 6 Jun 2014 08:16:25 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A741A00F6 for ; Fri, 6 Jun 2014 08:16:24 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so1181044wiw.3 for ; Fri, 06 Jun 2014 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=15tygoVTSnwie0zsOLStDrLL9OzC6FrrcVhz+qOfaao=; b=ArVG7u6G+TFHqFGsh70qZvNH0STt+0F1swaURiCtNZ7FGBewhgd7/QldDERgmmvtmc 5bhV9nnzhW6lHzsXDJ40M0so4SdNppRSGNJ/I+JGhY73mueIoKmnN7FQr6CCG9kzlR0i 8GvYsCSoVThqA5bxcJBQUQlL3lc8LsMBBa/6leXJDOkXksC4hiNSUis1r8Z5J8cUduGj iGspn/QOLGumb1bjz0y3N67XjuF3jNBXm7uL8IzPnkprKr3QawlDyiCmMtJcOlGUy1Di mkATlTqRdApleQwtNxSSqaeWSEpQtbBE8xO5D/O4hrBglBkvgYn/bgKioBk/MnxrrfxW KHxw== MIME-Version: 1.0 X-Received: by 10.194.77.39 with SMTP id p7mr5712810wjw.85.1402067776705; Fri, 06 Jun 2014 08:16:16 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Fri, 6 Jun 2014 08:16:16 -0700 (PDT) Date: Fri, 6 Jun 2014 10:16:16 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bfd057ac81beb04fb2c57a9 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SL6PtymCYMa9pWDNNbjtuP8YMUM Subject: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:16:26 -0000 --047d7bfd057ac81beb04fb2c57a9 Content-Type: text/plain; charset=UTF-8 Hi all, The minutes from last week's virtual interim meeting are now available: http://www.ietf.org/proceedings/interim/2014/05/29/clue/minutes/minutes-interim-2014-clue-2 Please post any comments or corrections no later than Friday, June 13th, 2014. Regards, Mary. --047d7bfd057ac81beb04fb2c57a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The minutes from last week'= s virtual interim meeting are now available:

Please post any comments or corrections no later = than Friday, June 13th, 2014.=C2=A0

Regards,
=
Mary.=C2=A0
--047d7bfd057ac81beb04fb2c57a9-- From nobody Fri Jun 6 08:35:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB25F1A021D for ; Fri, 6 Jun 2014 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqTH40FnvIaW for ; Fri, 6 Jun 2014 08:35:17 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B4C1A0219 for ; Fri, 6 Jun 2014 08:35:16 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so3052722wes.13 for ; Fri, 06 Jun 2014 08:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KKX5cmNGCfAANQoKQjsm+22cw0BmM7sggckDB+WNd1o=; b=n9j1Z/B3geuO40S2XeknWGNC5rJS2K/E893zM8dx+HLOI4GDwJCd+NsvdgDl7hUa0n jkUuvTKm87J1k5c0XKVsKVg/E2L9KawvgCNRE6PwvZEW2xEGulMEZbVKjsY8+ggVICMi g6FwazAXuIQABeQZjXN1FlYiepPd7BaINhcwb5uw7tC9ihHNzI3gQUSrlN6NZrT8Dsqs iSII5GhMUfoiHPW0Uel0iuZEd80sy57Pf8zUnmrYcxVjGEQh90nD0sDdjsJ6HvrFNyoj 0Vdw09+gDSeXhCep9mMSWzFQ1lkr+3yPb0BVjeWRt+qYp8Z9/94oDYx1m4oBO/Uy/QDp bYuw== MIME-Version: 1.0 X-Received: by 10.194.77.39 with SMTP id p7mr5877362wjw.85.1402068909121; Fri, 06 Jun 2014 08:35:09 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Fri, 6 Jun 2014 08:35:09 -0700 (PDT) Date: Fri, 6 Jun 2014 10:35:09 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bfd057a47696104fb2c9bc7 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gs-RnARPrzZhdC06bOgNThLxYiY Subject: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:35:22 -0000 --047d7bfd057a47696104fb2c9bc7 Content-Type: text/plain; charset=UTF-8 Hi all, As discussed at the interim meeting, this is a two week pre-WGLC review for the framework document: http://www.ietf.org/id/draft-ietf-clue-framework-15.txt The objective of this pre-WGLC review is for folks to take a fresh look at the document and re-review the entire document. Right now, there are just a couple outstanding issues: - #35 (consistency with the data model document) - audio issue (that still needs to be detailed by John Leslie) - issues reflected by editor's notes in the document for which we will open new tickets This review is intended to ensure that there are no other outstanding issues so that once we close the above open issues the document is ready for WGLC. Note, reviews that provide a general summary and then separate the major and minor issues from the editorial nits, something like the following, would be quite helpful. Summary: (e.g., Needs Work, Almost Ready, Ready, etc) Major issues: Minor Issues: Editorial nits: Please review and send any comments to the mailing list no later than Friday, June 20th, 2014. Thanks, Mary. --047d7bfd057a47696104fb2c9bc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As discussed at the = interim meeting, this is a two week pre-WGLC review for the framework docum= ent:

The objective of this pre-WGLC review is for folk= s to take a fresh look at the document and re-review the entire document. R= ight now, there are just a couple outstanding issues:
- #35 (= consistency with the data model document)
- audio issue (that still needs to be detailed by John Leslie)
- issues reflected by editor's notes in the document for which we wi= ll open new tickets

This review is intended to ens= ure that there are no other outstanding issues so that once we close the ab= ove open issues the document is ready for WGLC.=C2=A0

Note, reviews that provide a general summary and then s= eparate the major and minor issues from the editorial nits, something like = the following, would be quite helpful.
=C2=A0
Summary: = (e.g., Needs Work, Almost Ready, Ready, etc)

Major issues:

Minor Issues:

Editorial nits:

Please= review and send any comments to the mailing list no later than Friday, Jun= e 20th, 2014.=C2=A0

Thanks,
Mary.=C2=A0

--047d7bfd057a47696104fb2c9bc7-- From nobody Fri Jun 6 10:35:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74FD1A01D9 for ; Fri, 6 Jun 2014 10:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoCjRWvLx_gn for ; Fri, 6 Jun 2014 10:35:03 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769981A01D8 for ; Fri, 6 Jun 2014 10:35:03 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so1415971wib.5 for ; Fri, 06 Jun 2014 10:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=llthojV0p066y79PYKt/zZsil5Hj+cKme9Z3jTZWveA=; b=Nfie48LtWEasX5vsdbMc1h0ZLjQz6kocVXwl0sdBVRBXpt0GpLkoTz7fre9DgcGHw1 vVvgKfDiN6N0HKqL5SRK3YFD8ca1PdvFF6F1mU4xj2ZWeI9bIDzfdv+/BxvLDB+jhvTP 6grdTjkhygqfkMDF240XeBcsGGQhJZw3WEYeqEM6g6HduJHQzXpO9OxCEAX2ztqGS58K PoOwjKvPSh0gbj8YkTQm7C6YJJCcRjFliyFCI+r7/+PJpSPv0ZFc1sjzgM5iIX6aIP36 Yf4IGSEyHYxYS1+RjScKfFtCJw/3tvtHdubvvcJmxRsDPE6lZtjhefqNuplqrLfVP5vG 5rKg== MIME-Version: 1.0 X-Received: by 10.180.73.66 with SMTP id j2mr7360649wiv.36.1402076095613; Fri, 06 Jun 2014 10:34:55 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Fri, 6 Jun 2014 10:34:55 -0700 (PDT) Date: Fri, 6 Jun 2014 12:34:55 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0438921ba08df304fb2e47cb Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RzWKiRRkmhcSChD7FG3LJtoeMQ0 Subject: [clue] Tickets #24 and #30 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 17:35:05 -0000 --f46d0438921ba08df304fb2e47cb Content-Type: text/plain; charset=UTF-8 Both of these tickets relate to the use of BFCP and how it could be used in a CLUE context. At this time, there is nothing within the CLUE charter requiring us to specify anything about BFCP. It is perhaps something that might be addressed in a profile such as the IMTC SIP video profile. However, no one at the virtual interim meeting volunteered to look further into this in terms of identifying a use case or doing a call flow with CLUE and BFCP. Unless someone volunteers to do so by June 13th, these issues will be closed. Regards, Mary --f46d0438921ba08df304fb2e47cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Both of these tickets relate to the use of BFCP and how it= could be used in a CLUE context. At this time, there is nothing within the= CLUE charter requiring us to specify anything about BFCP. =C2=A0It is perh= aps something that might be addressed in a profile such as the IMTC SIP vid= eo profile. However, =C2=A0no one at the virtual interim meeting volunteere= d to look further into this in terms of identifying a use case or doing a c= all flow with CLUE and BFCP. =C2=A0Unless someone volunteers to do so by Ju= ne 13th, these issues will be closed.

Regards,
Mary

--f46d0438921ba08df304fb2e47cb-- From nobody Fri Jun 6 12:34:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8334B1A024D for ; Fri, 6 Jun 2014 12:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb9ZUfXoOopk for ; Fri, 6 Jun 2014 12:34:10 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C405C1A0247 for ; Fri, 6 Jun 2014 12:34:09 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so627472wgg.10 for ; Fri, 06 Jun 2014 12:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hz//jetWY+ceq0Va40CCZhRWG4zTefguF9Xf6vG9Mhc=; b=ZUWbUWiFAOzsjiXqzvIJelXYRWnikWxZ35PnfT3oy0GaGFIe6Zn59e/Uo0bmrflxt1 ETs48wqHn/xOgKK6XbQAqTCbkE4TSk1x85wcCmohIvf/QPRGOdo4+arnEe1oIzaSORap sRCY8DK57cut6DwdtpgBTPzcr/4le6h80/FqWV/Qz+B/6mB0ksLHskAE8ZYm2pJ/IoVk QUItWL/+k6lwprIEkRXb819GzUO6L4lLCqJ6yrjn96qvQ/kmlYVaf3MHl2R/HtPndID6 2E4jjZUmTE7JlphbsVq1o2y9sg9gqzQQhDWOXfYnv+DBUBUWAeOM+8EQpm80e+sD0FSM Pa1A== MIME-Version: 1.0 X-Received: by 10.180.107.130 with SMTP id hc2mr28321088wib.7.1402083241671; Fri, 06 Jun 2014 12:34:01 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Fri, 6 Jun 2014 12:34:01 -0700 (PDT) Date: Fri, 6 Jun 2014 14:34:01 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01494d5290c2a704fb2ff192 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JKrSypv-CsFH9p1b8D9goE3M9Ag Subject: [clue] Upcoming Deadlines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 19:34:11 -0000 --089e01494d5290c2a704fb2ff192 Content-Type: text/plain; charset=UTF-8 If you've had the chance to look at the Project Plan spreadsheet on the wiki you can see we will be very busy reviewing documents so that we can complete the work by year end. I've transferred these deadlines into specific dates for each of the document reviews as well as draft deadlines for upcoming meetings. This should allow the authors to plan document revisions and the WG to see when each document will be under review. http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart Regards. Mary --089e01494d5290c2a704fb2ff192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If you've had the chance to look a= t the Project Plan spreadsheet on the wiki you can see we will be very busy= reviewing documents so that we can complete the work by year end. =C2=A0 I= 've transferred these deadlines into specific dates for each of the doc= ument reviews as well as draft deadlines for upcoming meetings. =C2=A0This = should allow the authors to plan document revisions and the WG to see when = each document will be under review. =C2=A0

--089e01494d5290c2a704fb2ff192-- From nobody Sun Jun 8 01:32:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442061A002B for ; Sun, 8 Jun 2014 01:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMWMTAwrGoKo for ; Sun, 8 Jun 2014 01:32:29 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31801A0154 for ; Sun, 8 Jun 2014 01:32:28 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so2880010wib.11 for ; Sun, 08 Jun 2014 01:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=t0vXi3Rupg9GSu+GCcYgaDPon0tzkly6/q3ZFe/i2FQ=; b=i02wWP39cX3e16goF6rV2IJjnK3tCvmQChuuYzTdpP89U8X8SaSnMPdyDb+wZHJ5Qf HxkUTO0wbPzgPCSfMH32zdBroPs/Fl1c/lrd+Uk2OcGaN1uY7BhQuqN/o5bBvHsSqAar 8x5vx+TBblaQNJQBw4jAz67zlZRxGO3cRiU+kKaD13uKn9/3q/btcdi2DgcT4LPKwTEJ PEiF3e0Qvee/PbKfyn+QssLb1jwQOh6W82ianNrQXWzfKV9SdwEClNML3K6ACG6dIA9i 1A8aRttrqx9IhvKwegkLKrkgGnwnuTu/Ct2bWykpzYVazhtoLbm83/RqwB8gjaL66Zko 0BYw== X-Received: by 10.194.6.166 with SMTP id c6mr21256163wja.64.1402216340155; Sun, 08 Jun 2014 01:32:20 -0700 (PDT) Received: from RoniE (bzq-79-178-185-234.red.bezeqint.net. [79.178.185.234]) by mx.google.com with ESMTPSA id ej2sm19667897wjd.21.2014.06.08.01.32.18 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 08 Jun 2014 01:32:19 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Sun, 8 Jun 2014 11:32:09 +0300 Message-ID: <049a01cf82f4$251136f0$6f33a4d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_049B_01CF830D.4A5F5950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ03AflQumfxif/6yLhNjBoPwmg3pocMBWQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/csdlfGq4R2WPDyTT3s0z51b01Sg Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 08:32:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_049B_01CF830D.4A5F5950 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mary, I was unable to access the presentation the link = https://datatracker.ietf.org/accounts/login/?next=3D/secr/proceedings/int= erim-2014-clue-2/clue/ asks for login Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 06 June, 2014 6:16 PM To: CLUE Subject: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 =20 Hi all, =20 The minutes from last week's virtual interim meeting are now available: http://www.ietf.org/proceedings/interim/2014/05/29/clue/minutes/minutes-i= nterim-2014-clue-2 =20 Please post any comments or corrections no later than Friday, June 13th, = 2014.=20 =20 Regards, Mary.=20 ------=_NextPart_000_049B_01CF830D.4A5F5950 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mary,

I was unable to access the presentation the link https://datatracker.ietf.org/accounts/log= in/?next=3D/secr/proceedings/interim-2014-clue-2/clue/ asks for = login

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 06 June, 2014 6:16 PM
To: = CLUE
Subject: [clue] Minutes: CLUE WG Virtual Interim Meeting = on May 29, 2014

 

Hi = all,

 

The minutes from last week's virtual interim meeting = are now available:

 

Please post any comments or corrections no later than = Friday, June 13th, 2014. 

 

Regards,

Mary. 

------=_NextPart_000_049B_01CF830D.4A5F5950-- From nobody Sun Jun 8 10:01:32 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6349A1A0219 for ; Sun, 8 Jun 2014 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTF74ONUV3VZ for ; Sun, 8 Jun 2014 10:01:29 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6591A0214 for ; Sun, 8 Jun 2014 10:01:28 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so885421wgg.33 for ; Sun, 08 Jun 2014 10:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GUh6L2BCIHWwoUvjhaQyrV2itBBanQ0SLPf6JCw67fo=; b=jm4Q2Ovn/Zhx3Ca/lBhJ8t/ixcIXjj2f2O03pAk2Ckth7O+dDvIJN9+jeX+4FNr4rT uf9/nGSWgxIri20akJq2s2nkR8aQdgiYaksTutEQNvkLAwp53DDTlr0pPUkq9k8yd00M 7gx7v92hPVqTU0wIx7aIO91evQJP3Oflvay92kVO+gj1MiGUA26BeP3K+FoWLsvWgmzR 7e+vmSaOfbDIYDHegtVYQLJB3uhbjXSglx7MK1cg0YurYCb11fbctONek0IVU4bwvPU/ PsEhARillQgp7uTSsclZPcZJbjEfftXy4wTuQc7U8ryRZgT+qVmSeT8eDoXW8XPp/mOx E4TA== MIME-Version: 1.0 X-Received: by 10.194.157.68 with SMTP id wk4mr24458638wjb.42.1402246887056; Sun, 08 Jun 2014 10:01:27 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Sun, 8 Jun 2014 10:01:26 -0700 (PDT) In-Reply-To: <049a01cf82f4$251136f0$6f33a4d0$@gmail.com> References: <049a01cf82f4$251136f0$6f33a4d0$@gmail.com> Date: Sun, 8 Jun 2014 12:01:26 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=089e0112cbfc972b1004fb560be8 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fo6uYXfyo8Ks-_Or2w9iLOwFeSs Cc: CLUE Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 17:01:30 -0000 --089e0112cbfc972b1004fb560be8 Content-Type: text/plain; charset=UTF-8 I think that's an anomaly of changes they've made with regards to accessing some of the IETF webpages to require that you login. You should already have an IETF userid and password for the datatracker. I have mine cached in the browser, so it's just one extra click, although I seem to still get it periodically. Mary. On Sun, Jun 8, 2014 at 3:32 AM, Roni Even wrote: > Hi Mary, > > I was unable to access the presentation the link > https://datatracker.ietf.org/accounts/login/?next=/secr/proceedings/interim-2014-clue-2/clue/ > asks for login > > Roni > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 06 June, 2014 6:16 PM > *To:* CLUE > *Subject:* [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 > > > > Hi all, > > > > The minutes from last week's virtual interim meeting are now available: > > > http://www.ietf.org/proceedings/interim/2014/05/29/clue/minutes/minutes-interim-2014-clue-2 > > > > Please post any comments or corrections no later than Friday, June 13th, > 2014. > > > > Regards, > > Mary. > --089e0112cbfc972b1004fb560be8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that's an anomaly of changes they've made = with regards to accessing some of the IETF webpages to require that you log= in. You should already have an IETF userid and password for the datatracker= . =C2=A0I have mine cached in the browser, so it's just one extra click= , although I seem to still get it periodically.=C2=A0

Mary.


On Sun, Jun 8, 2014 at 3:32 AM, Roni Even &l= t;ron.even.tlv@= gmail.com> wrote:

Hi Mary,

I was unable to access th= e presentation the link = https://datatracker.ietf.org/accounts/login/?next=3D/secr/proceedings/inter= im-2014-clue-2/clue/ asks for login

Roni=

=C2=A0<= /span>

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 06 June, 2014 6:16 PM
To: CLUE
Subject: [c= lue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014=

=C2=A0

Hi all,

=C2=A0

The minutes= from last week's virtual interim meeting are now available:<= /u>

=C2=A0

Please post any comments or corrections no later than Frid= ay, June 13th, 2014.=C2=A0

=C2=A0

Regards,

Mary.=C2=A0


--089e0112cbfc972b1004fb560be8-- From nobody Mon Jun 9 04:39:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF971B27D6; Sun, 8 Jun 2014 21:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 FXZ_Z-bAxqaW; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBB91A04AE; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s594Q3u2096521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 23:26:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Sun, 8 Jun 2014 23:26:02 -0500 X-Mao-Original-Outgoing-Id: 423980762.897201-b2645a7bb05615547ccbc722548e50af Content-Transfer-Encoding: quoted-printable Message-Id: <26D7D69F-FFA0-442A-B151-1ADCCC972717@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: rtcweb@ietf.org, clue@ietf.org, mmusic@ietf.org, avtcore@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MIl82hnoOGGaY0xNv-scQN6VJAE X-Mailman-Approved-At: Mon, 09 Jun 2014 04:39:52 -0700 Cc: dart@ietf.org Subject: [clue] Fwd: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:26:08 -0000 Hi, The referenced draft is a start for discussion on the implicat ions of = using different DiffServ treatments for packets in the same IP flow = (that is, share the same IP 5-tuple.) This will likely be of interest to = RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate = the bundling of multiple media streams on a single IP flow.=20 Please take discussion to the DART working group list (copied.) Thanks! Ben. Begin forwarded message: > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based = on > the Real-time Transport Protocol (RTP). DiffServ is based on = network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As = a > result, use of different DSCPs within a single traffic flow may = cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the = traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, = including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 From nobody Mon Jun 9 05:50:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8385D1A0161 for ; Mon, 9 Jun 2014 05:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0TEtTkhmg5b for ; Mon, 9 Jun 2014 05:50:14 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B779D1A0157 for ; Mon, 9 Jun 2014 05:50:12 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so1315780wes.7 for ; Mon, 09 Jun 2014 05:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=ZyfOeWL1OcoGv/wF595BmYFj5fpjiy+q3StuOLApKRU=; b=E7ChMKVtsd/NxpAwtqGWPcNpSBiBUyGI8jmSUXysdRwjjQz1idUIFdfrvylL6iWajB sTniEJvkirv6edjyIaWO6n6pLxb2e3cRmuOete9mjih0gi96lS7i2tfoCFQiFlR5rTFq xLbA6CAWx2Sa8B2Gx/iESzDtB4qBDR0uPNN60rp00ARMPiZ1+FqFBn6kkO3/37p5M72z 5d0LQCIbYGW3wliw23E96F93qjPGo6QtMphS2bq4oaaU4fH7HRSpc3XtnzvGJJ8nWQZ9 tPOKLJIvJCv53gHJAM6EI2au5ig78c7RcNn8ORsVNfPHg3f5YFUPk0JzIJcDqfoDGef5 z3Sg== X-Received: by 10.180.7.227 with SMTP id m3mr30612350wia.59.1402318211132; Mon, 09 Jun 2014 05:50:11 -0700 (PDT) Received: from RoniE (bzq-79-178-185-234.red.bezeqint.net. [79.178.185.234]) by mx.google.com with ESMTPSA id gp15sm24925135wjc.10.2014.06.09.05.50.08 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jun 2014 05:50:10 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <049a01cf82f4$251136f0$6f33a4d0$@gmail.com> In-Reply-To: Date: Mon, 9 Jun 2014 15:49:57 +0300 Message-ID: <04ef01cf83e1$53427be0$f9c773a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F0_01CF83FA.78909E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ03AflQumfxif/6yLhNjBoPwmg3gHdBfGwAZoE2siaAlHn4A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/98-p9mv7kMYns02ZpqdUVLp-mJM Cc: 'CLUE' Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 12:50:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F0_01CF83FA.78909E40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mary, This is not the case, I logged in but it said that this is not my WG. It = looks like this is the WG chairs link Roni =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: 08 June, 2014 8:01 PM To: Roni Even Cc: CLUE Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, = 2014 =20 I think that's an anomaly of changes they've made with regards to = accessing some of the IETF webpages to require that you login. You = should already have an IETF userid and password for the datatracker. I = have mine cached in the browser, so it's just one extra click, although = I seem to still get it periodically.=20 =20 Mary. =20 On Sun, Jun 8, 2014 at 3:32 AM, Roni Even = wrote: Hi Mary, I was unable to access the presentation the link = https://datatracker.ietf.org/accounts/login/?next=3D/secr/proceedings/int= erim-2014-clue-2/clue/ asks for login Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 06 June, 2014 6:16 PM To: CLUE Subject: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 =20 Hi all, =20 The minutes from last week's virtual interim meeting are now available: http://www.ietf.org/proceedings/interim/2014/05/29/clue/minutes/minutes-i= nterim-2014-clue-2 =20 Please post any comments or corrections no later than Friday, June 13th, = 2014.=20 =20 Regards, Mary.=20 =20 ------=_NextPart_000_04F0_01CF83FA.78909E40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mary,

This is not the case, I logged in but it said that this is not my WG. = It looks like this is the WG chairs link

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 08 = June, 2014 8:01 PM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Minutes: CLUE WG Virtual Interim = Meeting on May 29, 2014

 

I think = that's an anomaly of changes they've made with regards to accessing some = of the IETF webpages to require that you login. You should already have = an IETF userid and password for the datatracker.  I have mine = cached in the browser, so it's just one extra click, although I seem to = still get it periodically. 

 

Mary.

 

On Sun, Jun 8, 2014 at 3:32 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Mary,

I was unable to access the presentation the link https://datatracker.ietf.org/accounts/login/?next=3D/se= cr/proceedings/interim-2014-clue-2/clue/ asks for = login

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 06 June, 2014 6:16 PM
To: = CLUE
Subject: [clue] Minutes: CLUE WG Virtual Interim Meeting = on May 29, 2014

 <= /o:p>

Hi = all,

 <= /o:p>

The minutes = from last week's virtual interim meeting are now = available:

 <= /o:p>

Please post = any comments or corrections no later than Friday, June 13th, = 2014. 

 <= /o:p>

Regards,

Mary. <= o:p>

 

------=_NextPart_000_04F0_01CF83FA.78909E40-- From nobody Mon Jun 9 06:39:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1191A0168 for ; Mon, 9 Jun 2014 06:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REcn-xpvK0Me for ; Mon, 9 Jun 2014 06:39:16 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C687A1A0164 for ; Mon, 9 Jun 2014 06:39:15 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so4290524wib.0 for ; Mon, 09 Jun 2014 06:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8KaqWBURlQNG49BnPFieONYKsGd3Mzussg/tiFfe5XI=; b=ckiZm04rokWW2QGpWpqBi27vArSc+Xg7fMFJNzirQQqJ0rDOQA+fO4omDTU9+Subz3 B4iPsphRzpzpncCE2Shd9hG29VEowLRYU5S0hjhv77hxtOYzEB1LWmY/qytRXezFv3Hn HNsLR2CzKwj4IVN2QXPcuqPRHYDPmogyeHnopZj8AQZaXZzHLX0aPe2xcTzFjc1XXwHE 8MBYTn5+gC0R/95ogqIWaLSW1y+DGqwyU6c105bmyJHJVsP3TljNNuZbCn0kfDCo+Zgl PfG3pv1ouxYzifQP3yvliYmTIJFxZ04LdHouaNjcoei8wmVIfCUMU3oNrOGfCJZLZQ84 sj4w== MIME-Version: 1.0 X-Received: by 10.180.84.168 with SMTP id a8mr17480817wiz.36.1402321153365; Mon, 09 Jun 2014 06:39:13 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Mon, 9 Jun 2014 06:39:13 -0700 (PDT) In-Reply-To: <04ef01cf83e1$53427be0$f9c773a0$@gmail.com> References: <049a01cf82f4$251136f0$6f33a4d0$@gmail.com> <04ef01cf83e1$53427be0$f9c773a0$@gmail.com> Date: Mon, 9 Jun 2014 08:39:13 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d041827f2351d6204fb675627 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Xd681NSb823SHT9GzxjzuZd677I Cc: CLUE Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 13:39:18 -0000 --f46d041827f2351d6204fb675627 Content-Type: text/plain; charset=UTF-8 I went to the IETF homepage and clicked on Interim meetings: http://www.ietf.org/meeting/interim-meetings.html and then Proceedings (i.e., not Meeting Materials Manager) to get here http://www.ietf.org/meeting/interim/proceedings.html, which actually is the wrong webpage. You should probably file a ticket. I would except I need to leave for the airport in 6 minutes. Mary. On Mon, Jun 9, 2014 at 7:49 AM, Roni Even wrote: > Hi Mary, > > This is not the case, I logged in but it said that this is not my WG. It > looks like this is the WG chairs link > > Roni > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 08 June, 2014 8:01 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, > 2014 > > > > I think that's an anomaly of changes they've made with regards to > accessing some of the IETF webpages to require that you login. You should > already have an IETF userid and password for the datatracker. I have mine > cached in the browser, so it's just one extra click, although I seem to > still get it periodically. > > > > Mary. > > > > On Sun, Jun 8, 2014 at 3:32 AM, Roni Even wrote: > > Hi Mary, > > I was unable to access the presentation the link > https://datatracker.ietf.org/accounts/login/?next=/secr/proceedings/interim-2014-clue-2/clue/ > asks for login > > Roni > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 06 June, 2014 6:16 PM > *To:* CLUE > *Subject:* [clue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014 > > > > Hi all, > > > > The minutes from last week's virtual interim meeting are now available: > > > http://www.ietf.org/proceedings/interim/2014/05/29/clue/minutes/minutes-interim-2014-clue-2 > > > > Please post any comments or corrections no later than Friday, June 13th, > 2014. > > > > Regards, > > Mary. > > > --f46d041827f2351d6204fb675627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I went to the IETF homepage and clicked on Interim meeting= s:
and then Proc= eedings (i.e., not Meeting Materials Manager) to get here =C2=A0http://www.ietf.org/m= eeting/interim/proceedings.html, which actually is the wrong webpage. = =C2=A0You should probably file a ticket. I would except I need to leave for= the airport in 6 minutes.

Mary.


On Mon, Jun 9, 2014 at 7:49 AM, Ro= ni Even <ron.even.tlv@gmail.com> wrote:

Hi Mary,

This is not the case, I l= ogged in but it said that this is not my WG. It looks like this is the WG c= hairs link

Roni=

=C2=A0<= /span>

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 08 June, 2014 8:01 PM
To: Roni Even
Cc: CL= UE
Subject: Re: [clue] Minutes: CLUE WG Virtual Interim Meeting o= n May 29, 2014

=C2=A0

= I think that's an anomaly of changes they've made with regards to a= ccessing some of the IETF webpages to require that you login. You should al= ready have an IETF userid and password for the datatracker. =C2=A0I have mi= ne cached in the browser, so it's just one extra click, although I seem= to still get it periodically.=C2=A0

=C2=A0

Mary.

=C2=A0

On Sun, Jun 8, 2014 at 3:32 AM, Roni Even <ron.even.tlv@gmail.com> wrote:<= /u>

Hi Mary,=

I was u= nable to access the presentation the link https://datatracker.ietf.org/accounts/login/?next=3D/secr= /proceedings/interim-2014-clue-2/clue/ asks for login<= /u>

Roni=

=C2=A0<= u>

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 06 June, 2014 6:16 PM
To: CLUE
Subject: [c= lue] Minutes: CLUE WG Virtual Interim Meeting on May 29, 2014=

=C2=A0

Hi all,

=C2=A0

The minutes= from last week's virtual interim meeting are now available:<= /u>

=C2=A0

Please post any comments or corrections no later than Frid= ay, June 13th, 2014.=C2=A0

=C2=A0

Regards,

Mary.=C2=A0

=C2=A0

<= /div>

--f46d041827f2351d6204fb675627-- From nobody Tue Jun 10 05:54:40 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8921A01C9 for ; Tue, 10 Jun 2014 05:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jfKVwSPXv0Pi for ; Tue, 10 Jun 2014 05:54:34 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id B6A391A0123 for ; Tue, 10 Jun 2014 05:54:33 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id CbUl1o00516LCl05BcuZ11; Tue, 10 Jun 2014 12:54:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id CcuZ1o0033ZTu2S3ScuZjJ; Tue, 10 Jun 2014 12:54:33 +0000 Message-ID: <53970008.9090105@alum.mit.edu> Date: Tue, 10 Jun 2014 08: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.5.0 MIME-Version: 1.0 To: CLUE 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=1402404873; bh=zNkEZmSqIGiOhHLPDwhrlmnS0yDHuqfJadG8AQztDpk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZsDlfR7wCAjDl+k7ejspOwxg67LUV7r3Zr5bIaW/FtVWb9EJr8wqJp3lDfHzHaECo +ZKpXfV7woUTKgC/Hd2p2NmqlJFPVeZ1YO6TT3xpdNP4BrFe2ElQ8VBf2Y54xeW6fq op9uKerN+bOW9XMDUKOCQYTMTvYHqCV2JE4ThMycBRaAJWtRRYvtSDQI6PALvsbZPT rHlg+hxhOM9GMrOs/AGRePv3phh31ugtNRpcrd/Or8LhrAxCIz+H/NroPnobbIPmtC pmD+sKqWMz7NGBCPE5ur1oJ4ABnhLi0SlJandXHoIl2IIEmFIN47i/klFs0fZM3dco QQe691uS4C6RA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZQwkFvAVyIuzyIu4EtBTviSoxts Subject: [clue] design team mtg Tuesday X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:54:35 -0000 Just a reminder that we *will* have a design team meeting tomorrow. Subject is Data Model open issues Thanks, Paul From nobody Tue Jun 10 05:58:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7678E1A00FE for ; Tue, 10 Jun 2014 05:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 EUa1fYDfW8Ps for ; Tue, 10 Jun 2014 05:58:19 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C77311A00E9 for ; Tue, 10 Jun 2014 05:58:18 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id CcB71o0011c6gX859cyJm8; Tue, 10 Jun 2014 12:58:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id CcyH1o00j3ZTu2S3jcyJxr; Tue, 10 Jun 2014 12:58:18 +0000 Message-ID: <539700E9.2050908@alum.mit.edu> Date: Tue, 10 Jun 2014 08:58:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: CLUE 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=1402405098; bh=/YOr4cSNAEDXZeBxJ4lHMxb3um2268L27wRyOUeq7lo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EPcwj85DswNtRB83eYXF+EbYJ+GzHvUEYs19Zo8IbPudlalX9wUjt8cy+Vo7uCvWu uHrY9jM28JTl3lHBFS/jxFTWR90yPxSVr53uDKO+AYcdpgNgWmcyv0t7iXHfeGAp0G JPygtENwqfciMBs+J7/bu1RR373uzojnk8ybDpIAhfCFEdQhetl1k7tTbfOErv9DE6 Ak0aauJT0lUXVPbDKWWdALtsY0x/g3YGg17FDdmlEx1qE53FiIg86Yf8llqGWq4B8c s4ut/sPL0QtQt8lhrOf1/v+QtbfqEOiBia7rSS7WJIBt5MHruuaIiVjDjoH2HJIzCP KVpzNm0LCijgQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/R1EBjxGaF6eCxbLLm4xzWKJJz34 Subject: [clue] design team mtg Tuesday - Now X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:58:19 -0000 Just a reminder that we *will* have a design team meeting *today*. Subject is Data Model open issues Thanks, Paul From nobody Tue Jun 10 07:33:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736191A0193 for ; Tue, 10 Jun 2014 07:33:53 -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 l4LS1IQ3WaDa for ; Tue, 10 Jun 2014 07:33:52 -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 2B15E1A018E for ; Tue, 10 Jun 2014 07:33:52 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id CbiW1o0040SCNGk51eZrXy; Tue, 10 Jun 2014 14:33:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id CeZr1o00N3ZTu2S3VeZryN; Tue, 10 Jun 2014 14:33:51 +0000 Message-ID: <5397174F.3070500@alum.mit.edu> Date: Tue, 10 Jun 2014 10:33:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: CLUE Content-Type: multipart/mixed; boundary="------------020706040909080504090705" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1402410831; bh=IR/gB7VbAKDbYFb5tQxZY8dA2qZSmAmJ0P2LNp87m4Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=flW/Ljrw0QiFPb+TMfh8Wz6nDu40PrtdaC5QfJIjDP3XPPcyibSSOrXN3HoKme2P8 pwJqBqDdYK67vYaScNEI9XoOi7ZM2mW86KgFmIaFyiR/P2SQjCK6zQOd2lYrcRFBKs pZ7Nq6hbLHMKWCDBVG7tB8bqHx9lyrimBsfDS3ZJBvJdTwKJK7C0mFR5iKyFauS0GK Y3umQZLGmZkPgpISSZEd4a5ltbgCXvhLGrx3BNmlMzA8BuAQanJYvn51ua+bVZCKJZ HcsrUantSTggV5NM1EuvXneY7PPwpXWyXSBQqWRi27YhNegQaelxnZQ+6T3Z9xTDMX 5rJyVlVg5RdDA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/htZtY30y9aUZMJkaaLL6QF4Ese4 Subject: [clue] Please comment on Data Model Changes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 14:33:53 -0000 This is a multi-part message in MIME format. --------------020706040909080504090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We had a design team meeting today, covering data model open issues. Attendance was very limited, but the meeting was nevertheless productive. If you weren't at the meeting today, please look at the slides and comment on them! I'm attaching the minutes of the meeting. They have a URL to the slides. Thanks, Paul --------------020706040909080504090705 Content-Type: text/plain; charset=UTF-8; name="minutes-140610.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="minutes-140610.txt" CLUE Working Group Design Team meeting (June 10, 2014) ========================================================== Subject: Data Model Open Issues Attendees: Paul Kyzivat, Simon Romano, Roberta Presta, Jonathan Lennox Note taker: Paul Kyzivat Recording: https://ietf.webex.com/ietf/ldr.php?RCID=fb8470901a3f1e958d7333eebacf3a09 Slides: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/CLUE-datamodel-design-team-meeting-140610.pptx Actions: Simon & Roberta: publish the new version of the data model before Monday, June 16. Paul: Send a request to the WG to review and comment on slides from this meeting. ========================================================== Notes by Paul Kyzivat A new version of the draft (in progress) addresses the issues in ticket #35 (Ensure Framework and Data model terminology is consistent) and #48 (Linking participant Information with Participant Type). There have been a number of changes to address this. They are covered in the slides for this meeting. A question came up about slide 6. There is confusion about the name "PersonType". The data model has an XML type named "PersonType" that is the type describing Person. Then, within this type there is an element with name "PersonType" that is of type "PersonTypeType". This is not ambiguous to an XML parser, but it is confusing. We discussed ways to reduce the confusion but didn't come to a decision about how. It isn't strictly necessary to do anything, but it seems likely to cause continuing confusion. Need to discuss this further on the list. Roberta and Simon plan to publish this new version of the data model draft by the end of this week, or Monday at the latest. (They are still verifying the XML.) Because the attendance was so limited at this meeting, we need to encourage the rest of the WG to review the meeting slides and comment. --------------020706040909080504090705-- From nobody Tue Jun 10 12:15:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFFD1A027B for ; Tue, 10 Jun 2014 12:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd_2B3Z4fsKj for ; Tue, 10 Jun 2014 12:15:04 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D351A0081 for ; Tue, 10 Jun 2014 12:15:03 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so7549831wgh.31 for ; Tue, 10 Jun 2014 12:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5QTyRZof+nJvPiMwrcMoXVn0AeaYA+jcq34RkegyHA4=; b=FUxhYKFnqVutcsSt8jc1AuMI0i+Ncs9BAwAqjZh2Jgo3ZTSWuIBN2JPtZCnCK1l6pX tj7PSOToDEQhJQO2bRljxE7QoBz15FHqq7qAUo9FudLgGkyowFW0Vv75UoY39sQzlv4v GFCB0i8qQpnVBhkw7NEQNkAIihGQxiJWsFUgJdmOR1c7ytyVNoC5oerTKJli6RVQ4W6J 7rFoUdFKpyIG7rihC1+ObIMHv36jk0LmgcomFcEylvzaRaws4iSt4BS8pKtIVuxWN4h6 DeFjoB8PhGC6Of0wYXg2dTvWTUh7rR+0wpbNex0HEU4/CJomFyYIx9uY0KJYDRkCVGJw YDxg== MIME-Version: 1.0 X-Received: by 10.194.77.39 with SMTP id p7mr17995574wjw.85.1402427702485; Tue, 10 Jun 2014 12:15:02 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Tue, 10 Jun 2014 12:15:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Jun 2014 14:15:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bfd057a07a83904fb80257d Archived-At: http://mailarchive.ietf.org/arch/msg/clue/XtWJyqd-B53yrsq7C0jcxue4ljQ Subject: [clue] Fwd: [rtcweb] WGLC for data channel drafts X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:15:08 -0000 --047d7bfd057a07a83904fb80257d Content-Type: text/plain; charset=UTF-8 Given that the CLUE WG data channel document has direct dependencies on the RTCWEB data channel document, folks in CLUE should review the RTCWEB document and provide comments. If you think the document is good from the CLUE perspective, then please post that feedback to the CLUE WG mailing list. If you see any specific issues with the RTCWEB document, then please post those on the RTCWEB mailing list as that would be extremely helpful in getting the document completed in that WG. Thanks, Mary. ---------- Forwarded message ---------- From: Ted Hardie Date: Tue, Jun 10, 2014 at 1:52 PM Subject: [rtcweb] WGLC for data channel drafts To: "rtcweb@ietf.org" Dear WG, This starts a working group last call for our core Data Channel drafts: draft-ietf-rtcweb-data-protocol-06.txt draft-ietf-rtcweb-data-channel-10.txt Please review them in detail, especially for areas which may be of concern to the broader IETF community. This WGLC will end on June 27, 2014. Ted, Sean, Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --047d7bfd057a07a83904fb80257d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that the CLUE WG data channel document has direct de= pendencies on the RTCWEB data channel document, folks in CLUE should review= the RTCWEB document and provide comments. =C2=A0 If you think the document= is good from the CLUE perspective, then please post that feedback to the C= LUE WG mailing list. =C2=A0If you see any specific issues with the RTCWEB d= ocument, then please post those on the RTCWEB mailing list as that would be= extremely helpful in getting the document completed in that WG.=C2=A0

Thanks,
Mary.=C2=A0

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, Jun 10, 2014 at 1:52 PM
Subject: [rtcweb] WGLC for data chann= el drafts
To: "rtcweb@ietf.org" <rtcweb@ietf.org>


Dear WG,<= br>
This starts a working group= last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to=20 the broader IETF community.=C2=A0 This WGLC will end on June 27, 2014.

Ted, Sean, Cullen

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


--047d7bfd057a07a83904fb80257d-- From nobody Tue Jun 10 12:45:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817AF1A02B0 for ; Tue, 10 Jun 2014 12:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkadhWznJ07I for ; Tue, 10 Jun 2014 12:45:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503871A028E for ; Tue, 10 Jun 2014 12:45:25 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-03-53976053bc0b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.8D.28642.35067935; Tue, 10 Jun 2014 21:45:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 21:45:22 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Fwd: [rtcweb] WGLC for data channel drafts Thread-Index: AQHPhN08xkhyX7k1O0+Za/7ipAL9/JtqlUwAgAApfMQ= Date: Tue, 10 Jun 2014 19:45:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35BA0A@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D35BA0AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+JvjW5wwvRgg0NT+C32n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj6fU97AUrtSv2b7vB3MD4WKWLkZNDQsBE Yv6KhawQtpjEhXvr2boYuTiEBI4ySjx6fIAFJCEksJhR4vkCny5GDg42AQuJ7n/aIGERASeJ Cy/fg5UIC9hJ/G2/xQgRt5e4v/cyK4RtJfFpw3EmEJtFQFWifW0vWD2vgK/EirdvWCB2TWWU uH34GztIglMgUOLB6cNgNiPQQd9PrQFrZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B/WAosTV 6cuh6vMltv86yQixTFDi5MwnLBMYRWYhGTULSdksJGUQcT2JG1OnsEHY2hLLFr5mhrB1JWb8 O8SCLL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22oH48HnjocYBTgYlXh4 F7hPDxZiTSwrrsw9xCjNwaIkzntRozpYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PZvoK2 e+8vv47IlHY/weZ469iuozf3FP+Q/pMcEH3/mtPppo7+3uVbBCJSU3uvZpYHv5lq2N2qyOHs zsafeuJK2Cn9CJNK0cM1TMvXXxR7HL9swtV5Ip81HWdxnGwNZ1dVPZ6xQ11nzwuVD2++ztGe uGAvg9Wb2ujyErcdHNaHigWZ2G/2aCmxFGckGmoxFxUnAgBZVdU7jAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VMBCorACwNm4fGd65aEJYK-GfAM Subject: Re: [clue] Fwd: [rtcweb] WGLC for data channel drafts X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:45:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D35BA0AESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have given some comments. One issue I have is that the text is very WebRTC specific. It should be mor= e generic, to allow usage also in other contexts - e.g. CLUE. At least me and Paul have commented on this issue before. Regards, Christer ________________________________ From: clue [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barn= es@gmail.com] Sent: Tuesday, 10 June, 2014 10:15 PM To: CLUE Subject: [clue] Fwd: [rtcweb] WGLC for data channel drafts Given that the CLUE WG data channel document has direct dependencies on the= RTCWEB data channel document, folks in CLUE should review the RTCWEB docum= ent and provide comments. If you think the document is good from the CLUE= perspective, then please post that feedback to the CLUE WG mailing list. = If you see any specific issues with the RTCWEB document, then please post t= hose on the RTCWEB mailing list as that would be extremely helpful in getti= ng the document completed in that WG. Thanks, Mary. ---------- Forwarded message ---------- From: Ted Hardie > Date: Tue, Jun 10, 2014 at 1:52 PM Subject: [rtcweb] WGLC for data channel drafts To: "rtcweb@ietf.org" > Dear WG, This starts a working group last call for our core Data Channel drafts: draft-ietf-rtcweb-data-protocol-06.txt draft-ietf-rtcweb-data-channel-10.txt Please review them in detail, especially for areas which may be of concern = to the broader IETF community. This WGLC will end on June 27, 2014. Ted, Sean, Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D35BA0AESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have given some comments.

 

One issue I have is that the text is very WebRTC specific. It should be = more generic, to allow usage also in other contexts - e.g. CLUE.

 

At least me and Paul have commented on this issue before.

 

 

Regards,

 

Christer

 

From: clue [clue-bounces@ietf.org] on beha= lf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Tuesday, 10 June, 2014 10:15 PM
To: CLUE
Subject: [clue] Fwd: [rtcweb] WGLC for data channel drafts

Given that the CLUE WG data channel document has direct de= pendencies on the RTCWEB data channel document, folks in CLUE should review= the RTCWEB document and provide comments.   If you think the document= is good from the CLUE perspective, then please post that feedback to the CLUE WG mailing list.  If you see an= y specific issues with the RTCWEB document, then please post those on the R= TCWEB mailing list as that would be extremely helpful in getting the docume= nt completed in that WG. 

Thanks,
Mary. 

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, Jun 10, 2014 at 1:52 PM
Subject: [rtcweb] WGLC for data channel drafts
To: "rtcweb@ietf.= org" <rtcw= eb@ietf.org>


Dear WG,

This starts a working group last = call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, esp= ecially for areas which may be of concern to the broader IETF community.&nb= sp; This WGLC will end on June 27, 2014.

Ted, Sean, Cullen

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


--_000_7594FB04B1934943A5C02806D1A2204B1D35BA0AESESSMB209erics_-- From nobody Tue Jun 10 12:55:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FAB1A02D0 for ; Tue, 10 Jun 2014 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDmy9Jfg9MvF for ; Tue, 10 Jun 2014 12:55:14 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEE71A02C4 for ; Tue, 10 Jun 2014 12:55:14 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so1242939wes.32 for ; Tue, 10 Jun 2014 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N9pCoJk969pAnNVrCCPh8TYNyx1KpoHEjcP+QqGbwTw=; b=CE8mlDHbQTmqziG524SEEayP6LAgma8n/2dovh1JyPANuifwB0w8GrMI+eutxAnFP7 Nuk+TDxnPwXrgvGqiBTmUMgaWJP6KsuxTUvBcxfJjMfyv49+CKEyHrYBsYQPPJwl60kq rHlYBfPgDKytz7U7BZK58H+pC/426ils+qlwsQ1B9EEaw0qTDiMghNWYGK2Sbehj5VdH yXlYnN+p8vdv0L62EejxKRTttFulHoDfws6nGDFRGlP2ZtQdOkT9QaZb5a30/dLYTbQQ dWvWbiPDaRpkWxYW1dj9StHGYjyPuQDNUjRTQKixLW7zRKXu9SYDTpz3B6c/GGsivWOx K1Zg== MIME-Version: 1.0 X-Received: by 10.195.13.79 with SMTP id ew15mr44620122wjd.19.1402430112736; Tue, 10 Jun 2014 12:55:12 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Tue, 10 Jun 2014 12:55:12 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35BA0A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35BA0A@ESESSMB209.ericsson.se> Date: Tue, 10 Jun 2014 14:55:12 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bfd093ab12d7304fb80b499 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Oo8BHsi74SwPcYpuoJM2GEiJL_Y Cc: CLUE Subject: Re: [clue] Fwd: [rtcweb] WGLC for data channel drafts X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:55:16 -0000 --047d7bfd093ab12d7304fb80b499 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 2:45 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I have given some comments. > > > > One issue I have is that the text is very WebRTC specific. It should be > more generic, to allow usage also in other contexts - e.g. CLUE. > [MB] I totally agree. Personally, I'd rather see the material that can be generic in a separate document. But, that's probably too much to ask. So, at a minimum it would be good for that document to be clear the parts in that document that are generic. I don't think CLUE will be the only other usage of SCTP/DTLS/UDP. [/MB] > > > At least me and Paul have commented on this issue before. > > > > > > Regards, > > > > Christer > > > ------------------------------ > *From:* clue [clue-bounces@ietf.org] on behalf of Mary Barnes [ > mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, 10 June, 2014 10:15 PM > *To:* CLUE > *Subject:* [clue] Fwd: [rtcweb] WGLC for data channel drafts > > Given that the CLUE WG data channel document has direct dependencies on > the RTCWEB data channel document, folks in CLUE should review the RTCWEB > document and provide comments. If you think the document is good from the > CLUE perspective, then please post that feedback to the CLUE WG mailing > list. If you see any specific issues with the RTCWEB document, then please > post those on the RTCWEB mailing list as that would be extremely helpful in > getting the document completed in that WG. > > Thanks, > Mary. > > ---------- Forwarded message ---------- > From: Ted Hardie > Date: Tue, Jun 10, 2014 at 1:52 PM > Subject: [rtcweb] WGLC for data channel drafts > To: "rtcweb@ietf.org" > > > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of > concern to the broader IETF community. This WGLC will end on June 27, 2014. > > Ted, Sean, Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7bfd093ab12d7304fb80b499 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 10, 2014 at 2:45 PM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I have given some comments.

=C2=A0

One issue I have is that the text is very WebRTC specific. It should be = more generic, to allow usage also in other contexts=C2=A0- e.g. CLUE.


[MB] I totally agree. Personally= , I'd rather see the material that can be generic in a separate documen= t. But, that's probably too much to ask. So, at a minimum it would be g= ood for that document to be clear the parts in that document that are gener= ic. =C2=A0I don't think CLUE will be the only other usage of =C2=A0 SCT= P/DTLS/UDP. =C2=A0
[/MB]=C2=A0

=C2=A0

At least me and Paul have commented on this issue=C2=A0before.

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

Fro= m: clue [clu= e-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Tuesday, 10 June, 2014 10:15 PM
To: CLUE
Subject: [clue] Fwd: [rtcweb] WGLC for data channel drafts

Given that the CLUE WG data channel document has direct de= pendencies on the RTCWEB data channel document, folks in CLUE should review= the RTCWEB document and provide comments. =C2=A0 If you think the document= is good from the CLUE perspective, then please post that feedback to the CLUE WG mailing list. =C2=A0If you see an= y specific issues with the RTCWEB document, then please post those on the R= TCWEB mailing list as that would be extremely helpful in getting the docume= nt completed in that WG.=C2=A0

Thanks,
Mary.=C2=A0

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, Jun 10, 2014 at 1:52 PM
Subject: [rtcweb] WGLC for data channel drafts
To: "rtcweb@ietf.= org" <rtcw= eb@ietf.org>


Dear WG,

This starts a working group last c= all for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, espe= cially for areas which may be of concern to the broader IETF community.=C2= =A0 This WGLC will end on June 27, 2014.

Ted, Sean, Cullen

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



--047d7bfd093ab12d7304fb80b499-- From nobody Wed Jun 11 22:08:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761FE1A0361 for ; Wed, 11 Jun 2014 22:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 6DXr5Vn6pDpG for ; Wed, 11 Jun 2014 22:07:59 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E2F1A035F for ; Wed, 11 Jun 2014 22:07:59 -0700 (PDT) Received: from ppp118-209-10-214.lns20.mel4.internode.on.net ([118.209.10.214]:57205 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WuxEs-0005r6-Mr for clue@ietf.org; Thu, 12 Jun 2014 15:07:50 +1000 Message-ID: <539935A8.4020308@nteczone.com> Date: Thu, 12 Jun 2014 15:07:52 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1NNexb8IoRmet1ayN7-O_yr3-ok Subject: [clue] Design team meetings announcements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 05:08:01 -0000 Hello Paul and Mary, With respect to the design team meetings would it be possible to confirm the meeting and have the meeting materials available earlier? Say the Friday before the meeting. I think it would be helpful to know definitely whether a design team meeting will go ahead a couple of days before hand to help with planning schedules. I also would find it more beneficial to have drafts/meeting material available a couple of days before the meeting to allow some time for review for educated discussions rather than sighting it at or shortly before the meeting. Regards, Christian From nobody Thu Jun 12 07:42:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB51B2A6E for ; Thu, 12 Jun 2014 07:42:03 -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 KkjTWqwNljEK for ; Thu, 12 Jun 2014 07:42:02 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 0123C1B2A6B for ; Thu, 12 Jun 2014 07:42:01 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id DQVQ1o0060SCNGk56Si19w; Thu, 12 Jun 2014 14:42:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id DSi11o00L3ZTu2S3VSi1Cb; Thu, 12 Jun 2014 14:42:01 +0000 Message-ID: <5399BC39.7010308@alum.mit.edu> Date: Thu, 12 Jun 2014 10:42:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <539935A8.4020308@nteczone.com> In-Reply-To: <539935A8.4020308@nteczone.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=1402584121; bh=2a051fRf6RWfnVzXLPC/Y7oEyeGfl/ioZlcIgd1xdhg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KUKpx6P2WIuCHmUpnNLofp+q/1SaeM3dMVpvwgRFdz3nWKuzdvuhskXMbbNKf+J2i SMNQ7l+PXiuL5h10573Nc+TNCpwbQH84Zo89I2UXfpC91qY6IopJ+nLsVxvodtAFMY uzmmmIBypBalBE78BtFDhLPEwMyxWeut/Vgjvd00+rWvQsuQpprS8pPk9wYT4Mavua Me1Elgking5xHN2lK3iC+xduFXYzJktE0GMU5OQV+zQfzJELVwgRvMFYfEOSrL90eZ +aNpiQpjKhghxvvJXnotbBsE6CiYjVzI+Q5F495+Po7IVw4rLRJs3Uv8Vs5cEtm1wD SnmGZvkJ6RV6A== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TyfAN1lL9ZOT1o9vCc9aroRsXmM Subject: Re: [clue] Design team meetings announcements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:42:03 -0000 Christian, Yes, I'll try to get notice out in advance. Absent an explicit notice, you should go by the schedule on the Wiki - if there is an explicit topic for the date then assume there will be a meeting. (I actually intended to get out the notice about this week's meeting on Monday. I had the message ready to send but forgot to send it until Tues morning. My bad.) Regarding getting the material out in advance - I think that will depend on the individual. If we make these meetings too formal and too planned then it will be harder to get people to talk. Thanks, Paul On 6/12/14 1:07 AM, Christian Groves wrote: > Hello Paul and Mary, > > With respect to the design team meetings would it be possible to confirm > the meeting and have the meeting materials available earlier? Say the > Friday before the meeting. I think it would be helpful to know > definitely whether a design team meeting will go ahead a couple of days > before hand to help with planning schedules. I also would find it more > beneficial to have drafts/meeting material available a couple of days > before the meeting to allow some time for review for educated > discussions rather than sighting it at or shortly before the meeting. > > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Jun 12 07:48:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1311B2A75 for ; Thu, 12 Jun 2014 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drZl-ieHr_hz for ; Thu, 12 Jun 2014 07:48:29 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C9B1A0546 for ; Thu, 12 Jun 2014 07:48:28 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so1451899wes.0 for ; Thu, 12 Jun 2014 07:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BD5vmxH6xqhvrXBP10v7rl92oJWqKpm7oq5CavWw08U=; b=kJtiaqNy4HC3XRPtv2vIy8HmZFruOfo8TG27dNsD2jrOt33r5n7ebmO1VtuAy2jhyX EmzJbvdmict+lqVNgVFhtBuzI/J2/K/wlzhM6meTcx3ijLUhONfhD8UBBvT3WtR5H+fz QnZma50iyOfbpVYkhGbmLL36DjcR8zjBOdXNxn0zWY5uB+eHu77zq++nV/P1i483avSe TVF0vhJo/TLFnHrRt8hqXUVbuL/FmX6c8ekg6HV8sNP4En4Y2t7/IOtDB18N+iQ0AS0X e4Ao+N/TKaz2ngHfpVkrL7Di7an+ahjgnzQgz8e8yRA9BbLv3MGqoxDIvHxq5vcPI+k6 nyRQ== MIME-Version: 1.0 X-Received: by 10.180.105.102 with SMTP id gl6mr7135460wib.7.1402584507045; Thu, 12 Jun 2014 07:48:27 -0700 (PDT) Received: by 10.216.240.194 with HTTP; Thu, 12 Jun 2014 07:48:26 -0700 (PDT) In-Reply-To: <5399BC39.7010308@alum.mit.edu> References: <539935A8.4020308@nteczone.com> <5399BC39.7010308@alum.mit.edu> Date: Thu, 12 Jun 2014 09:48:26 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d04426dd44f62ed04fba4a747 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/y-qmQaEd5EazTeWEaXnrFny_tcQ Cc: CLUE Subject: Re: [clue] Design team meetings announcements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:48:30 -0000 --f46d04426dd44f62ed04fba4a747 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 9:42 AM, Paul Kyzivat wrote: > Christian, > > Yes, I'll try to get notice out in advance. Absent an explicit notice, you > should go by the schedule on the Wiki - if there is an explicit topic for > the date then assume there will be a meeting. (I actually intended to get > out the notice about this week's meeting on Monday. I had the message ready > to send but forgot to send it until Tues morning. My bad.) > [MB] I think the notices on the wiki are sufficient. [/MB] > > Regarding getting the material out in advance - I think that will depend > on the individual. If we make these meetings too formal and too planned > then it will be harder to get people to talk. > [MB] Exactly. Given that the topics are directly related to drafts, issues in the tracker and/or issues being discussed on the mailing list, one should already have a lot of context going into the meetings. I don't think it's reasonable to expect someone to prepare slides early and then have to adjust since the WG should obviously not be waiting for the meetings to discuss the topics. The meetings are intended to provide a higher bandwidth conversation that will hopefully allow us to resolve issues more quickly than relying on email and/or waiting for f2f meetings. [/MB] > > Thanks, > Paul > > > On 6/12/14 1:07 AM, Christian Groves wrote: > >> Hello Paul and Mary, >> >> With respect to the design team meetings would it be possible to confirm >> the meeting and have the meeting materials available earlier? Say the >> Friday before the meeting. I think it would be helpful to know >> definitely whether a design team meeting will go ahead a couple of days >> before hand to help with planning schedules. I also would find it more >> beneficial to have drafts/meeting material available a couple of days >> before the meeting to allow some time for review for educated >> discussions rather than sighting it at or shortly before the meeting. >> >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d04426dd44f62ed04fba4a747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 12, 2014 at 9:42 AM= , Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Christian,

Yes, I'll try to get notice out in advance. Absent an explicit notice, = you should go by the schedule on the Wiki - if there is an explicit topic f= or the date then assume there will be a meeting. (I actually intended to ge= t out the notice about this week's meeting on Monday. I had the message= ready to send but forgot to send it until Tues morning. My bad.)
[MB] I think the notices on the wiki are sufficient. [/MB= ]

Regarding getting the material out in advance - I think that will depend on= the individual. If we make these meetings too formal and too planned then = it will be harder to get people to talk.
[MB] Exactly.= =C2=A0Given that the topics are directly related to drafts, issues in the = tracker and/or issues being discussed on the mailing list, one should alrea= dy have a lot of context going into the meetings. =C2=A0I don't think i= t's reasonable to expect someone to prepare slides early and then have = to adjust since the WG should obviously not be waiting for the meetings to = discuss the topics. The meetings are intended to provide a higher bandwidth= conversation that will hopefully allow us to resolve issues more quickly t= han relying on email and/or waiting for f2f meetings. [/MB]

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

On 6/12/14 1:07 AM, Christian Groves wrote:
Hello Paul and Mary,

With respect to the design team meetings would it be possible to confirm the meeting and have the meeting materials available earlier? Say the
Friday before the meeting. I think it would be helpful to know
definitely whether a design team meeting will go ahead a couple of days
before hand to help with planning schedules. I also would find it more
beneficial to have drafts/meeting material available a couple of days
before the meeting to allow some time for review for educated
discussions rather than sighting it at or shortly before the meeting.


Regards, Christian

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--f46d04426dd44f62ed04fba4a747-- From nobody Thu Jun 12 18:32:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580911B2827 for ; Thu, 12 Jun 2014 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93gO_MLNYzqv for ; Thu, 12 Jun 2014 18:32:01 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6081B280D for ; Thu, 12 Jun 2014 18:32:01 -0700 (PDT) Received: from ppp118-209-240-19.lns20.mel6.internode.on.net ([118.209.240.19]:51671 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WvGLE-00038B-L0 for clue@ietf.org; Fri, 13 Jun 2014 11:31:40 +1000 Message-ID: <539A5489.6060705@nteczone.com> Date: Fri, 13 Jun 2014 11:31:53 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <539935A8.4020308@nteczone.com> <5399BC39.7010308@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Jz35TO8mijJE6rltGRgzK9TrTWg Subject: Re: [clue] Design team meetings announcements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:32:03 -0000 Hello Paul and Mary, I think its good that Paul has been announcing meetings. It serves as a useful prompt. All I'm asking for is that there's a known confirmation time (earlier) so that people in all timezones have a chance to plan for the meeting. Regards, Christian On 13/06/2014 12:48 AM, Mary Barnes wrote: > On Thu, Jun 12, 2014 at 9:42 AM, Paul Kyzivat > wrote: > > Christian, > > Yes, I'll try to get notice out in advance. Absent an explicit > notice, you should go by the schedule on the Wiki - if there is an > explicit topic for the date then assume there will be a meeting. > (I actually intended to get out the notice about this week's > meeting on Monday. I had the message ready to send but forgot to > send it until Tues morning. My bad.) > > [MB] I think the notices on the wiki are sufficient. [/MB] [CNG] I don't think the wiki is sufficient for confirmation. Its not always up to date and doesn't reflect situations like, "we didn't receive input, so there's no meeting." I can't see that having the materials available earlier somehow will harm the conversation? > > > Regarding getting the material out in advance - I think that will > depend on the individual. If we make these meetings too formal and > too planned then it will be harder to get people to talk. > > [MB] Exactly. Given that the topics are directly related to drafts, > issues in the tracker and/or issues being discussed on the mailing > list, one should already have a lot of context going into the > meetings. I don't think it's reasonable to expect someone to prepare > slides early and then have to adjust since the WG should obviously not > be waiting for the meetings to discuss the topics. [CNG] Wouldn't feedback from the WG be a good thing? As for update, we'd be only talking a day or two in advance. Not weeks. > The meetings are intended to provide a higher bandwidth conversation > that will hopefully allow us to resolve issues more quickly than > relying on email and/or waiting for f2f meetings. [/MB] [CNG] Yes, if people had a chance to read the materials before the design team it might make things quicker. Rather than saying "I haven't had time to read the draft, but.....". > > > Thanks, > Paul > > > On 6/12/14 1:07 AM, Christian Groves wrote: > > Hello Paul and Mary, > > With respect to the design team meetings would it be possible > to confirm > the meeting and have the meeting materials available earlier? > Say the > Friday before the meeting. I think it would be helpful to know > definitely whether a design team meeting will go ahead a > couple of days > before hand to help with planning schedules. I also would find > it more > beneficial to have drafts/meeting material available a couple > of days > before the meeting to allow some time for review for educated > discussions rather than sighting it at or shortly before the > meeting. > > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 13 08:24:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEAA1B2921 for ; Fri, 13 Jun 2014 08:24:03 -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 emglhN4_9ANd for ; Fri, 13 Jun 2014 08:24:02 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 0643B1B28ED for ; Fri, 13 Jun 2014 08:24:01 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id DoRN1o0051ei1Bg5BrQ1rx; Fri, 13 Jun 2014 15:24:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id DrQ11o0093ZTu2S3krQ11L; Fri, 13 Jun 2014 15:24:01 +0000 Message-ID: <539B1791.3080709@alum.mit.edu> Date: Fri, 13 Jun 2014 11:24:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <539935A8.4020308@nteczone.com> <5399BC39.7010308@alum.mit.edu> <539A5489.6060705@nteczone.com> In-Reply-To: <539A5489.6060705@nteczone.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=1402673041; bh=rv4DD8hp+j4dGEcGYQFNibGGDrt9vBZtFh1mUsgil9w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TbUWYs42VQEyVREi2bVfBJBHOGNfvroQX3CpgTeqzCWLaS+YpK5wg1HEU+g/x+pJE sQ9F8Ai/mQ4VCZuDIY1nDwZ698kBbp5YjEZWcgqNllO1tvORD8MYu3+/iyVosiqmaS IsbTkfmmrebuA57fDQ3XYzI/VrSa3KGMA6heDbf9z8OU9GSJ7w9SKMncEQbOokqqWZ AXzabVggazWDed9zZGk07auAvjbcRyIOpcY8iZKdGpnMe7maogv2RNvbcT6lNsuH6Z jy1bm90rtkYLkxRAYNPxnWrjaplPB1/H4LdTiWOq2oHNvvM9EHU0qRXjPGg5Fn5cH6 S/UiMMndMijJQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/uWhie8oyeR44sWHThmoEAGn8H_U Subject: Re: [clue] Design team meetings announcements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:24:04 -0000 Christian, As I said - I'll *try*. (But I'm not always very reliable about such things.) But in the absence of such notice you should consider the wiki to be definitive. Thanks, Paul On 6/12/14 9:31 PM, Christian Groves wrote: > Hello Paul and Mary, > > I think its good that Paul has been announcing meetings. It serves as a > useful prompt. All I'm asking for is that there's a known confirmation > time (earlier) so that people in all timezones have a chance to plan for > the meeting. > > Regards, Christian > > On 13/06/2014 12:48 AM, Mary Barnes wrote: >> On Thu, Jun 12, 2014 at 9:42 AM, Paul Kyzivat > > wrote: >> >> Christian, >> >> Yes, I'll try to get notice out in advance. Absent an explicit >> notice, you should go by the schedule on the Wiki - if there is an >> explicit topic for the date then assume there will be a meeting. >> (I actually intended to get out the notice about this week's >> meeting on Monday. I had the message ready to send but forgot to >> send it until Tues morning. My bad.) >> >> [MB] I think the notices on the wiki are sufficient. [/MB] > [CNG] I don't think the wiki is sufficient for confirmation. Its not > always up to date and doesn't reflect situations like, "we didn't > receive input, so there's no meeting." I can't see that having the > materials available earlier somehow will harm the conversation? >> >> >> Regarding getting the material out in advance - I think that will >> depend on the individual. If we make these meetings too formal and >> too planned then it will be harder to get people to talk. >> >> [MB] Exactly. Given that the topics are directly related to drafts, >> issues in the tracker and/or issues being discussed on the mailing >> list, one should already have a lot of context going into the >> meetings. I don't think it's reasonable to expect someone to prepare >> slides early and then have to adjust since the WG should obviously not >> be waiting for the meetings to discuss the topics. > [CNG] Wouldn't feedback from the WG be a good thing? As for update, we'd > be only talking a day or two in advance. Not weeks. >> The meetings are intended to provide a higher bandwidth conversation >> that will hopefully allow us to resolve issues more quickly than >> relying on email and/or waiting for f2f meetings. [/MB] > [CNG] Yes, if people had a chance to read the materials before the > design team it might make things quicker. Rather than saying "I haven't > had time to read the draft, but.....". >> >> >> Thanks, >> Paul >> >> >> On 6/12/14 1:07 AM, Christian Groves wrote: >> >> Hello Paul and Mary, >> >> With respect to the design team meetings would it be possible >> to confirm >> the meeting and have the meeting materials available earlier? >> Say the >> Friday before the meeting. I think it would be helpful to know >> definitely whether a design team meeting will go ahead a >> couple of days >> before hand to help with planning schedules. I also would find >> it more >> beneficial to have drafts/meeting material available a couple >> of days >> before the meeting to allow some time for review for educated >> discussions rather than sighting it at or shortly before the >> meeting. >> >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Jun 13 09:46:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BB91B29A4; Fri, 13 Jun 2014 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 SHRaUs8RbC-S; Fri, 13 Jun 2014 09:46:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B6F741B2993; Fri, 13 Jun 2014 09:46:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CCD911801C2; Fri, 13 Jun 2014 09:45:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140613164530.CCD911801C2@rfc-editor.org> Date: Fri, 13 Jun 2014 09:45:30 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ixU_t3TP97Aod3-YBIDAzf2zymE Cc: drafts-update-ref@iana.org, clue@ietf.org, rfc-editor@rfc-editor.org Subject: [clue] RFC 7262 on Requirements for Telepresence Multistreams X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:46:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7262 Title: Requirements for Telepresence Multistreams Author: A. Romanow, S. Botzko, M. Barnes Status: Informational Stream: IETF Date: June 2014 Mailbox: allyn@cisco.com, stephen.botzko@polycom.com, mary.ietf.barnes@gmail.com Pages: 12 Characters: 26403 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-clue-telepresence-requirements-07.txt URL: http://www.rfc-editor.org/rfc/rfc7262.txt This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. This document is a product of the ControLling mUltiple streams for tElepresence Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jun 13 10:16:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959C21A0203 for ; Fri, 13 Jun 2014 10:16:04 -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 1WZpdk8vphie for ; Fri, 13 Jun 2014 10:16:03 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id DF40A1B29B9 for ; Fri, 13 Jun 2014 10:16:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id Dnj11o0051ap0As57tG20a; Fri, 13 Jun 2014 17:16:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id DtG21o00R3ZTu2S3itG2bT; Fri, 13 Jun 2014 17:16:02 +0000 Message-ID: <539B31D2.5020105@alum.mit.edu> Date: Fri, 13 Jun 2014 13:16:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: CLUE References: <20140613164530.CCD911801C2@rfc-editor.org> In-Reply-To: <20140613164530.CCD911801C2@rfc-editor.org> X-Forwarded-Message-Id: <20140613164530.CCD911801C2@rfc-editor.org> 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=1402679762; bh=jEqKA0MQnoPyBJst/BR67JNDiWjTWYkYDuo81Yfj6QU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wo4BEf9zfXgI0C6ld5WpQpJrxWESttowDlBMEFPljv9o1PbWP95bX1TM8bsqR58NX uDuD6/rx3eIPzMrtvE0D63ZkgAvIMY+yi3mmG+ODwoyU59zNg8DAIycn5v2F6E5l5h S2t/2y5azd5GniYvjhDbVepcy2U+HPK+axelGvFawDXPSP9h6SUau2DtsO6cgamKVa Gd8Y2lELfTbkejzPUELXQ/4IZp9nae460094rS3/RP+XEP/6STHTKVvhW2PRlfERd5 69iGGCgdtoEMJaQGtY9wamHpxptNVj2myj9W/SYVsj5pafNcUPniw3sv2bxiU/DrN1 qGYjpsaN/ey6g== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/J2AF2z7Qutm80IJcFsrjxjxgClY Subject: [clue] RFC 7262 on Requirements for Telepresence Multistreams X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:16:06 -0000 Congratulations!!! Now we just need to finish the mechanism drafts. Thanks, Paul -------- Original Message -------- Subject: [clue] RFC 7262 on Requirements for Telepresence Multistreams Date: Fri, 13 Jun 2014 09:45:30 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, clue@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7262 Title: Requirements for Telepresence Multistreams Author: A. Romanow, S. Botzko, M. Barnes Status: Informational Stream: IETF Date: June 2014 Mailbox: allyn@cisco.com, stephen.botzko@polycom.com, mary.ietf.barnes@gmail.com Pages: 12 Characters: 26403 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-clue-telepresence-requirements-07.txt URL: http://www.rfc-editor.org/rfc/rfc7262.txt This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. This document is a product of the ControLling mUltiple streams for tElepresence Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 16 03:58:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2391B2BB0 for ; Mon, 16 Jun 2014 03:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.471 X-Spam-Level: * X-Spam-Status: No, score=1.471 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abQ3Iq988boQ for ; Mon, 16 Jun 2014 03:58:56 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36A11B2BA3 for ; Mon, 16 Jun 2014 03:58:55 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so3822643wiv.16 for ; Mon, 16 Jun 2014 03:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=LDiilrTk+YBC8ynzIrkGe9xL9LVv15N5PFqTJHqWjo4=; b=GCxpubI6ypL8OWzgiqNYiDTA+robtm1LL5qQAp7hymMPuIHB2QycesR6ujb71lbpSc 5RPjDxESqLaUiGj8q5MeC6xCQspqM+EyF0F/HyPwWI1bMVvVo8ZHDBmypNOjnFlLaPzZ d5i5q1onadN4UtMNp5FY8w4VecOBEWmgL4tmMeiPOiT0/hyYEmNxQ5CjGMsZSHSnAfUY fa6fmg1Mi1SduOVE5KGQpQazv5i9W+vB0FbKz7Bspb1bRXDW0GUMFUsIc3TveF4fu7uc jjvo2PZcLYQErQunx3ArVxfsTCc1NGD2Nhlb+s0uI6bZV4UHnmR5RMs3TT5eCiY+sgoh bgQQ== X-Received: by 10.194.120.103 with SMTP id lb7mr17197449wjb.40.1402916333996; Mon, 16 Jun 2014 03:58:53 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id l5sm14012120wif.22.2014.06.16.03.58.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Jun 2014 03:58:53 -0700 (PDT) From: "Roni Even" To: Date: Mon, 16 Jun 2014 13:58:49 +0300 Message-ID: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01CF896B.1ADCAED0" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac+JUSH3h5nut8ctS+6tIeYgqnQC9Q== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/U13sr8V7sCEFu3aZm3IDtCIFUcQ Subject: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 10:58:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018B_01CF896B.1ADCAED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, While working on the call flows I have the following question After opening the SCTP connection using the SCTP INIT message we need to open the CLUE channel using DCEP. This is being done using an SCTP DATA message. The first DCEP message is DATA_CHANNEL_OPEN send as app data in the SCTP DATA message. What I was wondering is which PPID goes with this message, I assumed that it is 51 which is CLUE protocol but I am not sure. If we send PPID 50 are we going to use afterwards the CLUE message using PPID 51 with the same SCTP stream identifier as the webRTC channel open message? Roni ------=_NextPart_000_018B_01CF896B.1ADCAED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

While working = on the call flows I have the following question

After opening the SCTP connection using the SCTP INIT = message we need to open the CLUE channel using DCEP.

This is being done using an SCTP DATA = message.

The first DCEP message is = DATA_CHANNEL_OPEN send as app data in the SCTP DATA message. What I was = wondering is which PPID goes with this message, I assumed that it is 51 = which is CLUE protocol but I am not sure.

If we send PPID 50 are we going to use afterwards the = CLUE message using PPID 51 with the same SCTP stream identifier as the = webRTC channel open message?

Roni

------=_NextPart_000_018B_01CF896B.1ADCAED0-- From nobody Mon Jun 16 07:13:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1A1A0032 for ; Mon, 16 Jun 2014 07:13:03 -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 mtdHjggtXCid for ; Mon, 16 Jun 2014 07:13:02 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A81A002B for ; Mon, 16 Jun 2014 07:13:00 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id F0qm1o0010xGWP8552D02D; Mon, 16 Jun 2014 14:13:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id F2Cz1o0123ZTu2S3Y2D0ak; Mon, 16 Jun 2014 14:13:00 +0000 Message-ID: <539EFB6B.8000208@alum.mit.edu> Date: Mon, 16 Jun 2014 10:12:59 -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: clue@ietf.org References: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> In-Reply-To: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.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=1402927980; bh=u80cEbyvWuiXhgJ8L7p56xJmTQKevoDMaTltHQYrcx0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uqDL9daHIYXAFtZk4Lip44T6EjYrEB1/N6Abtwl2LztG+mkeYGw9C3aVKP6rLJ/QK 3XlKn0rjUtsYzC5ieYU0Bc+EB8EzEEvE+vFdW3YdwQjHyBBtR0sP2Ek8mLRbbbSvcz 9IqIKObe4ygj/axnvwtjAj3mX1/CRGkU6MIZTRqnPYCFCjOq7n5BpCYpy5VOfue8g+ /cy9CgHEtFONlt9esq18NHuYNlsjLUD11mI4f+GbTYgLOpjYHfOOvbr9eQf5kpx/JW mUP6OcoHqE0xyLHx/PYl0KhQwfY8+58f0EiOBHSijqjTC1+DuqasgLLwkjSHNa329U pYeZ0dh4oUzFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xu-gTL4CkEBK3HQEJXMzyoWO8Gg Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:13:03 -0000 On 6/16/14 6:58 AM, Roni Even wrote: > Hi, > > While working on the call flows I have the following question > > After opening the SCTP connection using the SCTP INIT message we need to > open the CLUE channel using DCEP. > > This is being done using an SCTP DATA message. > > The first DCEP message is DATA_CHANNEL_OPEN send as app data in the SCTP > DATA message. What I was wondering is which PPID goes with this message, > I assumed that it is 51 which is CLUE protocol but I am not sure. > > If we send PPID 50 are we going to use afterwards the CLUE message using > PPID 51 with the same SCTP stream identifier as the webRTC channel open > message? PPID 50 is used for DCEP (establishment) messages. PPID 51 is used for other (content) messages, in our case for CLUE protocol messages. They are sent on the same streamid. Thanks, Paul From nobody Mon Jun 16 07:22:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E191A0035 for ; Mon, 16 Jun 2014 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCWpSbQnczqz for ; Mon, 16 Jun 2014 07:22:28 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EA21A002B for ; Mon, 16 Jun 2014 07:22:28 -0700 (PDT) Received: from [216.82.249.212:62322] by server-15.bemta-12.messagelabs.com id 81/26-19062-4ADFE935; Mon, 16 Jun 2014 14:22:28 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1402928547!11239080!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9223 invoked from network); 16 Jun 2014 14:22:27 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-8.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jun 2014 14:22:27 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 16 Jun 2014 07:22:27 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 16 Jun 2014 07:22:23 -0700 Thread-Topic: Audio channel format - RE: [clue] Note that XY-stereo microphones are commonly available Thread-Index: Ac9uR5Ir9vVjPvxTSPycBgX6YqTJcAbIysWg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> <20140513010623.GD6449@verdi> In-Reply-To: <20140513010623.GD6449@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bP7Sk_IadsSQEhgWfJccpr1EvY8 Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:22:30 -0000 I don't think we resolved this issue, about the media capture attribute "au= dio channel format", and how it relates to the audio encoding parameters th= at are negotiated in SDP. I have a revised suggestion to resolve it. Does= anybody else have input on this issue? >From the May 13 2014 design team minutes: "It was agreed that spatial audio in general should be included with th= e codec and will be done in SDP." But there were also other issues about different formats such as "separated= mic stereo" and "XY stereo". I think binaural would fit here too. These = are different 2-channel formats, that could all use the same codec and enco= ding parameters, but yet would still have different meaning at a higher lev= el that could affect how the rendering side chooses streams to receive and = how it renders. I think a media capture attribute is the right place in th= e CLUE model to describe this. So my revised suggestion is to keep the "audio channel format" capture attr= ibute, but add some additional possible values: - mono - separated mic stereo - XY stereo - binaural - 3-channel (left, center, right, like separated mic stereo but with 3 chan= nels) - 5.1 surround? (not sure where to draw the line on more multi-channel form= ats) I think the framework should also add some better explanation of the differ= ence between the *capture* format and the *encoding* format. For example a= provider could offer a 3-channel capture as a 3-channel or stereo or mono = encoding (potentially with different codecs), to be compatible with receive= rs that can't receive 3-channel. (Existing non-CLUE equipment does this to= day with different available encodings for the same capture, without specif= ying the audio channel format at the capture level). Regards, Mark > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Monday, May 12, 2014 9:06 PM > To: Duckworth, Mark > Cc: John Leslie; clue@ietf.org > Subject: Re: Audio channel format - RE: [clue] Note that XY-stereo > microphones are commonly available >=20 > Duckworth, Mark wrote: > > [John Leslie wrote:] > >> Duckworth, Mark wrote: > >>> > >>> I'm thinking this "audio channel format" parameter is really a > >>> characteristic of a particular audio *encoding*, not an audio > >>> *capture*. > >> > >>> So my idea is we should remove this audio capture attribute from the > >>> framework and data model. The format of a particular audio encoding > >>> would be described entirely in SDP (not CLUE messages). > >> > >> I'm not _opposed_ to that; but there are _so_many_details_... >=20 > Alas, the bottom-line, regarding tomorrows design-team call, is that I= won't > have time to get into details before mid-week. :^( >=20 > >>> And a media provider could advertise one single audio capture for > >>> the whole room, which maybe it could encode as mono, or stereo, or > >>> 3 channel, or surround sound, or whatever. Or maybe even offer > >>> multiple encodings for simulcast, but these are still all just > >>> different encodings of the same audio capture. >=20 > (Note that there are other cases than whole-room capture that we shoul= d > deal with, IMHO.) >=20 > >> I'm not sure how to manage that, though. If a mix is prepared in > >> 5.1 surround, I doubt that SDP is the right conduit for negotiating > >> the number of channels -- offhand that sounds like a middlebox task. > > > > [Duckworth, Mark] Maybe we're talking about different things, because > > I think SDP is exactly the right thing for this, and is commonly done > > today, at least with stereo and mono. >=20 > No doubt it would help for Mark and me to exchange email as I study th= is > later this week. >=20 > > Endpoints I am familiar with today are capable of encoding their > > outgoing room audio as mono, stereo, and in some cases 3 channel. > > If the receiving side (whether middlebox or another endpoint) is > > capable only of mono, then the sender and receiver negotiate mono. > > This is done with SDP offer/answer today. And I think it should be > > done that way with CLUE also. >=20 > That sounds superficially reasonable. Some details which come to mind = are > how to proceed when receiving audio from two or more sending rooms... >=20 > >> And I'm _sure_ SDP isn't the right conduit for remapping the > >> components of a whole-room feed to fit an incompatible conference > room paradigm. >=20 > Well, I was sure yesterday, anyway. ;^) >=20 > > [Duckworth, Mark] It isn't about conserving bandwidth. It is about a > > receiver selecting an audio encoding format it is capable of decoding. >=20 > That does sound like an SDP issue. >=20 > I had assumed multi-room teleconferencing systems would be able to > decode at least one multi-channel surround format. >=20 > -- > John Leslie From nobody Mon Jun 16 07:50:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FE51A0058 for ; Mon, 16 Jun 2014 07:50: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 px9CQlFyZLMh for ; Mon, 16 Jun 2014 07:50:15 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A2AD61A0041 for ; Mon, 16 Jun 2014 07:50:15 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id F1dC1o0011uE5Es5E2qFrN; Mon, 16 Jun 2014 14:50:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id F2qE1o00P3ZTu2S3c2qFT2; Mon, 16 Jun 2014 14:50:15 +0000 Message-ID: <539F0426.6040900@alum.mit.edu> Date: Mon, 16 Jun 2014 10:50:14 -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: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> <20140513010623.GD6449@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.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=1402930215; bh=bvjDaeNn+jSjZ5GhGUQYBiqSJipclduC2ZchXQFOBeg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MilqJLKI97GoHd78q1DiQELlvN/ZHEdqq0/2WkVh6ky77EHrTst+JBqTMEEce265m hb6Dlj6lUKAjVUyBIagCRHUZ479bUv3D4APxpK5jlL2Q8eOUXlek82R+egqnRKZqFi 9O5dZIZiiXWivWAlRlq45KjkIh8OUtmZ90ndJ/oogLWaCaGwtyjPZwBqpGwOYyYEqa +Uq82sp+pjlT9oK3rD02G4kR6XH8DvGxTPdYexUuqslgMCsZSpZI3gXz8au7/IlZSl uwWa3tdDHy1LiSjCM/EHb9NaqQf/iFqD1YgwVwjAw940Fkj5TWmvLvlVjdGj/e5ick lEW6jOzuu9ZHg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fgTGtstkctvv3Gmd_sgdePOtx3M Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:50:26 -0000 On 6/16/14 10:22 AM, Duckworth, Mark wrote: > I don't think we resolved this issue, about the media capture attribute "audio channel format", and how it relates to the audio encoding parameters that are negotiated in SDP. I have a revised suggestion to resolve it. Does anybody else have input on this issue? > >>From the May 13 2014 design team minutes: > > "It was agreed that spatial audio in general should be included with the codec and will be done in SDP." > > But there were also other issues about different formats such as "separated mic stereo" and "XY stereo". I think binaural would fit here too. These are different 2-channel formats, that could all use the same codec and encoding parameters, but yet would still have different meaning at a higher level that could affect how the rendering side chooses streams to receive and how it renders. I think a media capture attribute is the right place in the CLUE model to describe this. > > So my revised suggestion is to keep the "audio channel format" capture attribute, but add some additional possible values: > - mono > - separated mic stereo > - XY stereo > - binaural > - 3-channel (left, center, right, like separated mic stereo but with 3 channels) > - 5.1 surround? (not sure where to draw the line on more multi-channel formats) This seems reasonable to me. > I think the framework should also add some better explanation of the difference between the *capture* format and the *encoding* format. > For example a provider could offer a 3-channel capture as a 3-channel or stereo or mono encoding (potentially with different codecs), to be compatible with receivers that can't receive 3-channel. > (Existing non-CLUE equipment does this today with different available encodings for the same capture, without specifying the audio channel format at the capture level). Hmm. Here you are talking about a single *capture* represented via different encodings. We have decided that encodings are represented solely in SDP. So the differences you are talking about here need to be representable in SDP. But above you are calling out mono and stereo as *capture* formats. OK, lets talk about this in the design team call tomorrow. We have no proposal close the "issue" on echo, so we are not going to talk about that tomorrow. Thanks, Paul > Regards, > Mark > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Monday, May 12, 2014 9:06 PM >> To: Duckworth, Mark >> Cc: John Leslie; clue@ietf.org >> Subject: Re: Audio channel format - RE: [clue] Note that XY-stereo >> microphones are commonly available >> >> Duckworth, Mark wrote: >>> [John Leslie wrote:] >>>> Duckworth, Mark wrote: >>>>> >>>>> I'm thinking this "audio channel format" parameter is really a >>>>> characteristic of a particular audio *encoding*, not an audio >>>>> *capture*. >>>> >>>>> So my idea is we should remove this audio capture attribute from the >>>>> framework and data model. The format of a particular audio encoding >>>>> would be described entirely in SDP (not CLUE messages). >>>> >>>> I'm not _opposed_ to that; but there are _so_many_details_... >> >> Alas, the bottom-line, regarding tomorrows design-team call, is that I won't >> have time to get into details before mid-week. :^( >> >>>>> And a media provider could advertise one single audio capture for >>>>> the whole room, which maybe it could encode as mono, or stereo, or >>>>> 3 channel, or surround sound, or whatever. Or maybe even offer >>>>> multiple encodings for simulcast, but these are still all just >>>>> different encodings of the same audio capture. >> >> (Note that there are other cases than whole-room capture that we should >> deal with, IMHO.) >> >>>> I'm not sure how to manage that, though. If a mix is prepared in >>>> 5.1 surround, I doubt that SDP is the right conduit for negotiating >>>> the number of channels -- offhand that sounds like a middlebox task. >>> >>> [Duckworth, Mark] Maybe we're talking about different things, because >>> I think SDP is exactly the right thing for this, and is commonly done >>> today, at least with stereo and mono. >> >> No doubt it would help for Mark and me to exchange email as I study this >> later this week. >> >>> Endpoints I am familiar with today are capable of encoding their >>> outgoing room audio as mono, stereo, and in some cases 3 channel. >>> If the receiving side (whether middlebox or another endpoint) is >>> capable only of mono, then the sender and receiver negotiate mono. >>> This is done with SDP offer/answer today. And I think it should be >>> done that way with CLUE also. >> >> That sounds superficially reasonable. Some details which come to mind are >> how to proceed when receiving audio from two or more sending rooms... >> >>>> And I'm _sure_ SDP isn't the right conduit for remapping the >>>> components of a whole-room feed to fit an incompatible conference >> room paradigm. >> >> Well, I was sure yesterday, anyway. ;^) >> >>> [Duckworth, Mark] It isn't about conserving bandwidth. It is about a >>> receiver selecting an audio encoding format it is capable of decoding. >> >> That does sound like an SDP issue. >> >> I had assumed multi-room teleconferencing systems would be able to >> decode at least one multi-channel surround format. >> >> -- >> John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 16 08:07:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884FF1A0066 for ; Mon, 16 Jun 2014 08:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 iP66nHvL3uD7 for ; Mon, 16 Jun 2014 08:06:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AF9DA1A006C for ; Mon, 16 Jun 2014 08:06:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8E3B1C94BF; Mon, 16 Jun 2014 11:06:53 -0400 (EDT) Date: Mon, 16 Jun 2014 11:06:53 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20140616150653.GA85889@verdi> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> <20140513010623.GD6449@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SO02m9o1WvKYzQTjvNtdwH0gJGg Cc: "clue@ietf.org" Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:07:02 -0000 Duckworth, Mark wrote: > > I don't think we resolved this issue, about the media capture attribute > "audio channel format", and how it relates to the audio encoding > parameters that are negotiated in SDP. My memory is foggy... > I have a revised suggestion to resolve it. Does anybody else have input > on this issue? > >> From the May 13 2014 design team minutes: > > "It was agreed that spatial audio in general should be included with the > codec and will be done in SDP." That doesn't exactly fit my memory... > But there were also other issues about different formats such as > "separated mic stereo" and "XY stereo". I think binaural would fit here > too. These are different 2-channel formats, that could all use the same > codec and encoding parameters, but yet would still have different > meaning at a higher level that could affect how the rendering side > chooses streams to receive and how it renders. I quite agree. > I think a media capture attribute is the right place in the CLUE model > to describe this. > > So my revised suggestion is to keep the "audio channel format" capture > attribute, but add some additional possible values: > - mono > - separated mic stereo > - XY stereo > - binaural > - 3-channel (left, center, right, like separated mic stereo but with 3 > channels) > - 5.1 surround? (not sure where to draw the line on more multi-channel > formats) +1 On the surround-sound question, IMHO 5.1 is the most common form, and others can be processed to it easily enough. > I think the framework should also add some better explanation of the > difference between the *capture* format and the *encoding* format. +1 -- John Leslie From nobody Mon Jun 16 08:08:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FEC1A0073 for ; Mon, 16 Jun 2014 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOr5_SlUdBVH for ; Mon, 16 Jun 2014 08:08:35 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D661A006E for ; Mon, 16 Jun 2014 08:08:35 -0700 (PDT) Received: from [216.82.254.20:29395] by server-13.bemta-7.messagelabs.com id 30/9A-16819-3780F935; Mon, 16 Jun 2014 15:08:35 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1402931307!12019566!14 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3068 invoked from network); 16 Jun 2014 15:08:34 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jun 2014 15:08:34 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 16 Jun 2014 08:08:18 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 16 Jun 2014 08:08:18 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 16 Jun 2014 08:08:16 -0700 Thread-Topic: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available Thread-Index: Ac+JclLrpW9PFC9BT2CkgqOlUTE+jQAAMCFw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F01210259@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> <20140513010623.GD6449@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> <539F0426.6040900@alum.mit.edu> In-Reply-To: <539F0426.6040900@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gw2SumLVvbketNoT5CRLxnYLPfA Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:08:38 -0000 Hi Paul, I'm saying the *encoding* information needs to be represented in SDP, and I= believe it already is with no additions needed for CLUE. This encoding in= formation about the codec and codec parameters includes information about t= he number of audio channels in the encoding. But suppose it is a 2-channel= encoding, it still does not say anything about which type of 2-channel enc= oding it is (separated mic, XY, binaural). My suggestion is to leave that = information as a capture attribute. I suppose we would also need to specif= y what it means if a surround or 3-channel capture is sent as a 2-channel e= ncoding - which 2-channel format is it? Maybe we can say it should be trea= ted as separated mic stereo? Or maybe the capture attribute should allow m= ultiple values so the provider can specify it? So far, the only encoding format I know about that would benefit from the a= dditional capture attribute information is a 2-channel encoding. If the en= coding is mono, 3-channel, or surround, then I don't have any example of wh= at additional information the capture attribute could provide. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, June 16, 2014 10:50 AM > To: clue@ietf.org > Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo > microphones are commonly available >=20 > On 6/16/14 10:22 AM, Duckworth, Mark wrote: > > I don't think we resolved this issue, about the media capture attribute > "audio channel format", and how it relates to the audio encoding paramete= rs > that are negotiated in SDP. I have a revised suggestion to resolve it. = Does > anybody else have input on this issue? > > > >>From the May 13 2014 design team minutes: > > > > "It was agreed that spatial audio in general should be included wi= th the > codec and will be done in SDP." > > > > But there were also other issues about different formats such as > "separated mic stereo" and "XY stereo". I think binaural would fit here = too. > These are different 2-channel formats, that could all use the same codec = and > encoding parameters, but yet would still have different meaning at a high= er > level that could affect how the rendering side chooses streams to receive > and how it renders. I think a media capture attribute is the right place= in the > CLUE model to describe this. > > > > So my revised suggestion is to keep the "audio channel format" capture > attribute, but add some additional possible values: > > - mono > > - separated mic stereo > > - XY stereo > > - binaural > > - 3-channel (left, center, right, like separated mic stereo but with 3 > > channels) > > - 5.1 surround? (not sure where to draw the line on more multi-channel > > formats) >=20 > This seems reasonable to me. >=20 > > I think the framework should also add some better explanation of the > difference between the *capture* format and the *encoding* format. > > For example a provider could offer a 3-channel capture as a 3-channel o= r > stereo or mono encoding (potentially with different codecs), to be > compatible with receivers that can't receive 3-channel. > > (Existing non-CLUE equipment does this today with different available > encodings for the same capture, without specifying the audio channel form= at > at the capture level). >=20 > Hmm. Here you are talking about a single *capture* represented via > different encodings. We have decided that encodings are represented solel= y > in SDP. So the differences you are talking about here need to be > representable in SDP. But above you are calling out mono and stereo as > *capture* formats. >=20 > OK, lets talk about this in the design team call tomorrow. >=20 > We have no proposal close the "issue" on echo, so we are not going to tal= k > about that tomorrow. >=20 > Thanks, > Paul >=20 > > Regards, > > Mark > > > >> -----Original Message----- > >> From: John Leslie [mailto:john@jlc.net] > >> Sent: Monday, May 12, 2014 9:06 PM > >> To: Duckworth, Mark > >> Cc: John Leslie; clue@ietf.org > >> Subject: Re: Audio channel format - RE: [clue] Note that XY-stereo > >> microphones are commonly available > >> > >> Duckworth, Mark wrote: > >>> [John Leslie wrote:] > >>>> Duckworth, Mark wrote: > >>>>> > >>>>> I'm thinking this "audio channel format" parameter is really a > >>>>> characteristic of a particular audio *encoding*, not an audio > >>>>> *capture*. > >>>> > >>>>> So my idea is we should remove this audio capture attribute from > >>>>> the framework and data model. The format of a particular audio > >>>>> encoding would be described entirely in SDP (not CLUE messages). > >>>> > >>>> I'm not _opposed_ to that; but there are _so_many_details_... > >> > >> Alas, the bottom-line, regarding tomorrows design-team call, is > >> that I won't have time to get into details before mid-week. :^( > >> > >>>>> And a media provider could advertise one single audio capture for > >>>>> the whole room, which maybe it could encode as mono, or stereo, or > >>>>> 3 channel, or surround sound, or whatever. Or maybe even offer > >>>>> multiple encodings for simulcast, but these are still all just > >>>>> different encodings of the same audio capture. > >> > >> (Note that there are other cases than whole-room capture that we > >> should deal with, IMHO.) > >> > >>>> I'm not sure how to manage that, though. If a mix is prepared in > >>>> 5.1 surround, I doubt that SDP is the right conduit for negotiating > >>>> the number of channels -- offhand that sounds like a middlebox task. > >>> > >>> [Duckworth, Mark] Maybe we're talking about different things, > >>> because I think SDP is exactly the right thing for this, and is > >>> commonly done today, at least with stereo and mono. > >> > >> No doubt it would help for Mark and me to exchange email as I > >> study this later this week. > >> > >>> Endpoints I am familiar with today are capable of encoding their > >>> outgoing room audio as mono, stereo, and in some cases 3 channel. > >>> If the receiving side (whether middlebox or another endpoint) is > >>> capable only of mono, then the sender and receiver negotiate mono. > >>> This is done with SDP offer/answer today. And I think it should be > >>> done that way with CLUE also. > >> > >> That sounds superficially reasonable. Some details which come to > >> mind are how to proceed when receiving audio from two or more sending > rooms... > >> > >>>> And I'm _sure_ SDP isn't the right conduit for remapping the > >>>> components of a whole-room feed to fit an incompatible conference > >> room paradigm. > >> > >> Well, I was sure yesterday, anyway. ;^) > >> > >>> [Duckworth, Mark] It isn't about conserving bandwidth. It is about a > >>> receiver selecting an audio encoding format it is capable of decoding= . > >> > >> That does sound like an SDP issue. > >> > >> I had assumed multi-room teleconferencing systems would be able > >> to decode at least one multi-channel surround format. > >> > >> -- > >> John Leslie > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 16 10:17:25 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711711A0084 for ; Mon, 16 Jun 2014 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOAauqG6YwUX for ; Mon, 16 Jun 2014 10:17:23 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738B71A000B for ; Mon, 16 Jun 2014 10:17:23 -0700 (PDT) Received: from [216.82.254.19:59049] by server-6.bemta-7.messagelabs.com id 65/41-08569-2A62F935; Mon, 16 Jun 2014 17:17:22 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-96.messagelabs.com!1402939041!13075987!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28039 invoked from network); 16 Jun 2014 17:17:22 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-3.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jun 2014 17:17:22 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 16 Jun 2014 10:17:21 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 16 Jun 2014 10:17:19 -0700 Thread-Topic: removing area of capture for audio Thread-Index: Ac+JghdqRcUjEW03Q+OS5h250OB5jw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/koz5r8TFG4Nlu96k658rJ4q11Vw Subject: [clue] removing area of capture for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:17:24 -0000 If the group agrees, I will update the framework to disallow use of area of= capture for audio. More below. Let me know if you agree. >From the minutes of the May 13 2014 design team: > 5. Intended-capture-area polygon > After some discussion it was agreed that capture "area" (2-dimensional) i= s > not applicable for audio, and should, if anything, be a "volume" (3-dimen= sional). > It was agreed that a better way of defining this capture volume would be = in=20 > terms of the microphone physical location (point of capture), the generic= =20 > microphone directivity pattern, and the microphone axis of orientation (i= f directional). Referring to the data model, I think what this means is that if the provide= r wants to give spatial information for audio captures, the provider should= not (MUST NOT?) use the element within the "spatialInformati= onType". The provider should use the element, which also in= cludes . This makes sense to me, so if the group agree= s with it I will update the framework section 7.1.1 to make this clear, fro= m the semantic point of view of the framework. I will also have to update = some examples in section 12. I think the data model would need changes also, either clarifying text that= is not allowed for audio, or changing the schema to make it = impossible to use for audio. Regards, Mark From nobody Mon Jun 16 11:08:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9321A014C for ; Mon, 16 Jun 2014 11:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc729XLbL-q7 for ; Mon, 16 Jun 2014 11:08:10 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A91A001A for ; Mon, 16 Jun 2014 11:08:09 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so5932757wes.7 for ; Mon, 16 Jun 2014 11:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=D1t3KR1Cx7e1EkrEvSIOjHONnUySfBCeU1pLBDq7Ck0=; b=rliQ/4PYSCooXx+xkWBPtg9BiXMt0XPsNakuHAks/k8rLWJA20GAnrz+Yhg2JZn7I4 680FvJlogU1Sj2GgLQ2kz833LhPvJFxPzsVXG/ui+TwU5iIrihMM1pWlUFXL1TMRcV0C tMdbjLtyQLI0wHfJ7OUO1L9nY1Df7GJlUg6anRYmNqw/QccvpedaxnPmMww01pDDYVFY J3Z2QX+N5GEbevX46HFiUMd28Hym8LTDyEL8D6hW0u0lpTKLkWHr+6pug9btAxkP7E2m OG0uhU4/84vKaE8b6VZ58xWEtNci2ziAOh3M8kVUpZYnC/jQyCMtPhQDWOfKKfE0YOML 1vDQ== X-Received: by 10.194.71.19 with SMTP id q19mr31179071wju.21.1402942088191; Mon, 16 Jun 2014 11:08:08 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id bp2sm16018879wib.9.2014.06.16.11.08.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Jun 2014 11:08:07 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> <539EFB6B.8000208@alum.mit.edu> In-Reply-To: <539EFB6B.8000208@alum.mit.edu> Date: Mon, 16 Jun 2014 21:08:02 +0300 Message-ID: <01bd01cf898d$ec319460$c494bd20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQH7CSQ5LvrhSDlX66bRcOrfyZh9AAIehjOumwwU/TA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_BxB7iUA3s645W3uPIotdeF8PLM Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:08:11 -0000 Paul, Thanks, so we could have also use the protocol parameter in the DATA_CHANNEL_OPEN to specify CLUE? Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 16 June, 2014 5:13 PM > To: clue@ietf.org > Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 > > On 6/16/14 6:58 AM, Roni Even wrote: > > Hi, > > > > While working on the call flows I have the following question > > > > After opening the SCTP connection using the SCTP INIT message we need > > to open the CLUE channel using DCEP. > > > > This is being done using an SCTP DATA message. > > > > The first DCEP message is DATA_CHANNEL_OPEN send as app data in the > > SCTP DATA message. What I was wondering is which PPID goes with this > > message, I assumed that it is 51 which is CLUE protocol but I am not sure. > > > > If we send PPID 50 are we going to use afterwards the CLUE message > > using PPID 51 with the same SCTP stream identifier as the webRTC > > channel open message? > > PPID 50 is used for DCEP (establishment) messages. > > PPID 51 is used for other (content) messages, in our case for CLUE protocol > messages. > > They are sent on the same streamid. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 16 11:42:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5031A016D for ; Mon, 16 Jun 2014 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOcHHK-z8h-e for ; Mon, 16 Jun 2014 11:42:44 -0700 (PDT) Received: from BLU004-OMC1S36.hotmail.com (blu004-omc1s36.hotmail.com [65.55.116.47]) by ietfa.amsl.com (Postfix) with ESMTP id 126801A0169 for ; Mon, 16 Jun 2014 11:42:43 -0700 (PDT) Received: from BLU0-SMTP85 ([65.55.116.7]) by BLU004-OMC1S36.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Mon, 16 Jun 2014 11:42:43 -0700 X-TMN: [mbEfNSRLfDwRcOctckufdCe9433J1djG] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.62.229]) by BLU0-SMTP85.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jun 2014 11:42:42 -0700 From: Paul Coverdale To: "'Duckworth, Mark'" , References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> Date: Mon, 16 Jun 2014 14:42:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac+JghdqRcUjEW03Q+OS5h250OB5jwADqeQQ Content-Language: en-us X-OriginalArrivalTime: 16 Jun 2014 18:42:42.0401 (UTC) FILETIME=[C1A3ED10:01CF8992] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZRFF8bSgkYhY0pt3bRsQCZ-9tkc Subject: Re: [clue] removing area of capture for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:42:45 -0000 Hi Mark, Yes, based on the discussion during the May 13 Design team meeting I think we need to remove the concept of area of capture for audio from the Framework. I think it needs to be specifically stated in section 7.1.1.3 that area of capture is only applicable to video. To convey spatial information for audio, we can use point of capture and point on line of capture as you propose, but I think we need to introduce another element to define the generic microphone directivity pattern. Regards, ...Paul >-----Original Message----- >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >Sent: Monday, June 16, 2014 1:17 PM >To: clue@ietf.org >Subject: [clue] removing area of capture for audio > >If the group agrees, I will update the framework to disallow use of area >of capture for audio. More below. Let me know if you agree. > >>From the minutes of the May 13 2014 design team: > >> 5. Intended-capture-area polygon >> After some discussion it was agreed that capture "area" >> (2-dimensional) is not applicable for audio, and should, if anything, >be a "volume" (3-dimensional). >> It was agreed that a better way of defining this capture volume would >> be in terms of the microphone physical location (point of capture), >> the generic microphone directivity pattern, and the microphone axis of >orientation (if directional). > >Referring to the data model, I think what this means is that if the >provider wants to give spatial information for audio captures, the >provider should not (MUST NOT?) use the element within the >"spatialInformationType". The provider should use the >element, which also includes . This makes sense to >me, so if the group agrees with it I will update the framework section >7.1.1 to make this clear, from the semantic point of view of the >framework. I will also have to update some examples in section 12. > >I think the data model would need changes also, either clarifying text >that is not allowed for audio, or changing the schema to >make it impossible to use for audio. > >Regards, >Mark > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 16 11:55:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442CF1A0163 for ; Mon, 16 Jun 2014 11:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rec2C6lwSl5 for ; Mon, 16 Jun 2014 11:54:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925C61A0058 for ; Mon, 16 Jun 2014 11:54:57 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-f5-539f3d7f4c7f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.C4.25910.F7D3F935; Mon, 16 Jun 2014 20:54:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Mon, 16 Jun 2014 20:54:55 +0200 From: Christer Holmberg To: Roni Even , 'Paul Kyzivat' , "clue@ietf.org" Thread-Topic: [clue] clarfication question for draft-ietf-clue-datachannel-00 Thread-Index: Ac+JUSH3h5nut8ctS+6tIeYgqnQC9QACy4WAAAg1gwAABdCWNg== Date: Mon, 16 Jun 2014 18:54:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D388BED@ESESSMB209.ericsson.se> References: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> <539EFB6B.8000208@alum.mit.edu>,<01bd01cf898d$ec319460$c494bd20$@gmail.com> In-Reply-To: <01bd01cf898d$ec319460$c494bd20$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW697fxgg/dNthb7T11mtlix4QCr xd92Zgdmj7/vPzB57Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZh15vYi3YzVNxYP9R5gbG Z5xdjJwcEgImEvMbW9kgbDGJC/fWA9lcHEICRxklVkxYzQrhLGKUWPO4l6mLkYODTcBCovuf NkiDiEChRM/rR6wgtrCAj8TfpiXMEHFfiU+nv7JD2E4Sq/7NAYuzCKhKrP33CGwZL1DNsUnP 2SHmtzJKrN5yBCzBCTR/57n5TCA2I9BF30+tAbOZBcQlbj2BiEsICEgs2XOeGcIWlXj5+B8r hK0o0f60gRGiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY RYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAmPn4JbfBjsYXz53PMQowMGoxMO7wGB+sBBrYllx Ze4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFyc5bXrbsLBzHbPmujl j65w7mgPyVgm8PBhdPO7j6f2L3kcnWu+d/n8ujufl5myfX2nEWLbVvvzK+PahBXxW/9Oz32z 0vsS16/I1WoLdc8q2dhfcz/++vla7+pLq1MttojeSXmWWX7Z+Wz9iSkmqfcVJtmsv8y4yXCq feKZdQ8rwxVsOKc+f1WnxFKckWioxVxUnAgAlRbRzn4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7nJcwjLWQ4Fpu-jPupkWveSGPUs Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:54:59 -0000 Hi, > Thanks, so we could have also use the protocol parameter in the > DATA_CHANNEL_OPEN to specify CLUE? Correct. Regards, Christer > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 16 June, 2014 5:13 PM > To: clue@ietf.org > Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 > > On 6/16/14 6:58 AM, Roni Even wrote: > > Hi, > > > > While working on the call flows I have the following question > > > > After opening the SCTP connection using the SCTP INIT message we need > > to open the CLUE channel using DCEP. > > > > This is being done using an SCTP DATA message. > > > > The first DCEP message is DATA_CHANNEL_OPEN send as app data in the > > SCTP DATA message. What I was wondering is which PPID goes with this > > message, I assumed that it is 51 which is CLUE protocol but I am not sure. > > > > If we send PPID 50 are we going to use afterwards the CLUE message > > using PPID 51 with the same SCTP stream identifier as the webRTC > > channel open message? > > PPID 50 is used for DCEP (establishment) messages. > > PPID 51 is used for other (content) messages, in our case for CLUE protocol > messages. > > They are sent on the same streamid. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From nobody Mon Jun 16 12:06:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D821A018A for ; Mon, 16 Jun 2014 12:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xoHTZlnOWaa3 for ; Mon, 16 Jun 2014 12:05:57 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 47B581A0189 for ; Mon, 16 Jun 2014 12:05:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 35966C94C4; Mon, 16 Jun 2014 15:05:54 -0400 (EDT) Date: Mon, 16 Jun 2014 15:05:54 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140616190554.GA18220@verdi> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> <20140513010623.GD6449@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F01210249@CRPMBOXPRD08.polycom.com> <539F0426.6040900@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539F0426.6040900@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RUWdZW1i1_8hToYA5QLkPgkxuVQ Cc: clue@ietf.org Subject: [clue] Design Team Meeting -- audio issues X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:06:06 -0000 Paul Kyzivat wrote: > > We have no proposal close the "issue" on echo, so we are not going to > talk about that tomorrow. It's OK with me to not discuss it; but I ought to bring folks up to date. >From the minutes I found at http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140513.txt ] 8. Whether echo cancellation is done ] This issue provoked a lot of discussion. Paul C has the view that, while ] echo cancellation is certainly important for Telepresence, it is beyond ] the scope of CLUE. John L's view is that it is too important to be left ] to "chance", and something explicit needs to be signaled. Paul K will ] issue a call for consensus on the mailing list. I've done some substantial research on this; and I've found that my proposal on the 13th was simply wrong. There really is no single definition of what "echo cancellation" means in terms of echo reduction decibels, and there's no reason to expect one to magically appear. The only definitons of "echo suppression" in terms of decibels amount to "drop the power to zero and add comfort noise" -- which is even less useful. I have since found definitions of "Echo Return Loss" and "Echo Return Loss Enhancement" (in Cisco documentation as well as several other vendors) which strike me as useful. "Echo Return Loss" is the number of decibels that the echo picked up at the microphone is below the received signal sent to the loudspeaker(s). "Echo Return Loss Enhancement" is the number of decibels below that which is accomplished by echo-cancellation. These are already-defined numbers which IMHO would be useful to pass from sending sites to receiving sites. The receiving sites could decline to use audio feeds where these numbers are too low; or they could enforce echo-suppression to give a single-duplex experience to sites with inadequate echo-management numbers. It remains (IMHO) far better to know the problem in advance. (BTW, the IESG has given up on calling the roll to see who's present; so the level of constant annoyance I've been experiencing has dropped. ;^) -- John Leslie From nobody Mon Jun 16 14:01:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AEC1A022D for ; Mon, 16 Jun 2014 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olW0B0bCNfr7 for ; Mon, 16 Jun 2014 14:01:07 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29781A0234 for ; Mon, 16 Jun 2014 14:01:06 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so4764843wiv.8 for ; Mon, 16 Jun 2014 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=WP4Tb0yILle0A0NeMI1JA39aZUyCtExPtLEHtDw4/2A=; b=d5qfxGzjvn5vXm1urRmekO7xCf95H/0zeQhjYsSdz5BUiOlTc5hJLNd0wuwCtXqVtc wccWM9WJ2mJtMekfvgjHmUK/Dl1+Y2W9ESyQ2wPBFTf95La07hRz6cSSjHaHKyLSORN4 zanGKT5vLhQ7pH59CNikHsuppjItow0A2loqSim1JGDBGtK3ITABDhHi3B4dsNAkxoEj MMqJka22HN6K4WxPdUHT3fff219CupMeNcsr4MnUnOTy6rMSHA5zWd8oJqQtfDn905Dx 1ErqmN1txcblF9ahbGVBNonjPi9vgTjzpnb9pjXka5NTt8U7algmcfX+dh3DoYLvH6mQ 4wfw== X-Received: by 10.180.126.8 with SMTP id mu8mr31075805wib.10.1402952465328; Mon, 16 Jun 2014 14:01:05 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id di10sm20301102wjb.1.2014.06.16.14.01.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Jun 2014 14:01:04 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> <539EFB6B.8000208@alum.mit.edu>, <01bd01cf898d$ec319460$c494bd20$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D388BED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D388BED@ESESSMB209.ericsson.se> Date: Tue, 17 Jun 2014 00:01:00 +0300 Message-ID: <01c701cf89a6$15785da0$406918e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQH7CSQ5LvrhSDlX66bRcOrfyZh9AAIehjOuAldFL48CB8xNIZrpTNiw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wOnbSiEetko6uKmc4I_HLe0w8-w Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:01:08 -0000 Hi, So should we add the CLUE protocol registration for DATA_CHANNEL_OPEN? Roni > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 16 June, 2014 9:55 PM > To: Roni Even; 'Paul Kyzivat'; clue@ietf.org > Subject: RE: [clue] clarfication question for draft-ietf-clue-datachannel-00 > > Hi, > > > Thanks, so we could have also use the protocol parameter in the > > DATA_CHANNEL_OPEN to specify CLUE? > > Correct. > > Regards, > > Christer > > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 16 June, 2014 5:13 PM > > To: clue@ietf.org > > Subject: Re: [clue] clarfication question for > draft-ietf-clue-datachannel-00 > > > > On 6/16/14 6:58 AM, Roni Even wrote: > > > Hi, > > > > > > While working on the call flows I have the following question > > > > > > After opening the SCTP connection using the SCTP INIT message we > > > need to open the CLUE channel using DCEP. > > > > > > This is being done using an SCTP DATA message. > > > > > > The first DCEP message is DATA_CHANNEL_OPEN send as app data in the > > > SCTP DATA message. What I was wondering is which PPID goes with this > > > message, I assumed that it is 51 which is CLUE protocol but I am not > sure. > > > > > > If we send PPID 50 are we going to use afterwards the CLUE message > > > using PPID 51 with the same SCTP stream identifier as the webRTC > > > channel open message? > > > > PPID 50 is used for DCEP (establishment) messages. > > > > PPID 51 is used for other (content) messages, in our case for CLUE > protocol > > messages. > > > > They are sent on the same streamid. > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue= From nobody Mon Jun 16 18:16:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF91A0081 for ; Mon, 16 Jun 2014 18:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6T_fuTcYtTt for ; Mon, 16 Jun 2014 18:16:31 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170091A0064 for ; Mon, 16 Jun 2014 18:16:30 -0700 (PDT) Received: from ppp118-209-238-181.lns20.mel6.internode.on.net ([118.209.238.181]:56689 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wwi0d-0000fi-Pb for clue@ietf.org; Tue, 17 Jun 2014 11:16:23 +1000 Message-ID: <539F96E3.1040900@nteczone.com> Date: Tue, 17 Jun 2014 11:16:19 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <018a01cf8951$f58f28b0$e0ad7a10$@gmail.com> <539EFB6B.8000208@alum.mit.edu>, <01bd01cf898d$ec319460$c494bd20$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D388BED@ESESSMB209.ericsson.se> <01c701cf89a6$15785da0$406918e0$@gmail.com> In-Reply-To: <01c701cf89a6$15785da0$406918e0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/X8jF1QOO7Yh6wvyTQuwvl-mV26g Subject: Re: [clue] clarfication question for draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 01:16:33 -0000 Hello Roni, Yes we should. This is captured by a note in cl.4.1 of the draft: NOTE: A new 'protocol' value for CLUE needs to be registered with IANA in the 'Protocol Registry' defined by [I-D.ietf-rtcweb-data-protocol]. Regards, Christian On 17/06/2014 7:01 AM, Roni Even wrote: > Hi, > So should we add the CLUE protocol registration for DATA_CHANNEL_OPEN? > Roni > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 16 June, 2014 9:55 PM >> To: Roni Even; 'Paul Kyzivat'; clue@ietf.org >> Subject: RE: [clue] clarfication question for > draft-ietf-clue-datachannel-00 >> Hi, >> >>> Thanks, so we could have also use the protocol parameter in the >>> DATA_CHANNEL_OPEN to specify CLUE? >> Correct. >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 16 June, 2014 5:13 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] clarfication question for >> draft-ietf-clue-datachannel-00 >>> On 6/16/14 6:58 AM, Roni Even wrote: >>>> Hi, >>>> >>>> While working on the call flows I have the following question >>>> >>>> After opening the SCTP connection using the SCTP INIT message we >>>> need to open the CLUE channel using DCEP. >>>> >>>> This is being done using an SCTP DATA message. >>>> >>>> The first DCEP message is DATA_CHANNEL_OPEN send as app data in the >>>> SCTP DATA message. What I was wondering is which PPID goes with this >>>> message, I assumed that it is 51 which is CLUE protocol but I am not >> sure. >>>> If we send PPID 50 are we going to use afterwards the CLUE message >>>> using PPID 51 with the same SCTP stream identifier as the webRTC >>>> channel open message? >>> PPID 50 is used for DCEP (establishment) messages. >>> >>> PPID 51 is used for other (content) messages, in our case for CLUE >> protocol >>> messages. >>> >>> They are sent on the same streamid. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue= > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 16 18:33:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17CA1A007B for ; Mon, 16 Jun 2014 18:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 WtagH_49wpuY for ; Mon, 16 Jun 2014 18:33:17 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E191A0076 for ; Mon, 16 Jun 2014 18:33:16 -0700 (PDT) Received: from ppp118-209-238-181.lns20.mel6.internode.on.net ([118.209.238.181]:56894 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WwiGs-0003OQ-Kg for clue@ietf.org; Tue, 17 Jun 2014 11:33:10 +1000 Message-ID: <539F9AD2.4040508@nteczone.com> Date: Tue, 17 Jun 2014 11:33:06 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/A4x_WqS3xSUxmtMxi7J6xDiGSxg Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 01:33:19 -0000 Hello Mark, Please see my comments below. Regards, Christian On 14/05/2014 10:03 AM, Duckworth, Mark wrote: > > I’m looking at more terms and concepts that are used both in CLUE and > in draft-ietf-avtext-rtp-grouping-taxonomy-01. > > Should we add some of this to the framework definitions section, to > indicate how the CLUE terms relate to taxonomy terms? > > CLUE Media Capture: I’m not sure about this. I was going to say it is > the same as taxonomy Media Capture, with either physical stimulus or > synthetic stimulus. But the taxonomy draft says a CLUE Media Capture > is the same as a taxonomy Media Source. I don’t see how it makes any > difference to CLUE either way. What do you think? > [CNG] I think CLUE captures can be either a RTP taxonomy media capture or media source. The distinguishing factor appears to be that the media capture is raw stream and a media source is a processed stream. CLUE media captures could be either. This could be updated in the taxonomy draft. > > CLUE Individual Encoding: I think this is parameters of the taxonomy > Media Encoder transformation. Taxonomy draft says “CLUE’s ‘Capture > Encoding’ provides specific encoding configuration for this purpose > [Media Encoder]”. I think it should be “CLUE’s ‘Individual Encoding’”, > not “Capture Encoding”. (suggest change this in taxonomy draft, also > in Packet Stream section) > [CNG] I agree individual coding would be more appropriate. > CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest add > this to taxonomy draft) > [CNG] I think its similar but not the same. A CLUE capture encoding does result in an encoded stream but due to the link with a CLUE media capture ID there is also semantic information that is associated with the encoded stream. > > CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already > equates CLUE Stream with Packet Stream). > > CLUE Endpoint: includes a taxonomy End Point and a Participant. > [CNG] Yes > > CLUE MCU: includes multiple taxonomy End Points and a Participant for > each conference. > [CNG] Yes > > I can post suggestions to avtext to change the taxonomy draft > regarding these CLUE terms, but I’d like to hear feedback from this > group first. > > Regards, > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 17 00:04:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42C1A0299 for ; Tue, 17 Jun 2014 00:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrmi4DXznHUW for ; Tue, 17 Jun 2014 00:04:27 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DF81A0286 for ; Tue, 17 Jun 2014 00:04:26 -0700 (PDT) Received: from ppp118-209-238-181.lns20.mel6.internode.on.net ([118.209.238.181]:60199 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WwnRJ-0001Ym-79 for clue@ietf.org; Tue, 17 Jun 2014 17:04:17 +1000 Message-ID: <539FE86F.7000902@nteczone.com> Date: Tue, 17 Jun 2014 17:04:15 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Rp1hp0aPzkemd9UyrxxhArXPsZc Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 07:04:30 -0000 Hello, In summary I think its fairly good although the audio issue is still a worry. My comments: Issues ========= Cl.3 Advertisement: " the formatting of the media streams it can send" can probably be deleted as we removed the encoding information. Cl.3 Capture Encoding: How critical is the use of RTP for a capture encoding? I would think anything defined to carry media would be appropriate, obviously RTP is the most used example. So perhaps we can change that to: ".... to a Media Consumer, e.g. via RTP." Cl.3 Capture Scene: Is it really a region containing one or more capture devices? The scene may not actually contain the capture device. I would think it would be more appropriate to say something like "a structure representing the region captured by one or more media captures..." Cl.3 General: Do we need a term to describe when multiple Capture Scenes are used to give an overall "picture" of the endpoint, i.e. GCSE? Cl.3 Media Consumer/Media Provider - Should this say MCU? Cl.3 Model: Is this definition needed or valid in the current CLUE framework? The use of "model" in the draft doesn't appear to reflect this definition. Cl.3 Render: A rendered video may be as a result of multiple media. I propose "... a representation from media..." Cl.3 Single Media Capture: "i.e. audio capture, video capture" don't really represent a single capture they represent a "single capture type". I think it would be more correct to say "i.e. an audio capture from a single microphone, a video capture from a single camera." Cl.5 para.2: Rather than say "formatting of the media streams" it should say something like "media stream encodings"? Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE channel is only established later in the call. Either we could have "SHOULD" or say something like "MUST occur when a CLUE channel is established in the call". Cl.5 para.5: Is there a double definition of "media capture"? In this paragraph it says that a media capture describes the content. Whereas the definition in cl.3 says " Media Capture: a source of Media, such as from one or more Capture Devices or constructed from other Media streams." There's nothing about description of content here. Cl.5 para.6: " A Consumer chooses which Media Captures it wants to receive from each Capture Scene." A Consumer doesn't have to choose any MCs from a scene. I'd suggested replace "each" with "the", i.e. "...receive from the Capture Scenes." Cl.5 para.7 : "...media attributes of the Encodings" (and following text). This can be deleted as these are not contained in the Advertisement any more. Cl.5 fig.1 : Does this need to be updated to remove maxBandWidth or at least move it to the encoding group level? Also does the global CSE need to be added as a box like the STS? Cl.5 pg.13 para.1: "Voice Activated Stream Switching" via updated CLUE signalling is that something we've decided for CLUE? Cl.5 pg.13 para.2: Do we need the sentence " Obviously, this is not a particularly sensible design choice in almost all conceivable cases."? Cl.7.1.1.8 : There's the note regarding the different types of presentation. Is there any interest for values beyond "image" and "slides"? Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial relationship between scenes. However this paragraph is a little "fuzzy" implying there may be relationship between scenes. Whilst physically there may a relationship a consumer has no way of knowing this. The default behaviour will not be to associate scenes. Cl.9.1 para.3 : "The parameter of an Individual Encoding represent the maximum values", is this the case now? As the individual encoding parameter are now defined by SDP they could mean anything, not just maximum values. I think this paragraph needs to be updated to reflect this. Cl.9.2: There is no explicit mention of whether individual encodings of multiple media types i.e. audio and video can belong to a single group. Cl.10 para.2: I don't see the "special" handling outlined in this paragraph. A consumer would have a separate CLUE channel with each provider and treat the associations differently? Cl.10 Pg.39 para.2: ", and includes the encoding parameter values" should be deleted. A configure doesn't respond with these values. Also in the paragraph below the text regarding parameters should be deleted also. Cl.11 Para 1: Do we need the text about new industry and future directions? Can't we just mention how the framework is extensible? Cl.11 bullet 3: New codecs should be added to SDP not CLUE. We could remove this bullet. Cl.13 : How much do you have to input to get a mention? (hint) Editorial ========= General: I think the draft would read better if constructions such as "is sending" and "is receiving" are changed to "sends" and "receives", i.e. cl.4 para.2 "represents the entity that sends the media". "is not supporting" => "does not support" General: Defined terms "Provider", "Advertisement" etc. should have there first character capitalized. Cl.1 Para.1 : References to CLUE drafts can be updated to RFCs. Cl.3 AudioCapture: ". Denoted as ACn in the examples in this document." Cl.3 Font: "In going towards back..." Cl.4 (1): The first part of the sentence talks about the past, so I suggest changing "... for example, there was no mechanism..." Cl.4 (2): Consistency "...are multiple capturing and rendering..." or "...are multiple capture and render..." Cl.7.1.1 Para.1: "... for the benefit of the Consumer the Advertisement message" or "A Provider can use the Media Capture Attributes in an Advertisement to describe the Capture for the benefit of the Consumer". Cl.7.1.1.7 Reword " The Description attribute is a human-readable description (which could be in multiple languages) of the Capture." Otherwise it reads that the capture could be in multiple languages not the description. (Similar comment to cl.7.3.2) Cl.8 Pg.33 Para.2 : "...are shown in Table 1" => "... are shown in Table 5." Cl.9 "...please refer to section 4" => "...please refer to section 5"? Cl.10 para.4: "As a general outline, Consumer..." Regards, Christian On 7/06/2014 1:35 AM, Mary Barnes wrote: > Hi all, > > As discussed at the interim meeting, this is a two week pre-WGLC > review for the framework document: > http://www.ietf.org/id/draft-ietf-clue-framework-15.txt > > The objective of this pre-WGLC review is for folks to take a fresh > look at the document and re-review the entire document. Right now, > there are just a couple outstanding issues: > - #35 (consistency with the data model document) > - audio issue (that still needs to be detailed by John Leslie) > - issues reflected by editor's notes in the document for which we will > open new tickets > > This review is intended to ensure that there are no other outstanding > issues so that once we close the above open issues the document is > ready for WGLC. > > Note, reviews that provide a general summary and then separate the > major and minor issues from the editorial nits, something like the > following, would be quite helpful. > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > Major issues: > > Minor Issues: > > Editorial nits: > > Please review and send any comments to the mailing list no later than > Friday, June 20th, 2014. > > Thanks, > Mary. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 17 05:08:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295C71A035D for ; Tue, 17 Jun 2014 05:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLMXNXYtxbiO for ; Tue, 17 Jun 2014 05:08:50 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B851A035C for ; Tue, 17 Jun 2014 05:08:49 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-ab-53a02fcff253 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.CA.25910.FCF20A35; Tue, 17 Jun 2014 14:08:48 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 14:08:47 +0200 From: Bo Burman To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] more taxonomy Thread-Index: Ac9u8GFqVUnsOP5fTpiqTclwzPXLpgayvGAAABlQ6PA= Date: Tue, 17 Jun 2014 12:08:47 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> <539F9AD2.4040508@nteczone.com> In-Reply-To: <539F9AD2.4040508@nteczone.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4F/QXBBo+v8Fl8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSujoXMiS8E6+YqFXT2MDYw/JLoYOTgkBEwk fn8q62LkBDLFJC7cW8/WxcjFISRwlFHi2L39LBDOEkaJ2avnMYNUsQloSMzfcZcRxBYRCJfo 2HYFzBYWUJS4te4vC0RcSeLBmT1QtpXE702XwGpYBFQl1k6bDzaHV8BX4uyWVjYQW0igUKLr eyNYDaeAjkT7qV6wGkYBWYn73++BzWEWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scK8YySxLSt aRDlOhILdn9ig7C1JZYtfA21VlDi5MwnLBMYRWchmToLScssJC2zkLQsYGRZxShanFqclJtu ZKSXWpSZXFycn6eXl1qyiREYJQe3/DbYwfjyueMhRgEORiUe3gUG84OFWBPLiitzDzFKc7Ao ifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj5GPLZAPZiiyv8CeHLTOV4TieV3Lr RpyA7p6pZ5T/Zpqf/x7idC5v+aJ3e6paezVOfFrC5MPA8CVq20KG1KfrKj9PWuUteF3z8mmx upsMdzk6ZZVNFjLxsB7mv7XYouvsny1tnzP/zly5ctWjgEcaj0qSG1SmyG99uKuSj+vhR8O7 7clLZAyjlFiKMxINtZiLihMB3RCid3MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/F2S9b2kHRwHQzwmjTFjxtbVa0QE Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 12:08:55 -0000 Hi, I am currently updating the RTP Taxonomy, so this review of CLUE terms is r= eally welcome. I plan to submit a new version of the Taxonomy draft within = the next few days and would like to include the result of this discussion. Please find a few comments and questions inline below. Cheers, Bo > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: den 17 juni 2014 03:33 > To: clue@ietf.org > Subject: Re: [clue] more taxonomy >=20 > Hello Mark, >=20 > Please see my comments below. >=20 > Regards, Christian >=20 > On 14/05/2014 10:03 AM, Duckworth, Mark wrote: > > > > I'm looking at more terms and concepts that are used both in CLUE and > > in draft-ietf-avtext-rtp-grouping-taxonomy-01. > > > > Should we add some of this to the framework definitions section, to > > indicate how the CLUE terms relate to taxonomy terms? > > > > CLUE Media Capture: I'm not sure about this. I was going to say it is > > the same as taxonomy Media Capture, with either physical stimulus or > > synthetic stimulus. But the taxonomy draft says a CLUE Media Capture > > is the same as a taxonomy Media Source. I don't see how it makes any > > difference to CLUE either way. What do you think? > > > [CNG] I think CLUE captures can be either a RTP taxonomy media capture or= media source. The distinguishing factor > appears to be that the media capture is raw stream and a media source is = a processed stream. CLUE media captures could > be either. This could be updated in the taxonomy draft. [BoB] OK > > > > CLUE Individual Encoding: I think this is parameters of the taxonomy > > Media Encoder transformation. Taxonomy draft says "CLUE's 'Capture > > Encoding' provides specific encoding configuration for this purpose > > [Media Encoder]". I think it should be "CLUE's 'Individual Encoding'", > > not "Capture Encoding". (suggest change this in taxonomy draft, also > > in Packet Stream section) > > > [CNG] I agree individual coding would be more appropriate. [BoB] OK >=20 > > CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest add > > this to taxonomy draft) > > > [CNG] I think its similar but not the same. A CLUE capture encoding does = result in an encoded stream but due to the link > with a CLUE media capture ID there is also semantic information that is a= ssociated with the encoded stream. [BoB] OK. I get a feeling that the CLUE capture encoding term is (at least = in the CLUE framework) mostly used to describe an Encoded Stream, but is so= metimes also used to denote the Media Encoder transformation and the result= is then (correctly) described as a Stream. Am I correct? If so, do you wan= t to change that "duality" of capture encoding, or do you rather prefer tha= t I just reflect this fact in the Taxonomy? > > > > CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already > > equates CLUE Stream with Packet Stream). > > >=20 > > CLUE Endpoint: includes a taxonomy End Point and a Participant. > > > [CNG] Yes [BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple en= tities running separate RTP stacks), or is that an unnecessary generalizati= on? > > > > CLUE MCU: includes multiple taxonomy End Points and a Participant for > > each conference. > > > [CNG] Yes [BoB] You mean the MCU itself is a Participant in each conference and as su= ch also includes multiple End Points per conference, right? > > > > I can post suggestions to avtext to change the taxonomy draft > > regarding these CLUE terms, but I'd like to hear feedback from this > > group first. > > > > Regards, > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 17 06:05:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547571A037B for ; Tue, 17 Jun 2014 06:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKsFxyX3qFOY for ; Tue, 17 Jun 2014 06:05:19 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752EA1A0375 for ; Tue, 17 Jun 2014 06:05:19 -0700 (PDT) Received: from ppp118-209-238-181.lns20.mel6.internode.on.net ([118.209.238.181]:52387 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wwt4U-00045q-8G for clue@ietf.org; Tue, 17 Jun 2014 23:05:06 +1000 Message-ID: <53A03D03.3000507@nteczone.com> Date: Tue, 17 Jun 2014 23:05:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/G76pzlv8aLCEuLFhfEtQ55a5FgY Subject: Re: [clue] removing area of capture for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:05:24 -0000 Hello Mark, Yes I agree. I think its a "MUST NOT". Regards, Christian On 17/06/2014 3:17 AM, Duckworth, Mark wrote: > If the group agrees, I will update the framework to disallow use of area of capture for audio. More below. Let me know if you agree. > > >From the minutes of the May 13 2014 design team: > >> 5. Intended-capture-area polygon >> After some discussion it was agreed that capture "area" (2-dimensional) is >> not applicable for audio, and should, if anything, be a "volume" (3-dimensional). >> It was agreed that a better way of defining this capture volume would be in >> terms of the microphone physical location (point of capture), the generic >> microphone directivity pattern, and the microphone axis of orientation (if directional). > Referring to the data model, I think what this means is that if the provider wants to give spatial information for audio captures, the provider should not (MUST NOT?) use the element within the "spatialInformationType". The provider should use the element, which also includes . This makes sense to me, so if the group agrees with it I will update the framework section 7.1.1 to make this clear, from the semantic point of view of the framework. I will also have to update some examples in section 12. > > I think the data model would need changes also, either clarifying text that is not allowed for audio, or changing the schema to make it impossible to use for audio. > > Regards, > Mark > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Jun 18 05:12:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE011A01EE for ; Wed, 18 Jun 2014 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_7bGyq32_Hz for ; Wed, 18 Jun 2014 05:12:06 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4E81A01E8 for ; Wed, 18 Jun 2014 05:12:05 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so738231wes.22 for ; Wed, 18 Jun 2014 05:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=0wEk0tCEZNHvQJtVDUyc11lkwHU74q5L4LaxydK7GUk=; b=ub6tfMjF1k2MA0Yk2mly5n9gn1/d1AGJOJ77b0wSbCD8zhjM6fg6gpiiBS9O7P99bQ WXNjtrVHc6jPqDpm2bFa/3g6/QKfcR3pH5WsNb9RU5LNat57CUKgybXUpvbr9NneT+oA +I86YXTYrrBm0+uteH1wx3gdEgCt3Xhl8Loplsty9B62dmftdNc65qSwmDynAGliz3hY Twz1BMGUv7zjpEdAg21lncH8gdxjHD5QNEL7o8hOb3TqEfaCxkfMtrD4zJ8imVDasoZQ PtTOhTSxg58Or3sEM6o7o0WlSaRg5ULjE3Ds8kKN9vlKwSX+kHgcPTbQdbGiv434I4Ly tsAg== X-Received: by 10.194.71.19 with SMTP id q19mr47922898wju.21.1403093524145; Wed, 18 Jun 2014 05:12:04 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id wk8sm2575743wjb.22.2014.06.18.05.12.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Jun 2014 05:12:03 -0700 (PDT) From: "Roni Even" To: Date: Wed, 18 Jun 2014 15:11:59 +0300 Message-ID: <027401cf8aee$82f75310$88e5f930$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0275_01CF8B07.A8452750" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac+K7oFL36vXpH6rTVik9W2Hi7AjOA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_bzlBolO7qSWBCWasrYcsaMTzOw Subject: [clue] Comment on option response indraft-presta-clue-protocol-04 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:12:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0275_01CF8B07.A8452750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I was looking at the OPTION response What is the responseCode and why a string. (in other messgaes it is "short") need to define values Media Provider and Consumer are mandatory and not optional Roni ------=_NextPart_000_0275_01CF8B07.A8452750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I was looking = at the OPTION response

 

<xs:element name=3D"responseCode" = type=3D"xs:string"/>

= <xs:element name=3D"reasonString" = type=3D"xs:string"/>

= <xs:element name=3D"mediaProvider" = type=3D"xs:boolean" = minOccurs=3D"0"/>

= <xs:element name=3D"mediaConsumer" = type=3D"xs:boolean" = minOccurs=3D"0"/>

 

 

What is the = responseCode and why a string. (in other messgaes it is = “short”) need to define values

 

Media = Provider and Consumer are mandatory and not optional

 

Roni

------=_NextPart_000_0275_01CF8B07.A8452750-- From nobody Thu Jun 19 07:11:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056321A036F for ; Thu, 19 Jun 2014 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3PfiPC0UHSx for ; Thu, 19 Jun 2014 07:11:10 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA7C1A01EE for ; Thu, 19 Jun 2014 07:11:09 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so2314250wgg.34 for ; Thu, 19 Jun 2014 07:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k/cLouiAlpS1uW/umFa2k50NVhYdHKkIc5zTduhuJfs=; b=ofv1xXJgqMvu1WUSAD0VWteyoP/PZlb3oF/ZescsklMPt8uNNddU2+wKn8BRgxP0MT HdZrT46ceZIf/Xpe0V4fqebvUKlGDShgh31Fw69AuYoVzYu4JfTieP9xtunu9f03SMX6 hF+mcw0kq7dzJHyEqMpyAubu0qw/n5pPOdc9OMJJhnmaba7ajzFcH+n4nf4DFbTvBcoJ dQeu9VAEoBTpmsviR/OmShc01PGmtkI1rXoB6sSjCRhe0SJTi+4dsOaLfPsofBH88wdL +ts1x9VWfFIclv80FmhlwOeisCAuKqgxJiqAn+ves2jGDRCTJl22jvKzj5ax4AG9EW+5 Q+LA== MIME-Version: 1.0 X-Received: by 10.194.60.198 with SMTP id j6mr5399074wjr.86.1403187068684; Thu, 19 Jun 2014 07:11:08 -0700 (PDT) Received: by 10.217.116.201 with HTTP; Thu, 19 Jun 2014 07:11:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jun 2014 09:11:08 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b86d578c84fa704fc30f2b1 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/AZjpTq-P9GY65hnDdo9XPYOdoaU Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:11:15 -0000 --047d7b86d578c84fa704fc30f2b1 Content-Type: text/plain; charset=UTF-8 Hi all, Note that this pre-WGLC ends tomorrow. So far, we've only had one set of review comments posted to the mailing list. Mary. On Fri, Jun 6, 2014 at 10:35 AM, Mary Barnes wrote: > Hi all, > > As discussed at the interim meeting, this is a two week pre-WGLC review > for the framework document: > http://www.ietf.org/id/draft-ietf-clue-framework-15.txt > > The objective of this pre-WGLC review is for folks to take a fresh look at > the document and re-review the entire document. Right now, there are just a > couple outstanding issues: > - #35 (consistency with the data model document) > - audio issue (that still needs to be detailed by John Leslie) > - issues reflected by editor's notes in the document for which we will > open new tickets > > This review is intended to ensure that there are no other outstanding > issues so that once we close the above open issues the document is ready > for WGLC. > > Note, reviews that provide a general summary and then separate the major > and minor issues from the editorial nits, something like the following, > would be quite helpful. > > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > Major issues: > > Minor Issues: > > Editorial nits: > > Please review and send any comments to the mailing list no later than > Friday, June 20th, 2014. > > Thanks, > Mary. > > --047d7b86d578c84fa704fc30f2b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Note that this pre-WGLC ends to= morrow. So far, we've only had one set of review comments posted to the= mailing list. =C2=A0

Mary.=C2=A0


On Fri, Jun 6, 2014 at 10:35 AM, Mary Ba= rnes <mary.ietf.barnes@gmail.com> wrote:
Hi all,

As discussed at the = interim meeting, this is a two week pre-WGLC review for the framework docum= ent:

The objective of this pre-WGLC review is for folk= s to take a fresh look at the document and re-review the entire document. R= ight now, there are just a couple outstanding issues:
- #35 (= consistency with the data model document)
- audio issue (that still needs to be detailed by John Leslie)
- issues reflected by editor's notes in the document for which we wi= ll open new tickets

This review is intended to ens= ure that there are no other outstanding issues so that once we close the ab= ove open issues the document is ready for WGLC.=C2=A0

Note, reviews that provide a general summary and then s= eparate the major and minor issues from the editorial nits, something like = the following, would be quite helpful.
=C2=A0
Summary: = (e.g., Needs Work, Almost Ready, Ready, etc)

Major issues:

Minor Issues:

Editorial nits:

Please= review and send any comments to the mailing list no later than Friday, Jun= e 20th, 2014.=C2=A0

Thanks,
Mary.=C2=A0


--047d7b86d578c84fa704fc30f2b1-- From nobody Thu Jun 19 07:46:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB561A03C2 for ; Thu, 19 Jun 2014 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzV7V4Fz4H4f for ; Thu, 19 Jun 2014 07:46:23 -0700 (PDT) Received: from BLU004-OMC1S29.hotmail.com (blu004-omc1s29.hotmail.com [65.55.116.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F021A03C3 for ; Thu, 19 Jun 2014 07:46:22 -0700 (PDT) Received: from BLU0-SMTP17 ([65.55.116.7]) by BLU004-OMC1S29.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Thu, 19 Jun 2014 07:46:22 -0700 X-TMN: [4c/kierg2tWPLgq8NtwmLXcqF+YTBPt+] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.62.229]) by BLU0-SMTP17.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jun 2014 07:46:21 -0700 From: Paul Coverdale To: References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> Date: Thu, 19 Jun 2014 10:46:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+JghdqRcUjEW03Q+OS5h250OB5jwADqeQQ Content-Language: en-us X-OriginalArrivalTime: 19 Jun 2014 14:46:21.0443 (UTC) FILETIME=[3C5EB530:01CF8BCD] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zkmiCJB3ZgqpMZG5_rSe1DrgV-o Subject: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:46:24 -0000 Colleagues, Following up on the action from the Design Team meeting of June 17, I propose the following text to be added at the end of section 7.1.1.3 in the Framework document. ................ Note that area of capture is not a valid concept for audio. To capture spatial information related to audio, the point of capture and point on line of capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may be used, along with another element defining the nominal sensitivity pattern of the microphone (bearing in mind that the actual microphone sensitivity pattern, in situ, may be somewhat different due to local obstacles). Nominal microphone sensitivity patterns to choose from include: Omni; Bi-directional; Cardioid; Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone pair, the point of capture is defined as the mid-point between the point of capture of the individual microphones. .................. Regards, ...Paul From nobody Thu Jun 19 08:27:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312031A026E; Thu, 19 Jun 2014 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuXVS_QyL45V; Thu, 19 Jun 2014 08:27:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F901A027E; Thu, 19 Jun 2014 08:27:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140619152740.4270.90549.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 08:27:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cXOMc3GWluM_fBc8X2_79VMotuI Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:27:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-05.txt Pages : 54 Date : 2014-06-19 Abstract: This document formally describes the data model adopted in CLUE. It provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 19 09:33:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645171A02B8 for ; Thu, 19 Jun 2014 09:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhY2RlpgOHgR for ; Thu, 19 Jun 2014 09:33:47 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FFC1A0291 for ; Thu, 19 Jun 2014 09:33:45 -0700 (PDT) X-ASG-Debug-ID: 1403195621-05ce37177b115270001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id WQVrHkmK1sZogUsg (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 18:33:41 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s5JGXers007383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2014 18:33:41 +0200 Message-ID: <53A310E4.7070808@unina.it> Date: Thu, 19 Jun 2014 18:33:40 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org, Roni Even References: <027401cf8aee$82f75310$88e5f930$@gmail.com> X-ASG-Orig-Subj: Re: [clue] Comment on option response indraft-presta-clue-protocol-04 In-Reply-To: <027401cf8aee$82f75310$88e5f930$@gmail.com> Content-Type: multipart/alternative; boundary="------------080608060308050301000208" X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1403195621 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/L4sBFSGB6SmyF0uM5lcTPxtBig8 Subject: Re: [clue] Comment on option response indraft-presta-clue-protocol-04 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:33:49 -0000 This is a multi-part message in MIME format. --------------080608060308050301000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Roni, the string type for the responseCode is a typo, it should be a short type element. We have distinguished between the numeric response code and the textual (human readable) response string. and appear optional in the response because in case of error responses the CR might not want to add further information besides the response code and the reason string. Roberta Il 18/06/2014 14:11, Roni Even ha scritto: > > Hi, > > I was looking at the OPTION response > > > > > > > > > > What is the responseCode and why a string. (in other messgaes it is > "short") need to define values > > Media Provider and Consumer are mandatory and not optional > > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille --------------080608060308050301000208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Roni,


the string type for the responseCode is a typo, it should be a short type element.
We have distinguished between the numeric response code and the textual (human readable) response string.
<mediaProvider> and <mediaConsumer> appear optional in the response because in case of error responses the CR might not want to add further information besides the response code and the reason string.

Roberta


Il 18/06/2014 14:11, Roni Even ha scritto:

Hi,

I was looking at the OPTION response

 

<xs:element name="responseCode" type="xs:string"/>

<xs:element name="reasonString" type="xs:string"/>

<xs:element name="mediaProvider" type="xs:boolean" minOccurs="0"/>

<xs:element name="mediaConsumer" type="xs:boolean" minOccurs="0"/>

 

 

What is the responseCode and why a string. (in other messgaes it is “short”) need to define values

 

Media Provider and Consumer are mandatory and not optional

 

Roni



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




----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­   --------------080608060308050301000208-- From nobody Thu Jun 19 11:18:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943281A0291; Thu, 19 Jun 2014 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJt9osCfuoPy; Thu, 19 Jun 2014 11:18:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2721A00B1; Thu, 19 Jun 2014 11:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140619181813.12714.60680.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 11:18:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YfVNL5stCdC9W4vyOdxyHMODB7M Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:18:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-00.txt Pages : 36 Date : 2014-06-19 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [I-D.ietf-clue-telepresence-requirements]. The companion document [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-protocol-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 19 14:55:43 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101EB1A03E2 for ; Thu, 19 Jun 2014 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bgZNsew67Y9 for ; Thu, 19 Jun 2014 12:53:49 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC8B1A0302 for ; Thu, 19 Jun 2014 12:53:48 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2792676wgg.20 for ; Thu, 19 Jun 2014 12:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=Y167c3cqOrpp6Q2CJExhS7NObdAaagkWU54U4KZg59g=; b=valGNRJvQW8sp7SgrLY/Z95oIZtPfffub0K/66c+cI+0VwMXl61PSFGLQMHpADWO/E HKAItQEKfs8rJVTTWivckqKweSdIwlwLe+zYBggu/OUjSImBerIHfOiBXE+rCEOz7X7X UDkXTxNdH9NTy5N8wgHishcdbiKPi9rw12e1gw4aXeVlMAUxy3XCC03O8q2TwI2NJIGL PsmENwbN74MYRbasfoYV5ccNZse6Ff5lHzKqTS+QHrHDTyV8BLMj7NX6ZqhT/3mVWJCR nnFTIIURj3jeOdzKiLFBgkS7lSocgKEpA99vQi3XR1NqIWoFZCGUIIrqBCzo2Y4sMY7X /Q+w== X-Received: by 10.180.198.44 with SMTP id iz12mr9061534wic.49.1403207627212; Thu, 19 Jun 2014 12:53:47 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id rw4sm10716349wjb.44.2014.06.19.12.53.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jun 2014 12:53:46 -0700 (PDT) From: "Roni Even" To: "'Roberta Presta'" , References: <027401cf8aee$82f75310$88e5f930$@gmail.com> <53A310E4.7070808@unina.it> In-Reply-To: <53A310E4.7070808@unina.it> Date: Thu, 19 Jun 2014 22:53:39 +0300 Message-ID: <031401cf8bf8$2d308ae0$8791a0a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0315_01CF8C11.527EAD40" X-Mailer: Microsoft Outlook 14.0 thread-index: AQJMq/ZhF89vmBWL+WcrpAi9E81sfgEfXr0amnWc60A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LmuwDoSzLeUSCMyi8dW4mzJhnBk X-Mailman-Approved-At: Thu, 19 Jun 2014 14:55:40 -0700 Subject: Re: [clue] Comment on option response indraft-presta-clue-protocol-04 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 19:53:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0315_01CF8C11.527EAD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Roberta, We do not have the response codes yet but the text for the Option response should say that if the response code is OK the mediaProvider and mediaConsumer fields are not optional Roni From: Roberta Presta [mailto:roberta.presta@unina.it] Sent: 19 June, 2014 7:34 PM To: clue@ietf.org; Roni Even Subject: Re: [clue] Comment on option response indraft-presta-clue-protocol-04 Hi Roni, the string type for the responseCode is a typo, it should be a short type element. We have distinguished between the numeric response code and the textual (human readable) response string. and appear optional in the response because in case of error responses the CR might not want to add further information besides the response code and the reason string. Roberta Il 18/06/2014 14:11, Roni Even ha scritto: Hi, I was looking at the OPTION response What is the responseCode and why a string. (in other messgaes it is "short") need to define values Media Provider and Consumer are mandatory and not optional Roni _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITA' DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille -- ------=_NextPart_000_0315_01CF8C11.527EAD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Roberta,

We do not have the response codes yet but the = text for the Option response should say that if the response code is OK = the mediaProvider and mediaConsumer fields are not = optional

Roni

 

From: Roberta Presta [mailto:roberta.presta@unina.it]
Sent: = 19 June, 2014 7:34 PM
To: clue@ietf.org; Roni = Even
Subject: Re: [clue] Comment on option response = indraft-presta-clue-protocol-04

 

Hi = Roni,


the string type for the responseCode is a typo, it = should be a short type element.
We have distinguished between the = numeric response code and the textual (human readable) response = string.
<mediaProvider> and <mediaConsumer> appear = optional in the response because in case of error responses the CR might = not want to add further information besides the response code and the = reason string.

Roberta


Il 18/06/2014 14:11, Roni Even = ha scritto:

Hi,

I was looking = at the OPTION response

 

<xs:element name=3D"responseCode" = type=3D"xs:string"/>

<xs:element name=3D"reasonString" = type=3D"xs:string"/>

<xs:element name=3D"mediaProvider" = type=3D"xs:boolean" = minOccurs=3D"0"/>

<xs:element name=3D"mediaConsumer" = type=3D"xs:boolean" = minOccurs=3D"0"/>

 

 

What is the = responseCode and why a string. (in other messgaes it is = “short”) need to define values

 

Media = Provider and Consumer are mandatory and not optional

 

Roni




__________________=
_____________________________
clue mailing =
list
clue@ietf.org
https://www.ietf.org/=
mailman/listinfo/clue




----
5x100= 0 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice = Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­  

<= /div>
------=_NextPart_000_0315_01CF8C11.527EAD40-- From nobody Fri Jun 20 08:41:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11A61B2818 for ; Fri, 20 Jun 2014 08:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHUBcOrSUmTh for ; Fri, 20 Jun 2014 08:41:30 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925201B2804 for ; Fri, 20 Jun 2014 08:41:29 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so1024583wiv.8 for ; Fri, 20 Jun 2014 08:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NRsS3xIYdeVF+S+V2tHZgXDEEI4YdNcONZhKlA3KrA8=; b=cVpHFL28E91U1OaZvSHkmuElQVYg5Dm3SDbFxkbx/s4FD14EYo9mi+ovkfSaevB8DA 4N02FAbHHgXatzyieC6jfE2ytcVeVWBlQboifjRtryjxZsqPNzjr+Hlw0WXuKZJCDiEA FQvzGj2nLEMkI4pH1waNQxDJ9PR9qyPPb1wvrWBEux64oLPPAVoBwlNFe2s1uAW3QnDf rnpvunhLGhi2MToLLfiol/GRfZEBrNxEkU4Yg8qIFPSbhBlic1lglWRb2hT8oSlg1FRX 1Sq1yHUNnR5+9TIPxGIc/ICNRM/NZmBYEoCAUIkbiLQ+s/5Nye2Cj0ka4VKUtWrbneLm Q1KA== MIME-Version: 1.0 X-Received: by 10.194.60.198 with SMTP id j6mr5542971wjr.86.1403278886440; Fri, 20 Jun 2014 08:41:26 -0700 (PDT) Received: by 10.217.116.201 with HTTP; Fri, 20 Jun 2014 08:41:26 -0700 (PDT) Date: Fri, 20 Jun 2014 10:41:26 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b86d5788c13f904fc46530e Archived-At: http://mailarchive.ietf.org/arch/msg/clue/g6GYmsRr4UEkXkHtqi8nRnE8EQE Subject: [clue] Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:41:33 -0000 --047d7b86d5788c13f904fc46530e Content-Type: text/plain; charset=UTF-8 Per the schedule on the wiki, we are starting a pre-WGLC on the data model document: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ The objective of this pre-WGLC review is for folks to take a fresh look at the document and re-review the entire document. If you missed the design team meeting on June 10th, you might also find it helpful to look at the minutes/presentation for some background: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140610.txt There are currently two open issues against this document in the tracker: #35: Consistency between framework and data model #48: Linking participant Information with Participant Type This review is intended to ensure that there are no other outstanding issues so that once we close the above open issues the document is ready for WGLC. Note, reviews that provide a general summary and then separate the major and minor issues from the editorial nits, something like the following, would be quite helpful. Summary: (e.g., Needs Work, Almost Ready, Ready, etc) Major issues: Minor Issues: Editorial nits: Please review and send any comments to the mailing list no later than Friday, July 4th, 2014. Thanks, Mary. --047d7b86d5788c13f904fc46530e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per the schedule on the wiki, w= e are starting a pre-WGLC on the data model document:
https://da= tatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/

The objective of t= his=C2=A0pre-WGLC=C2=A0review is for folks to take a fresh look at the docume= nt and re-review the entire document. If you missed the design team meeting= on June 10th, you might also find it helpful to look at the minutes/presen= tation for some background: =C2=A0
http://= trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140610= .txt

There are currently two open issues against this document in the tracker:= =C2=A0
#35: Consistency between framework and data model
#48: =C2=A0Linki= ng participant Information with Participant Type

This review is in= tended to ensure that there are no other outstanding issues so that once we= close the above open issues the document is ready for=C2=A0WGLC.=C2=A0

Note, reviews that provide a general summary an= d then separate the major and minor issues from the editorial nits, somethi= ng like the following, would be quite helpful.
=C2=A0
Summary: (e.g., Needs Work, Almost Ready, Rea= dy, etc)

Major issues:

Minor Issues:

Editorial nits:

Please review and sen= d any comments to the mailing list no later than Friday, July 4th, 2014.=C2= =A0

Thanks,
Mary.=C2=A0



--047d7b86d5788c13f904fc46530e-- From nobody Fri Jun 20 09:23:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4131B2863 for ; Fri, 20 Jun 2014 09:23:49 -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 VaXsK07jrTDa for ; Fri, 20 Jun 2014 09:23:49 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4D1B285B for ; Fri, 20 Jun 2014 09:23:48 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id GezX1o00427AodY5EgPoi6; Fri, 20 Jun 2014 16:23:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id GgPn1o01A3ZTu2S3fgPoXT; Fri, 20 Jun 2014 16:23:48 +0000 Message-ID: <53A46013.1060108@alum.mit.edu> Date: Fri, 20 Jun 2014 12:23:47 -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: CLUE 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=1403281428; bh=L+K8tyzNu9xn4CIK20Sruhn7hfHcjiWbEcOtPhIyW1k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qcA2CrKxEcpnpGlRTo6h2OwjGcbvH2oli9g6sfIFu0nZcOK5Z2Ppmcthv6HjR++/q NnxJu0PuOGEimlfon6qCt3cC3YxVg+0SosGLh/ov3d+ILBl6607+9FcnkMOC62Xzvn x8T9GMNSmj4OtA2Xb2SBNDDTDte5zsd1D5LsDjD0whiM+BTxS4a4rdzRynQD85SLZH oZzwfDCMpp/uzd6/TIHGpyyLBmOBfMdg5y6NrHDqwJVWlhrz/jmLBXkZeCaC5Lr5AX tEPdJH9Uteml7EgHmKEdBINuF7jrRqrpRqSMK3ellucn9rjUqpMu+pnFZChgIxp86E bT7b0EuC5LyHg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ExuLEiwfDfIEiLhhxNLhVINDwFw Subject: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 16:23:49 -0000 During a past design team call I proposed a homework task that I thought would be very helpful. The idea was well received, but nothing has happened. So I'll spell it out in more detail: The idea is to do a "test run" of the key aspects of clue, especially from an interoperability perspective. Specifically, I propose that, as a first step, everybody who can represent a possible implementation of CLUE should write down a proposed advertisement for each of their likely device configurations, and share that with the group. (E.g., if you have a one-screen system and a three-screen system, then provide an advertisement for each.) The next step would be for each person to look at all the advertisements other than their own, and decide if they can make sense of each and make a good choice of what to configure, and how they would render that on their device(s). Yet another step will be to extend the above to MCUs. We could pick combinations of endpoints and ask people with MCUs to decide what they would configure and then what they would advertise as a result. And then people to review those advertisements as well. (Ideally there will be no surprises here. But what I *expect* to happen here is that people will be surprised to find things they don't understand and/or can't deal with in any useful way. Discussions to clarify these would follow, and perhaps lead to some clarifications and maybe fixes.) This exercise is a bit like doing call flows, but the level of detail is different. Initially I think we only need the advertisements, and the corresponding SDP that contains the encodings. The advertisements could be encoded according to the message syntax in the protocol document, but for simplicity I think people can take liberties and use informal shorthand, as long as they include all the pieces. This is extra work for everybody, so I'd like to make it as easy as possible. One possibility is for people to submit contributions via email and then collate them into an individual draft. (I am willing to do the collation.) Or we could do this on the CLUE Wiki. (The Wiki might be easier.) Your thoughts on this are welcome. Who would be willing to participate in such an exercise? Thanks, Paul From nobody Fri Jun 20 11:17:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243241B2890 for ; Fri, 20 Jun 2014 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zz9wZI2qfa6 for ; Fri, 20 Jun 2014 11:17:48 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CC51B28A4 for ; Fri, 20 Jun 2014 11:17:44 -0700 (PDT) Received: from [216.82.254.20:4023] by server-15.bemta-7.messagelabs.com id DF/BE-08061-8CA74A35; Fri, 20 Jun 2014 18:17:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-47.messagelabs.com!1403288261!12273095!5 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28060 invoked from network); 20 Jun 2014 18:17:43 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-8.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 20 Jun 2014 18:17:43 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 20 Jun 2014 11:17:09 -0700 From: "Duckworth, Mark" To: Bo Burman , Christian Groves , "clue@ietf.org" Date: Fri, 20 Jun 2014 11:17:06 -0700 Thread-Topic: [clue] more taxonomy Thread-Index: Ac9u8GFqVUnsOP5fTpiqTclwzPXLpgayvGAAABlQ6PAAo/Zb0A== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> <539F9AD2.4040508@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t1WAVq-hgMH9UaH-PpHTJIM-gcw Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:17:51 -0000 Hi, There are a few suggestions below for the taxonomy document to clarify refe= rences to CLUE terms, which Bo has agreed with, or had questions which I tr= ied to answer below. So I think it is not necessary to add anything in the CLUE framework that r= efers back to the taxonomy document, does that sound right? Or do we want = to add all this information about the relationship between CLUE and taxonom= y into the framework doc also? Some more inline below. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Bo Burman > Sent: Tuesday, June 17, 2014 8:09 AM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] more taxonomy >=20 > Hi, >=20 > I am currently updating the RTP Taxonomy, so this review of CLUE terms is > really welcome. I plan to submit a new version of the Taxonomy draft with= in > the next few days and would like to include the result of this discussion= . >=20 > Please find a few comments and questions inline below. >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > Groves > > Sent: den 17 juni 2014 03:33 > > To: clue@ietf.org > > Subject: Re: [clue] more taxonomy > > > > Hello Mark, > > > > Please see my comments below. > > > > Regards, Christian > > > > On 14/05/2014 10:03 AM, Duckworth, Mark wrote: > > > > > > I'm looking at more terms and concepts that are used both in CLUE > > > and in draft-ietf-avtext-rtp-grouping-taxonomy-01. > > > > > > Should we add some of this to the framework definitions section, to > > > indicate how the CLUE terms relate to taxonomy terms? > > > > > > CLUE Media Capture: I'm not sure about this. I was going to say it > > > is the same as taxonomy Media Capture, with either physical stimulus > > > or synthetic stimulus. But the taxonomy draft says a CLUE Media > > > Capture is the same as a taxonomy Media Source. I don't see how it > > > makes any difference to CLUE either way. What do you think? > > > > > [CNG] I think CLUE captures can be either a RTP taxonomy media capture > > or media source. The distinguishing factor appears to be that the > > media capture is raw stream and a media source is a processed stream. > CLUE media captures could be either. This could be updated in the taxonom= y > draft. > [BoB] OK >=20 > > > > > > CLUE Individual Encoding: I think this is parameters of the taxonomy > > > Media Encoder transformation. Taxonomy draft says "CLUE's 'Capture > > > Encoding' provides specific encoding configuration for this purpose > > > [Media Encoder]". I think it should be "CLUE's 'Individual > > > Encoding'", not "Capture Encoding". (suggest change this in taxonomy > > > draft, also in Packet Stream section) > > > > > [CNG] I agree individual coding would be more appropriate. > [BoB] OK >=20 > > > > > CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest > add > > > this to taxonomy draft) > > > > > [CNG] I think its similar but not the same. A CLUE capture encoding > > does result in an encoded stream but due to the link with a CLUE media > capture ID there is also semantic information that is associated with the > encoded stream. > [BoB] OK. I get a feeling that the CLUE capture encoding term is (at leas= t in > the CLUE framework) mostly used to describe an Encoded Stream, but is > sometimes also used to denote the Media Encoder transformation and the > result is then (correctly) described as a Stream. Am I correct? If so, do= you > want to change that "duality" of capture encoding, or do you rather prefe= r > that I just reflect this fact in the Taxonomy? [Duckworth, Mark] I still think a Capture Encoding is the same as an Encode= d Stream. Yes, there is a link to the semantic information, but still it i= s an Encoded Stream. I don't think Capture Encoding refers to the media en= coder transformation. It is the output of the transformation, which is the= Encoded Stream. > > > CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already > > > equates CLUE Stream with Packet Stream). > > > > > > > > CLUE Endpoint: includes a taxonomy End Point and a Participant. > > > > > [CNG] Yes > [BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple > entities running separate RTP stacks), or is that an unnecessary > generalization? [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. CLUE d= efinition says "exactly one [RFC4353] Participant (which, in turn, includes= exactly one SIP User Agent)". I think this is all consistent. > > > CLUE MCU: includes multiple taxonomy End Points and a Participant > > > for each conference. > > > > > [CNG] Yes > [BoB] You mean the MCU itself is a Participant in each conference and as > such also includes multiple End Points per conference, right? [Duckworth, Mark] I think so. A CLUE MCU shouldn't be any different than a= ny other MCU. The taxonomy document doesn't mention MCU or multipoint. I = suggest neither CLUE framework nor taxonomy doc needs to add anything about= relation between MCU and End Point and Participant. > > > I can post suggestions to avtext to change the taxonomy draft > > > regarding these CLUE terms, but I'd like to hear feedback from this > > > group first. > > > > > > Regards, > > > Mark > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 20 11:39:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF91B28B9 for ; Fri, 20 Jun 2014 11:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8QkfEnb-Led for ; Fri, 20 Jun 2014 11:39:18 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292EE1B28B0 for ; Fri, 20 Jun 2014 11:39:18 -0700 (PDT) Received: from [216.82.249.212:46750] by server-14.bemta-12.messagelabs.com id E6/34-04933-5DF74A35; Fri, 20 Jun 2014 18:39:17 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-219.messagelabs.com!1403289555!8030628!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8091 invoked from network); 20 Jun 2014 18:39:16 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 20 Jun 2014 18:39:16 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 20 Jun 2014 11:37:38 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 20 Jun 2014 11:37:38 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 20 Jun 2014 11:37:35 -0700 Thread-Topic: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt Thread-Index: Ac+J+mc0fnPKlYvQQXqIpgNQTb3o1ACvBDfg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3FF@CRPMBOXPRD08.polycom.com> References: <539FE86F.7000902@nteczone.com> In-Reply-To: <539FE86F.7000902@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/30BfxgtkYjg1w--SnYMONmIZSWM Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:39:21 -0000 Thanks Christian. I agree with pretty much all this. Later (next week I hope) I can give spe= cific responses and suggestions for framework updates to address all these = points. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, June 17, 2014 3:04 AM > To: clue@ietf.org > Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >=20 > Hello, >=20 > In summary I think its fairly good although the audio issue is still a wo= rry. >=20 > My comments: >=20 > Issues > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Cl.3 Advertisement: " the formatting of the media streams it can send" > can probably be deleted as we removed the encoding information. >=20 > Cl.3 Capture Encoding: How critical is the use of RTP for a capture encod= ing? I > would think anything defined to carry media would be appropriate, obvious= ly > RTP is the most used example. So perhaps we can change that to: ".... to = a > Media Consumer, e.g. via RTP." >=20 > Cl.3 Capture Scene: Is it really a region containing one or more capture > devices? The scene may not actually contain the capture device. I would > think it would be more appropriate to say something like "a structure > representing the region captured by one or more media captures..." >=20 > Cl.3 General: Do we need a term to describe when multiple Capture Scenes > are used to give an overall "picture" of the endpoint, i.e. GCSE? >=20 > Cl.3 Media Consumer/Media Provider - Should this say MCU? >=20 > Cl.3 Model: Is this definition needed or valid in the current CLUE framew= ork? > The use of "model" in the draft doesn't appear to reflect this definition= . >=20 > Cl.3 Render: A rendered video may be as a result of multiple media. I > propose "... a representation from media..." >=20 > Cl.3 Single Media Capture: "i.e. audio capture, video capture" don't real= ly > represent a single capture they represent a "single capture type". I thin= k it > would be more correct to say "i.e. an audio capture from a single > microphone, a video capture from a single camera." >=20 > Cl.5 para.2: Rather than say "formatting of the media streams" it should = say > something like "media stream encodings"? >=20 > Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE channel= is only > established later in the call. Either we could have "SHOULD" or say somet= hing > like "MUST occur when a CLUE channel is established in the call". >=20 > Cl.5 para.5: Is there a double definition of "media capture"? In this par= agraph > it says that a media capture describes the content. Whereas the definitio= n in > cl.3 says " Media Capture: a source of Media, such as from one or more > Capture Devices or constructed from other Media streams." There's nothing > about description of content here. >=20 > Cl.5 para.6: " A Consumer chooses which Media Captures it wants to receiv= e > from each Capture Scene." A Consumer doesn't have to choose any MCs > from a scene. I'd suggested replace "each" with "the", i.e. > "...receive from the Capture Scenes." >=20 > Cl.5 para.7 : "...media attributes of the Encodings" (and following text)= . This > can be deleted as these are not contained in the Advertisement any more. >=20 > Cl.5 fig.1 : Does this need to be updated to remove maxBandWidth or at le= ast > move it to the encoding group level? Also does the global CSE need to be > added as a box like the STS? >=20 > Cl.5 pg.13 para.1: "Voice Activated Stream Switching" via updated CLUE > signalling is that something we've decided for CLUE? >=20 > Cl.5 pg.13 para.2: Do we need the sentence " Obviously, this is not a > particularly sensible design choice in almost all conceivable > cases."? >=20 > Cl.7.1.1.8 : There's the note regarding the different types of presentati= on. Is > there any interest for values beyond "image" and "slides"? >=20 > Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial = relationship > between scenes. However this paragraph is a little "fuzzy" > implying there may be relationship between scenes. Whilst physically ther= e > may a relationship a consumer has no way of knowing this. The default > behaviour will not be to associate scenes. >=20 > Cl.9.1 para.3 : "The parameter of an Individual Encoding represent the > maximum values", is this the case now? As the individual encoding > parameter are now defined by SDP they could mean anything, not just > maximum values. I think this paragraph needs to be updated to reflect thi= s. >=20 > Cl.9.2: There is no explicit mention of whether individual encodings of > multiple media types i.e. audio and video can belong to a single group. >=20 > Cl.10 para.2: I don't see the "special" handling outlined in this paragra= ph. A > consumer would have a separate CLUE channel with each provider and treat > the associations differently? >=20 > Cl.10 Pg.39 para.2: ", and includes the encoding parameter values" > should be deleted. A configure doesn't respond with these values. Also in > the paragraph below the text regarding parameters should be deleted also. >=20 > Cl.11 Para 1: Do we need the text about new industry and future direction= s? > Can't we just mention how the framework is extensible? >=20 > Cl.11 bullet 3: New codecs should be added to SDP not CLUE. We could > remove this bullet. >=20 > Cl.13 : How much do you have to input to get a mention? (hint) >=20 > Editorial > =3D=3D=3D=3D=3D=3D=3D=3D=3D > General: I think the draft would read better if constructions such as "is > sending" and "is receiving" are changed to "sends" and "receives", i.e. c= l.4 > para.2 "represents the entity that sends the media". "is not supporting" = =3D> > "does not support" >=20 > General: Defined terms "Provider", "Advertisement" etc. should have there > first character capitalized. >=20 > Cl.1 Para.1 : References to CLUE drafts can be updated to RFCs. >=20 > Cl.3 AudioCapture: ". Denoted as ACn in the examples in this document." >=20 > Cl.3 Font: "In going towards back..." >=20 > Cl.4 (1): The first part of the sentence talks about the past, so I sugge= st > changing "... for example, there was no mechanism..." >=20 > Cl.4 (2): Consistency "...are multiple capturing and rendering..." or "..= .are > multiple capture and render..." >=20 > Cl.7.1.1 Para.1: "... for the benefit of the Consumer the Advertisem= ent > message" or "A Provider can use the Media Capture Attributes in an > Advertisement to describe the Capture for the benefit of the Consumer". >=20 > Cl.7.1.1.7 Reword " The Description attribute is a human-readable descrip= tion > (which could be in multiple languages) of the Capture." > Otherwise it reads that the capture could be in multiple languages not th= e > description. (Similar comment to cl.7.3.2) >=20 > Cl.8 Pg.33 Para.2 : "...are shown in Table 1" =3D> "... are shown in Tabl= e 5." >=20 > Cl.9 "...please refer to section 4" =3D> "...please refer to section 5"? >=20 > Cl.10 para.4: "As a general outline, Consumer..." >=20 > Regards, Christian >=20 >=20 > On 7/06/2014 1:35 AM, Mary Barnes wrote: > > Hi all, > > > > As discussed at the interim meeting, this is a two week pre-WGLC > > review for the framework document: > > http://www.ietf.org/id/draft-ietf-clue-framework-15.txt > > > > The objective of this pre-WGLC review is for folks to take a fresh > > look at the document and re-review the entire document. Right now, > > there are just a couple outstanding issues: > > - #35 (consistency with the data model document) > > - audio issue (that still needs to be detailed by John Leslie) > > - issues reflected by editor's notes in the document for which we will > > open new tickets > > > > This review is intended to ensure that there are no other outstanding > > issues so that once we close the above open issues the document is > > ready for WGLC. > > > > Note, reviews that provide a general summary and then separate the > > major and minor issues from the editorial nits, something like the > > following, would be quite helpful. > > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > > > Major issues: > > > > Minor Issues: > > > > Editorial nits: > > > > Please review and send any comments to the mailing list no later than > > Friday, June 20th, 2014. > > > > Thanks, > > Mary. > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 20 11:48:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02E1B28C0 for ; Fri, 20 Jun 2014 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZnEwwZAHNiQ for ; Fri, 20 Jun 2014 11:48:38 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.108]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E761B28B5 for ; Fri, 20 Jun 2014 11:48:38 -0700 (PDT) Received: from [216.82.254.20:8278] by server-12.bemta-7.messagelabs.com id 3D/07-30382-50284A35; Fri, 20 Jun 2014 18:48:37 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1403290113!12433977!9 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20867 invoked from network); 20 Jun 2014 18:48:37 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 20 Jun 2014 18:48:37 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 20 Jun 2014 11:48:20 -0700 From: "Duckworth, Mark" To: Paul Coverdale , "clue@ietf.org" Date: Fri, 20 Jun 2014 11:48:18 -0700 Thread-Topic: [clue] How to do deal with CLUE spatial audio aspects Thread-Index: Ac+JghdqRcUjEW03Q+OS5h250OB5jwADqeQQAMmLAqA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/s-AQGYhyeFaWsgtzcUgEslsC1bQ Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:48:40 -0000 Thanks Paul, I agree with your suggestion, but I would like to add a new section 7.1.1.x= for the new sensitivity pattern attribute. Then split your proposed text = between 7.1.1.3 Area of Capture and 7.1.1.1 Point of Capture and the new se= ction. I can also update the section 12 examples that mention spatial information = for audio. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale > Sent: Thursday, June 19, 2014 10:46 AM > To: clue@ietf.org > Subject: [clue] How to do deal with CLUE spatial audio aspects >=20 > Colleagues, >=20 > Following up on the action from the Design Team meeting of June 17, I > propose the following text to be added at the end of section 7.1.1.3 in t= he > Framework document. >=20 > ................ > Note that area of capture is not a valid concept for audio. To capture sp= atial > information related to audio, the point of capture and point on line of > capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may be used, along = with > another element defining the nominal sensitivity pattern of the microphon= e > (bearing in mind that the actual microphone sensitivity pattern, in situ,= may > be somewhat different due to local obstacles). Nominal microphone > sensitivity patterns to choose from include: Omni; Bi-directional; Cardio= id; > Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone pair, th= e > point of capture is defined as the mid-point between the point of capture= of > the individual microphones. > .................. >=20 > Regards, >=20 > ...Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 20 17:47:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB11A02F7 for ; Fri, 20 Jun 2014 17:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9wBnPhgzSiY for ; Fri, 20 Jun 2014 17:47:06 -0700 (PDT) Received: from BLU004-OMC1S15.hotmail.com (blu004-omc1s15.hotmail.com [65.55.116.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C4D1A0280 for ; Fri, 20 Jun 2014 17:47:05 -0700 (PDT) Received: from BLU436-SMTP109 ([65.55.116.7]) by BLU004-OMC1S15.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 20 Jun 2014 17:47:05 -0700 X-TMN: [nU0q/Ur4s0jWzF8pw/3ZjzgpANIqnckM] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.62.229]) by smtphm.sympatico.ca over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384); Fri, 20 Jun 2014 17:47:04 -0700 From: Paul Coverdale To: "'Duckworth, Mark'" , References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> Date: Fri, 20 Jun 2014 20:47:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+JghdqRcUjEW03Q+OS5h250OB5jwADqeQQAMmLAqAADMIncA== Content-Language: en-us X-OriginalArrivalTime: 21 Jun 2014 00:47:04.0660 (UTC) FILETIME=[5236E940:01CF8CEA] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Xp_AV0rXuLcyXCrDgqaQxZSEEp8 Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 00:47:08 -0000 Hi Mark, Your proposed way forward is fine for me. Thanks, ...Paul >-----Original Message----- >From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >Sent: Friday, June 20, 2014 2:48 PM >To: Paul Coverdale; clue@ietf.org >Subject: RE: [clue] How to do deal with CLUE spatial audio aspects > >Thanks Paul, > >I agree with your suggestion, but I would like to add a new section >7.1.1.x for the new sensitivity pattern attribute. Then split your >proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of >Capture and the new section. > >I can also update the section 12 examples that mention spatial >information for audio. > >Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale >> Sent: Thursday, June 19, 2014 10:46 AM >> To: clue@ietf.org >> Subject: [clue] How to do deal with CLUE spatial audio aspects >> >> Colleagues, >> >> Following up on the action from the Design Team meeting of June 17, I >> propose the following text to be added at the end of section 7.1.1.3 >> in the Framework document. >> >> ................ >> Note that area of capture is not a valid concept for audio. To capture >> spatial information related to audio, the point of capture and point >> on line of capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may >> be used, along with another element defining the nominal sensitivity >> pattern of the microphone (bearing in mind that the actual microphone >> sensitivity pattern, in situ, may be somewhat different due to local >> obstacles). Nominal microphone sensitivity patterns to choose from >> include: Omni; Bi-directional; Cardioid; Super-cardioid; >> Hyper-cardioid; Shotgun. For a stereo microphone pair, the point of >> capture is defined as the mid-point between the point of capture of >the individual microphones. >> .................. >> >> Regards, >> >> ...Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Sun Jun 22 07:50:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69161B2973 for ; Sun, 22 Jun 2014 07:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.471 X-Spam-Level: * X-Spam-Status: No, score=1.471 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9NEKNOwoqJt for ; Sun, 22 Jun 2014 07:50:19 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09651B2976 for ; Sun, 22 Jun 2014 07:50:18 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so2887048wib.6 for ; Sun, 22 Jun 2014 07:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=RdOGKcQrhlX2YZ0HK7CkFObEjhpOzXHd/cZYcqW8Ko4=; b=EjDI8z/v6x7EwcOqIqhQuu1oBB1G1mr2p+V8DkM2NhSW7NAMM638qBqgb37ke6z/fy TQyLZ1kDgB3vK8oeI0ARlwUgySAzfPYHz07P8xiqE0M2vvA9xk+eX500IjSk07m07xi8 byed3NEHE//GUKcXeS4PfdLsenjao1dGKuN70+1bc3tiIjQqjyjIbFBLASLht0sKinQT 87i1FMEe+HPhksrP91+GGQ5NQ4XpSlhqBeLspg1lKdRBlezVhb8IKxRWcxmOPOPF02Ip NS0aLSerySFhHvhlxY3DEkrxB/pkDOEtK7pZtTIfiiO2g2gjD+m7t1Mg9iRpV/qF9v0V VqKQ== X-Received: by 10.180.13.230 with SMTP id k6mr18918178wic.1.1403448617525; Sun, 22 Jun 2014 07:50:17 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id 19sm29658834wjz.3.2014.06.22.07.50.14 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Jun 2014 07:50:16 -0700 (PDT) From: "Roni Even" To: Date: Sun, 22 Jun 2014 17:50:07 +0300 Message-ID: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038E_01CF8E42.6B096FC0" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac+NLLJHPt+1L6g6QselktpqHPFbgA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5O8NVVxarqVIdZHk6bpEfD96oo4 Subject: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 14:50:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_038E_01CF8E42.6B096FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Trying to write the call flows make me review the other documents (good excuse) This is the base CLUE message type Some comments 1. What is the purpose of the ClueId? Is this for displaying the station name? 2. The version (v) is defined as string, this is also the type for the version in the supported version. Being a string will make comparison in option and option response dependent on having the same string in both. For example the option can have "v1.0" while the response will be "ver 1.0", should be positive integer also in version list type. 3. Why do we need the fixed attribute "protocol" with the vale CLUE, this is already known from the ppid (51) of the sctp channel? I assume that if we will have another transport it will include the opening of a CLUE channel. Roni ------=_NextPart_000_038E_01CF8E42.6B096FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Trying to write = the call flows make me review the other documents (good = excuse)

 

This is the base CLUE message type

 

<xs:complexType name=3D"clueMessageType" = abstract=3D"true">

<xs:sequence>

<xs:element name=3D"clueId" = type=3D"xs:string"/>

<xs:element name=3D"sequenceNr" = type=3D"xs:unsignedInt"/>

</xs:sequence>

<xs:attribute name=3D"protocol" = type=3D"xs:string" fixed=3D"CLUE" = use=3D"required"/>

<xs:attribute name=3D"v" = type=3D"xs:string" = use=3D"required"/>

</xs:complexType>

 

Some = comments

 

1.       = What is the purpose of = the ClueId? Is this for displaying the station name?

2.       = The version (v) is = defined as string, this is also the type for the version in the = supported version. Being a string will make comparison in option and = option response dependent on having the same string in both. For example = the option can have “v1.0” while the response will be = “ver 1.0”, should be positive integer also in version list = type.

3.       = Why do we need the fixed = attribute “protocol” with the vale CLUE, this is already = known from the ppid (51) of the sctp channel? I assume that if we will = have another transport it will include the opening of a CLUE = channel.

Roni

 

------=_NextPart_000_038E_01CF8E42.6B096FC0-- From nobody Sun Jun 22 13:08:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A738B1A025D for ; Sun, 22 Jun 2014 13:08:54 -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 8ptIZBbjBmNz for ; Sun, 22 Jun 2014 13:08:54 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C64BF1A01BB for ; Sun, 22 Jun 2014 13:08:53 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id HY6J1o0041HzFnQ53Y8sVW; Sun, 22 Jun 2014 20:08:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id HY8s1o00W3ZTu2S3aY8snW; Sun, 22 Jun 2014 20:08:52 +0000 Message-ID: <53A737D4.9070808@alum.mit.edu> Date: Sun, 22 Jun 2014 16:08:52 -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: clue@ietf.org References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> In-Reply-To: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403467732; bh=38cpsY/4FD95I2Vy5XLXaLqNkaXXF3yoooDev+2Qx+c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eocfiTkfnb1kJyZ0nIyrXaHJZKywxJAS8+NdKJnLeN1MeVRSsZdQltvREC5NOH6f9 vPLDXj/yiqDymBeE8hf8QiLCDQmNOW0NVzLqPruHluZvOtRHiXaL/2kTTnjRaAHspL XSka7+cGRB4QbLd3Fn6pQp1wkaOIoxhvmeFHFCWqVfO7PHciJDygr2TaZwpYdcqaVw +i+5qEm8IaCQ2ekYOkCzvM3Kc7UKcYUOqGmTCnzrCltOqD/4TqoJxBdW82V1dTSXSg j+70f70RdID31mPC58NHndAN5kDBh6XBoitcA2H3WanCIRy+Is8bO0F1ZUOlWGC3C/ ab17HHsQsyOwA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/V-TRY6PTHHr5-SlHqe4T-8Qu4BE Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 20:08:54 -0000 On 6/22/14 10:50 AM, Roni Even wrote: > 3.Why do we need the fixed attribute “protocol” with the vale CLUE, this > is already known from the ppid (51) of the sctp channel? I assume that > if we will have another transport it will include the opening of a CLUE > channel. ppid 51 is not unique to clue - it is used for all data channel payloads. Without something in the xml, determining that this is clue will be contextual. Having it be explicit will help with analysis tools, deep packet inspection, etc. Thanks, Paul From nobody Sun Jun 22 14:06:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0075A1A02B5 for ; Sun, 22 Jun 2014 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gINiILZxl9qW for ; Sun, 22 Jun 2014 14:06:24 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0AE1A0295 for ; Sun, 22 Jun 2014 14:06:24 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so5825468wev.6 for ; Sun, 22 Jun 2014 14:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=RrrYFjSDDOxIPkFpjYo/mPhS+ZaumvlfiCuO6uzYCVk=; b=KN9HVWauVUseWLv0Kml0AE+JP85smMTg2g8V/W1mgTE0P7s1nQzKERgGRo8AeLk1Il FiCsNnG0hSsVU9UbAXc9eJ73/5ayva3eEbOF7K7cmqeJnxyvfuLcT+B7t1TrGXyAjGm8 NhAM/vjpkahXMqeK9xWZRpGivIsN2z1vDt9Vox9ox4pfPyPzHeRjEYQ4IBOA6KOxNs1M armFS4dVpQZjiRwgH2xuYXB/VoP5RJoYoZwCe774yatJYye8gWtrsrx88G0P1oshypmj 6IZDFzULtYIYmkrkmzC2xDUaqORa0VdHMkT18WJ7AcIMsBna0Wijf5LhINDyf7UBqc7v 710A== X-Received: by 10.180.211.106 with SMTP id nb10mr21016039wic.9.1403471183166; Sun, 22 Jun 2014 14:06:23 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id cj8sm31575747wjb.5.2014.06.22.14.06.20 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Jun 2014 14:06:22 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A737D4.9070808@alum.mit.edu> In-Reply-To: <53A737D4.9070808@alum.mit.edu> Date: Mon, 23 Jun 2014 00:06:15 +0300 Message-ID: <03a401cf8e5d$d038f490$70aaddb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJFKbhM3XYMAHeDWEWDfRd7RrdWlAG+prL2moRw+AA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/r91mvzauTlSDC_y01q4nVM_rsww Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 21:06:26 -0000 Hi Paul, This is not my understanding of the PPID parameter. There is a IANA registry for SCTP PPID http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p arameters-25 and looking at it PPID 51 is already assigned Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 22 June, 2014 11:09 PM > To: clue@ietf.org > Subject: Re: [clue] CLUE protocol message type comment > > On 6/22/14 10:50 AM, Roni Even wrote: > > > 3.Why do we need the fixed attribute "protocol" with the vale CLUE, > > this is already known from the ppid (51) of the sctp channel? I assume > > that if we will have another transport it will include the opening of > > a CLUE channel. > > ppid 51 is not unique to clue - it is used for all data channel payloads. > > Without something in the xml, determining that this is clue will be contextual. > Having it be explicit will help with analysis tools, deep packet inspection, etc. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sun Jun 22 14:24:10 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44111A02BA for ; Sun, 22 Jun 2014 14:24:07 -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 htW1L50U96xy for ; Sun, 22 Jun 2014 14:24:06 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB71A0263 for ; Sun, 22 Jun 2014 14:24:06 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id HYug1o0021c6gX85AZQ6QU; Sun, 22 Jun 2014 21:24:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id HZQ51o00h3ZTu2S3jZQ67b; Sun, 22 Jun 2014 21:24:06 +0000 Message-ID: <53A74975.6050306@alum.mit.edu> Date: Sun, 22 Jun 2014 17:24:05 -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: Roni Even , clue@ietf.org References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A737D4.9070808@alum.mit.edu> <03a401cf8e5d$d038f490$70aaddb0$@gmail.com> In-Reply-To: <03a401cf8e5d$d038f490$70aaddb0$@gmail.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=1403472246; bh=lwk97HCvf4Jy5jFUfLantsgPqxTK7/E+vqCAzJihs6U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uX4tj1aIHnuivDdq1lxbKV27Y4UdyrpcngnXsOS82YhUIWIlHb29ZQJYiEehJ8oJ0 GWbSH6nhTjcZ9PrP2tv7apy27qe2655C2OyT1IxfPYAry5agPRJaaz9mjiNilJoMY6 sh8cDDcoqe56MsuEL42wS4BYewspv1vymBiVcLbSvUEWkJBiOeADlvQSMK1fL/yX/Z JT6Q4H2gZNXyo3H7E2Cp5LXCkPliM/l9Ob2PV7VrbPUEr7WUKmv17xDFluKd793rqi +YIH1qxRMz0x8U7ElribqLk/0/vcutZzGHKmQ+3MxvIikXMY7TdeBZAg0NolRs0Vp4 RQ9lkG42YCUTg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/R8MX4-VpypguruY46i67zHKXkD4 Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 21:24:07 -0000 On 6/22/14 5:06 PM, Roni Even wrote: > Hi Paul, > This is not my understanding of the PPID parameter. > There is a IANA registry for SCTP PPID > http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p > arameters-25 and looking at it PPID 51 is already assigned > Roni Yes, I know. Values 50-54 were defined for use with data channels. Of those, 52 and 54 have already been effectively deprecated. 51 and 53 are used for data channel payloads. The distinction between them is an artifact of javascript. *All* payload data using data channels will be with either ppid 51 or 53. We can't claim 51 as being unique for clue. Thanks, Paul > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 22 June, 2014 11:09 PM >> To: clue@ietf.org >> Subject: Re: [clue] CLUE protocol message type comment >> >> On 6/22/14 10:50 AM, Roni Even wrote: >> >>> 3.Why do we need the fixed attribute "protocol" with the vale CLUE, >>> this is already known from the ppid (51) of the sctp channel? I assume >>> that if we will have another transport it will include the opening of >>> a CLUE channel. >> >> ppid 51 is not unique to clue - it is used for all data channel payloads. >> >> Without something in the xml, determining that this is clue will be > contextual. >> Having it be explicit will help with analysis tools, deep packet > inspection, etc. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Sun Jun 22 21:57:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB051B2992 for ; Sun, 22 Jun 2014 21:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 u_qeE2VoAiod for ; Sun, 22 Jun 2014 21:57:14 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F68F1B298F for ; Sun, 22 Jun 2014 21:57:14 -0700 (PDT) Received: from ppp118-209-152-146.lns20.mel6.internode.on.net ([118.209.152.146]:56510 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WywJI-0004zT-Cg; Mon, 23 Jun 2014 14:56:52 +1000 Message-ID: <53A7B3A5.8020309@nteczone.com> Date: Mon, 23 Jun 2014 14:57:09 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , Bo Burman , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> <539F9AD2.4040508@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/EAJQ9RetxaKHr1m-_ZZe7ooMURg Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 04:57:17 -0000 Hello Please find my comments below. On 21/06/2014 4:17 AM, Duckworth, Mark wrote: > Hi, > > There are a few suggestions below for the taxonomy document to clarify references to CLUE terms, which Bo has agreed with, or had questions which I tried to answer below. > > So I think it is not necessary to add anything in the CLUE framework that refers back to the taxonomy document, does that sound right? Or do we want to add all this information about the relationship between CLUE and taxonomy into the framework doc also? [CNG] I don't think its strictly necessary to add anything. If the taxonomy document became an RFC before the CLUE framework maybe we could add something, but I don't think there's a need to create a dependency. > ..snip.. >>>> CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest >> add >>>> this to taxonomy draft) >>>> >>> [CNG] I think its similar but not the same. A CLUE capture encoding >>> does result in an encoded stream but due to the link with a CLUE media >> capture ID there is also semantic information that is associated with the >> encoded stream. >> [BoB] OK. I get a feeling that the CLUE capture encoding term is (at least in >> the CLUE framework) mostly used to describe an Encoded Stream, but is >> sometimes also used to denote the Media Encoder transformation and the >> result is then (correctly) described as a Stream. Am I correct? If so, do you >> want to change that "duality" of capture encoding, or do you rather prefer >> that I just reflect this fact in the Taxonomy? > [Duckworth, Mark] I still think a Capture Encoding is the same as an Encoded Stream. Yes, there is a link to the semantic information, but still it is an Encoded Stream. I don't think Capture Encoding refers to the media encoder transformation. It is the output of the transformation, which is the Encoded Stream. [CNG] I agree that a CLUE capture encoding results in an encoded stream from a transport perspective. From a CLUE perspective its an encoded stream with a particular semantic. I think its important to capture the "CLUE" part of the definition of "CLUE capture encoding". > >>>> CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already >>>> equates CLUE Stream with Packet Stream). >>>> >>>> CLUE Endpoint: includes a taxonomy End Point and a Participant. >>>> >>> [CNG] Yes >> [BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple >> entities running separate RTP stacks), or is that an unnecessary >> generalization? > [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. CLUE definition says "exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)". I think this is all consistent. [CNG] I agree. > >>>> CLUE MCU: includes multiple taxonomy End Points and a Participant >>>> for each conference. >>>> >>> [CNG] Yes >> [BoB] You mean the MCU itself is a Participant in each conference and as >> such also includes multiple End Points per conference, right? > [Duckworth, Mark] I think so. A CLUE MCU shouldn't be any different than any other MCU. The taxonomy document doesn't mention MCU or multipoint. I suggest neither CLUE framework nor taxonomy doc needs to add anything about relation between MCU and End Point and Participant. [CNG] I agree. > >>>> I can post suggestions to avtext to change the taxonomy draft >>>> regarding these CLUE terms, but I'd like to hear feedback from this >>>> group first. >>>> >>>> Regards, >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Sun Jun 22 22:01:10 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAEF1B2991 for ; Sun, 22 Jun 2014 22:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 b6Ecp9lUNc_u for ; Sun, 22 Jun 2014 22:01:07 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E097C1B298F for ; Sun, 22 Jun 2014 22:01:06 -0700 (PDT) Received: from ppp118-209-152-146.lns20.mel6.internode.on.net ([118.209.152.146]:56513 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WywN4-0005Se-25 for clue@ietf.org; Mon, 23 Jun 2014 15:00:46 +1000 Message-ID: <53A7B48F.4030405@nteczone.com> Date: Mon, 23 Jun 2014 15:01:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-nViV2tzBWmqXZrWET8x0eZlXxE Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 05:01:09 -0000 Hello Paul, Mark, Paul: Thanks for providing the text. For the sensitivity pattern attribute is there some short description giving an example how it could be used by the Consumer? Mark: I agree with your suggestion. I think its better to capture the changes that way. Regards, Christian On 21/06/2014 4:48 AM, Duckworth, Mark wrote: > Thanks Paul, > > I agree with your suggestion, but I would like to add a new section 7.1.1.x for the new sensitivity pattern attribute. Then split your proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of Capture and the new section. > > I can also update the section 12 examples that mention spatial information for audio. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale >> Sent: Thursday, June 19, 2014 10:46 AM >> To: clue@ietf.org >> Subject: [clue] How to do deal with CLUE spatial audio aspects >> >> Colleagues, >> >> Following up on the action from the Design Team meeting of June 17, I >> propose the following text to be added at the end of section 7.1.1.3 in the >> Framework document. >> >> ................ >> Note that area of capture is not a valid concept for audio. To capture spatial >> information related to audio, the point of capture and point on line of >> capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may be used, along with >> another element defining the nominal sensitivity pattern of the microphone >> (bearing in mind that the actual microphone sensitivity pattern, in situ, may >> be somewhat different due to local obstacles). Nominal microphone >> sensitivity patterns to choose from include: Omni; Bi-directional; Cardioid; >> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone pair, the >> point of capture is defined as the mid-point between the point of capture of >> the individual microphones. >> .................. >> >> Regards, >> >> ...Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jun 22 22:09:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD301B2993 for ; Sun, 22 Jun 2014 22:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 C4canavIiy4P for ; Sun, 22 Jun 2014 22:09:23 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24CE1A045D for ; Sun, 22 Jun 2014 22:09:15 -0700 (PDT) Received: from ppp118-209-152-146.lns20.mel6.internode.on.net ([118.209.152.146]:56598 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WywUw-0006Pa-UB for clue@ietf.org; Mon, 23 Jun 2014 15:08:55 +1000 Message-ID: <53A7B678.9070808@nteczone.com> Date: Mon, 23 Jun 2014 15:09:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> In-Reply-To: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oRJG4A0bl-DAX0cBAlHg6WNyYuo Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 05:09:25 -0000 Hello Roni, Please see below. Regards, Christian On 23/06/2014 12:50 AM, Roni Even wrote: > > Hi, > > Trying to write the call flows make me review the other documents > (good excuse) > > This is the base CLUE message type > > > > > > > > > > > > use="required"/> > > > > > > Some comments > > 1.What is the purpose of the ClueId? Is this for displaying the > station name? > [CNG] The draft says its the identifier of the CP (CLUE participant???) within the telepresence system. I agree we need some more information about this. > > 2.The version (v) is defined as string, this is also the type for the > version in the supported version. Being a string will make comparison > in option and option response dependent on having the same string in > both. For example the option can have “v1.0” while the response will > be “ver 1.0”, should be positive integer also in version list type. > [CNG] I agree we should specify the exact version string to use. > > 3.Why do we need the fixed attribute “protocol” with the vale CLUE, > this is already known from the ppid (51) of the sctp channel? I assume > that if we will have another transport it will include the opening of > a CLUE channel. > [CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" will help with identification. Given the size of the XML I don't think a few extra bytes for this is a problem. > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 23 01:54:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A81E1B2A44 for ; Mon, 23 Jun 2014 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x97g75Ll3iwr for ; Mon, 23 Jun 2014 01:54:36 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAFD1B2A15 for ; Mon, 23 Jun 2014 01:49:53 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so6396921wes.7 for ; Mon, 23 Jun 2014 01:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=/32SuS5PM8o8YGfPNHL6HWQHsyJ/zS96vn/KcLFvZbs=; b=foAm4HM+iMB/OZ6AsdH5YJLeB5cHzYFjWoyfr2r7SDPNCp4rHV5Z+9UBqBBewet7Br 7pV41gKKlbPfYxDLPziuOTq7RBfeW7fUoSIiL6wDS+Jhdapb5u+hL2yW++fW53aEJtDv fY8kUAqZ1YT6M3hnJ1SxIC5A003m9GqH/1VeRBd1lKB7HdDzNela0JoD+Wz/sbJxQFuo kwQ8eE8//xYJOTFVsfp3dXfUQwZBMFpoCFyhDYW5X+vfUJQRdExOONA/8gWHDRWJivFE B0ES4GO2BlauKuFG2a+7ohjFdsaISnjrEiSLWokWB0eNR3H6Ytn+w/kfujb+gXc9V49V 7TnA== X-Received: by 10.194.94.226 with SMTP id df2mr1843268wjb.113.1403513388446; Mon, 23 Jun 2014 01:49:48 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id gd5sm34837504wjb.40.2014.06.23.01.49.46 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 01:49:47 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A737D4.9070808@alum.mit.edu> <03a401cf8e5d$d038f490$70aaddb0$@gmail.com> <53A74975.6050306@alum.mit.edu> In-Reply-To: <53A74975.6050306@alum.mit.edu> Date: Mon, 23 Jun 2014 11:49:42 +0300 Message-ID: <03cb01cf8ec0$163e7250$42bb56f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJFKbhM3XYMAHeDWEWDfRd7RrdWlAG+prL2AnOGEWwDJZTlIZpYbBew Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/z-ZL8STRj1knihpn22UPHWeVzpM Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 08:54:37 -0000 Hi, So I am confused. According to RFC4960 Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data. And Payload Protocol Identifiers Except for value 0, which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data. The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP. So what is the purpose of the IANA registry for PPIDs and why we do not allocate a unique CLUE PPID but re-use ones used by webRTC. This may cause confusion for applications that will look at the PPID value and take action based on it which is OK according to SCTP. I am not saying we should not use the protocol-id fixed value in the CLUE message but it is more a question also for the CLUE data channel BTW: the registry http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p arameters-25 does not mention that some values were deprecated but still they should not be re-used > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 23 June, 2014 12:24 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] CLUE protocol message type comment > > On 6/22/14 5:06 PM, Roni Even wrote: > > Hi Paul, > > This is not my understanding of the PPID parameter. > > There is a IANA registry for SCTP PPID > > http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml# > > sctp-p > > arameters-25 and looking at it PPID 51 is already assigned Roni > > Yes, I know. Values 50-54 were defined for use with data channels. Of those, 52 > and 54 have already been effectively deprecated. 51 and 53 are used for data > channel payloads. The distinction between them is an artifact of javascript. > > *All* payload data using data channels will be with either ppid 51 or 53. We > can't claim 51 as being unique for clue. > > Thanks, > Paul > > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 22 June, 2014 11:09 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] CLUE protocol message type comment > >> > >> On 6/22/14 10:50 AM, Roni Even wrote: > >> > >>> 3.Why do we need the fixed attribute "protocol" with the vale CLUE, > >>> this is already known from the ppid (51) of the sctp channel? I > >>> assume that if we will have another transport it will include the > >>> opening of a CLUE channel. > >> > >> ppid 51 is not unique to clue - it is used for all data channel payloads. > >> > >> Without something in the xml, determining that this is clue will be > > contextual. > >> Having it be explicit will help with analysis tools, deep packet > > inspection, etc. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From nobody Mon Jun 23 01:56:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295521B2A23 for ; Mon, 23 Jun 2014 01:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIXzArqSpIj9 for ; Mon, 23 Jun 2014 01:55:59 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EA11B2A3A for ; Mon, 23 Jun 2014 01:53:23 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so3778917wib.3 for ; Mon, 23 Jun 2014 01:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=EFoBu9RquNHObAqRrzIUv3ud8KJKD/A3lcDooYwxelU=; b=AClAxFw/dyhG/kQNDBVDaJ2Ucn+e/Ot9/gj+eY/mjp0fpT783Arj9SYnTmxpZIt1O9 hPguDRXwHm73+ZwnomePm70igK0z3mfB1uL0bxvac4iL6G87flDjQGz2zEZZZfQCPotN /hbeOmwF0PyJr40dK2FsLm+NinzBstZNv4HjXuywP2LnqGmRsjyd6rXIPbDtxBvo9Mw4 HWX9ipUj1G4qZtIW4XuBxO8uye8NoFZWR2vTkInxN3ItU6Bsu1WRCzVtD3XetX1U2rhE L6oVWze57/uaUiVxwKEnJIFLpvNxVYUoOCTEF76wVtdSPynZNZ+M2iiaC/NQ35hnuMYV Nq9g== X-Received: by 10.180.72.176 with SMTP id e16mr24134782wiv.44.1403513598053; Mon, 23 Jun 2014 01:53:18 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id h3sm34853246wjz.48.2014.06.23.01.53.16 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 01:53:17 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A7B678.9070808@nteczone.com> In-Reply-To: <53A7B678.9070808@nteczone.com> Date: Mon, 23 Jun 2014 11:53:13 +0300 Message-ID: <03cc01cf8ec0$933d5910$b9b80b30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJFKbhM3XYMAHeDWEWDfRd7RrdWlAG0XYGqmoWJ5PA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Nbk8kdjASKZXsOp0gNQiVoF404A Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 08:56:00 -0000 Christian, The version should not be a string but an integer, similar example is XCON protocol which uses an integer. As for PPID, it is for the application above the SCTP (RFC4960) which is either RTCweb (ppid=50) or CLUE (which should have a unique IANA registered PPID) Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 23 June, 2014 8:09 AM > To: clue@ietf.org > Subject: Re: [clue] CLUE protocol message type comment > > Hello Roni, > > Please see below. > > Regards, Christian > > On 23/06/2014 12:50 AM, Roni Even wrote: > > > > Hi, > > > > Trying to write the call flows make me review the other documents > > (good excuse) > > > > This is the base CLUE message type > > > > > > > > > > > > > > > > > > > > > > > > > use="required"/> > > > > > > > > > > > > Some comments > > > > 1.What is the purpose of the ClueId? Is this for displaying the > > station name? > > > [CNG] The draft says its the identifier of the CP (CLUE participant???) within the > telepresence system. I agree we need some more information about this. > > > > 2.The version (v) is defined as string, this is also the type for the > > version in the supported version. Being a string will make comparison > > in option and option response dependent on having the same string in > > both. For example the option can have "v1.0" while the response will > > be "ver 1.0", should be positive integer also in version list type. > > > [CNG] I agree we should specify the exact version string to use. > > > > 3.Why do we need the fixed attribute "protocol" with the vale CLUE, > > this is already known from the ppid (51) of the sctp channel? I assume > > that if we will have another transport it will include the opening of > > a CLUE channel. > > > [CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" > will help with identification. Given the size of the XML I don't think a few extra > bytes for this is a problem. > > > Roni > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 23 05:30:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716031B2AA1 for ; Mon, 23 Jun 2014 05:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N2x1jyzlhAP for ; Mon, 23 Jun 2014 05:30:45 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8B01B2A96 for ; Mon, 23 Jun 2014 05:30:45 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so6993155wes.35 for ; Mon, 23 Jun 2014 05:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=N5dlUH1c/dumP86S0WvBR60FACyB02oJh3fWNjnnQzA=; b=Fg+4Gu3l+BdAwRZs28Mrz7m8a0w6Zshb5V+74b/6oMZewxk3iRI1LVUH8CH2A2FJPp /CA5357HP+n7oq/GcWLUv4U0uDjq6yqhFdlmalHN0+5BCNjdV6Gsy+EyojRwKk3ik0Th M5MNCR4u60gSmAmbhaHLMyLJpO8Nsk6oBaD+bLelayOiARTeUueI1nqfpP2Mpa95NmxG qi9DdIdGaYMdYuD2PR8hcB2UJhnu7SDOlWFzRfk9fpqHoFNfKkdXM9OyCFwzw6iKsqBy iCc9W8MXNIkZEt+Oy/H7YE6aUO5LaOE3hB1ftfT3G1pMk6z30p99yGfbewKcev6e3Eyc PtmA== X-Received: by 10.194.77.238 with SMTP id v14mr4381996wjw.103.1403526643039; Mon, 23 Jun 2014 05:30:43 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id r9sm32998628wia.17.2014.06.23.05.30.41 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 05:30:42 -0700 (PDT) From: "Roni Even" To: Date: Mon, 23 Jun 2014 15:30:38 +0300 Message-ID: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D4_01CF8EF8.17E39C60" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac+O3kKlVzMJdGh1TxajEQU+s53fIw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7JWJH5Tq3OXHVi47Dpl8ErmzlCY Subject: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 12:30:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D4_01CF8EF8.17E39C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Looking at the discussion in RTCweb I understand that SCTP PPID=51 is for UTF-16 string and they may register with IANA a new PPID for utf-8. I understand that from the RTCweb perspective defining a general string PPID make sense. The CLUE document in table 1 calls this PPID 51 - CLUE protocol. The question is why we use a general string PPID and not register a SCTP ppid for CLUE? Roni ------=_NextPart_000_03D4_01CF8EF8.17E39C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Looking at the = discussion in RTCweb I understand that SCTP PPID=3D51 is for UTF-16 = string and they may register with IANA a new PPID for = utf-8.

 

I understand that from the RTCweb perspective defining = a general string PPID make sense.

The CLUE document in table 1 calls this  PPID 51 = - CLUE protocol.

The question is why = we use  a general string PPID and not register a SCTP ppid for = CLUE?

 

Roni

------=_NextPart_000_03D4_01CF8EF8.17E39C60-- From nobody Mon Jun 23 07:01:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81C1B2B15 for ; Mon, 23 Jun 2014 07:01:21 -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 mrDWB1DBSP_d for ; Mon, 23 Jun 2014 07:01:19 -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 5FA931B2B1F for ; Mon, 23 Jun 2014 07:01:16 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id HpkK1o0081uE5Es51q1F5R; Mon, 23 Jun 2014 14:01:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id Hq1F1o00D3ZTu2S3cq1FQ2; Mon, 23 Jun 2014 14:01:15 +0000 Message-ID: <53A8332B.8050009@alum.mit.edu> Date: Mon, 23 Jun 2014 10:01:15 -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: Roni Even , clue@ietf.org References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A737D4.9070808@alum.mit.edu> <03a401cf8e5d$d038f490$70aaddb0$@gmail.com> <53A74975.6050306@alum.mit.edu> <03cb01cf8ec0$163e7250$42bb56f0$@gmail.com> In-Reply-To: <03cb01cf8ec0$163e7250$42bb56f0$@gmail.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=1403532075; bh=ETlxyM7nAD4ZGlmw9bb5Ltd44rZJ8ChPNJHBc9ZI+U8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PfN7le+o/GDU+7K1aya9k30WXdV4XE3AV25Zyrvy/rR5esm5vJ+kWcmAdK3edlM9t jqAFuTOcSeD73kA6js9mUeUpcbK/xG324QZUHKtGN+AHAXa82IBOmNexu5pAypxMWk +N9Uuk0cNY6mOmBfhPUbNHehjnyLgcUK2GHMODay7lZzZlkZRX4ZS0li2NW4KbuI29 CYOoWVq9y7UoJZEKA3H/nYVBitkTwWzYlwoyT81yBhCSHeBkGtSMvCJ9HgW1ZHeBVk IB5rnJcQYSc3k883kt1P/9vzjynJJXuXg2hz2mZM3a99lgD165rJp/Ys2vpQPbqjnR V/HY5wi8IccEw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a0le-Oap9s7WmLq9oEeGiQHVErc Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:01:21 -0000 On 6/23/14 4:49 AM, Roni Even wrote: > Hi, > So I am confused. > According to RFC4960 > > > Payload Protocol Identifier: 32 bits (unsigned integer) > > This value represents an application (or upper layer) specified > protocol identifier. This value is passed to SCTP by its upper > layer and sent to its peer. This identifier is not used by SCTP > but can be used by certain network entities, as well as by the > peer application, to identify the type of information being > carried in this DATA chunk. This field must be sent even in > fragmented DATA chunks (to make sure it is available for agents in > the middle of the network). Note that this field is NOT touched > by an SCTP implementation; therefore, its byte order is NOT > necessarily big endian. The upper layer is responsible for any > byte order conversions to this field. > > The value 0 indicates that no application identifier is specified > by the upper layer for this payload data. > > > > And > > > Payload Protocol Identifiers > > Except for value 0, which is reserved by SCTP to indicate an > unspecified payload protocol identifier in a DATA chunk, SCTP will > not be responsible for standardizing or verifying any payload > protocol identifiers; SCTP simply receives the identifier from the > upper layer and carries it with the corresponding payload data. > > The upper layer, i.e., the SCTP user, SHOULD standardize any specific > protocol identifier with IANA if it is so desired. The use of any > specific payload protocol identifier is out of the scope of SCTP. > > > So what is the purpose of the IANA registry for PPIDs and why we do not > allocate a unique CLUE PPID but re-use ones used by webRTC. This may cause > confusion for applications that will look at the PPID value and take action > based on it which is OK according to SCTP. > I am not saying we should not use the protocol-id fixed value in the CLUE > message but it is more a question also for the CLUE data channel This is an example of the problem of using flat namespaces for hierarchical structures. If we were using SCTP directly for CLUE, then it might make sense to assign a CLUE-specific PPID value. But we are instead putting CLUE over data channel. So data channel is the "SCTP user", and we need to adhere to its use of PPIDs. If we were to use some different PPID then we couldn't build a CLUE client over RTCWEB, because RTCWEB clients are restricted in how PPIDs are used. Thanks, Paul > BTW: the registry > http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p > arameters-25 does not mention that some values were deprecated but still > they should not be re-used > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 23 June, 2014 12:24 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] CLUE protocol message type comment >> >> On 6/22/14 5:06 PM, Roni Even wrote: >>> Hi Paul, >>> This is not my understanding of the PPID parameter. >>> There is a IANA registry for SCTP PPID >>> http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml# >>> sctp-p >>> arameters-25 and looking at it PPID 51 is already assigned Roni >> >> Yes, I know. Values 50-54 were defined for use with data channels. Of > those, 52 >> and 54 have already been effectively deprecated. 51 and 53 are used for > data >> channel payloads. The distinction between them is an artifact of > javascript. >> >> *All* payload data using data channels will be with either ppid 51 or 53. > We >> can't claim 51 as being unique for clue. >> >> Thanks, >> Paul >> >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 22 June, 2014 11:09 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] CLUE protocol message type comment >>>> >>>> On 6/22/14 10:50 AM, Roni Even wrote: >>>> >>>>> 3.Why do we need the fixed attribute "protocol" with the vale CLUE, >>>>> this is already known from the ppid (51) of the sctp channel? I >>>>> assume that if we will have another transport it will include the >>>>> opening of a CLUE channel. >>>> >>>> ppid 51 is not unique to clue - it is used for all data channel > payloads. >>>> >>>> Without something in the xml, determining that this is clue will be >>> contextual. >>>> Having it be explicit will help with analysis tools, deep packet >>> inspection, etc. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> > > From nobody Mon Jun 23 07:11:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FF11B2AF5 for ; Mon, 23 Jun 2014 07:11:00 -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 9BwyElZVM5Nl for ; Mon, 23 Jun 2014 07:10:56 -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 E0DDD1B295D for ; Mon, 23 Jun 2014 07:10:55 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id Hpzq1o0021ap0As5CqAvsB; Mon, 23 Jun 2014 14:10:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id HqAv1o0043ZTu2S3iqAvZ8; Mon, 23 Jun 2014 14:10:55 +0000 Message-ID: <53A8356F.70806@alum.mit.edu> Date: Mon, 23 Jun 2014 10:10:55 -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: clue@ietf.org References: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> In-Reply-To: <03d301cf8ede$f2961640$d7c242c0$@gmail.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=1403532655; bh=pRp51osizZBv6Ea4MpAX967Xq1WdGJm7d9HfOXRvXf4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ME+usYjSCym0uWLH9Br+4SgrwHbvPAu4rlr/teHXBxmS31F9d2gEA130soJAzU0GP k+CEcsuM/+vOA51HHlCLBYtShS9WDgp3T/LHqGPmU+qPfhde3e9/PdnAnBQgwzZ6Vg 5b8Ifg5Go2y+Vuzu+UG/5zHC78Za/xrtVTJUasgBVo8xUlLIAKPNTC5COHwWUOapT5 uju+Nnov+pQs6ouQ/SRg8ouDivbVkevS0cdXbwgPVZAgCBGnxsrRraQk7umORhH3qZ 2fxei75bgfXUl1J9S1HzCgu4eBIi1IIAsulnwECJPknt1lH89ORrzTRjZH8iG41Gg1 4XjJHtkgIQccA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6YXgIIwcg1lNs_GyWnQAjwcy0yU Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:11:00 -0000 On 6/23/14 8:30 AM, Roni Even wrote: > Hi, > > Looking at the discussion in RTCweb I understand that SCTP PPID=51 is > for UTF-16 string and they may register with IANA a new PPID for utf-8. > > I understand that from the RTCweb perspective defining a general string > PPID make sense. > > The CLUE document in table 1 calls this PPID 51 - CLUE protocol. We can use anything that is allowed by rtcweb for data channels. We only need a string format, and for now there is only one string format we can choose. If another string format becomes available we could update to use that one instead, or leave it as a choice. > The question is why we use a general string PPID and not register a > SCTP ppid for CLUE? As I just replied in another message, then we would not be in compliance with the data channel spec, and couldn't build clue clients on top of rtcweb. Thanks, Paul > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 23 07:44:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69E31B2961 for ; Mon, 23 Jun 2014 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz8e9--adKBS for ; Mon, 23 Jun 2014 07:44:17 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5701B296B for ; Mon, 23 Jun 2014 07:44:17 -0700 (PDT) X-ASG-Debug-ID: 1403534654-05f27516dc563400001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 4WNBpVVk2cmRr4t7 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jun 2014 16:44:14 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([100.102.6.64]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s5NEiDOV029526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 16:44:13 +0200 Message-ID: <53A83D3C.5060207@unina.it> Date: Mon, 23 Jun 2014 16:44:12 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "clue@ietf.org" References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A7B678.9070808@nteczone.com> X-ASG-Orig-Subj: Re: [clue] CLUE protocol message type comment In-Reply-To: <53A7B678.9070808@nteczone.com> Content-Type: multipart/alternative; boundary="------------090105080606050303050600" X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1403534654 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6882 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bg4Ken7g0C5RzTN76Ma1yIqipvc Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:44:21 -0000 This is a multi-part message in MIME format. --------------090105080606050303050600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Christian, hi Roni, please see below. Il 23/06/2014 07:09, Christian Groves ha scritto: > > On 23/06/2014 12:50 AM, Roni Even wrote: >> >> 1.What is the purpose of the ClueId? Is this for displaying the >> station name? >> > [CNG] The draft says its the identifier of the CP (CLUE > participant???) within the telepresence system. I agree we need some > more information about this. >> The purpose of the identifier is providing a unique name for the CLUE entity involved in the telepresence session at the CLUE application level. It has not been conceived (necessarily) for carrying a displayable name of the CLUE entity. In the terminology section, in order to make a reference to both a CLUE endpoint and a CLUE MCU, we have introduced the term "CLUE participant" (for the sake of brevity/convenience). These are the definitions we used: CLUE Participant An entity able to use the CLUE protocol within a telepresence session. It can be an endpoint or a MCU able to use the CLUE protocol. Endpoint The logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices which source and sink media streams, and exactly one [RFC4353 ] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera room controllers to handheld devices. MCU Multipoint Control Unit (MCU) - a device that connects two or more endpoints together into one single multimedia conference [RFC5117 ]. An MCU may include a Mixer [RFC4353 ]. >> 2.The version (v) is defined as string, this is also the type for the >> version in the supported version. Being a string will make comparison >> in option and option response dependent on having the same string in >> both. For example the option can have “v1.0” while the response will >> be “ver 1.0”, should be positive integer also in version list type. >> > [CNG] I agree we should specify the exact version string to use. I agree we need to be more precise in the describing text. In our mind, the content of the "v" attribute would be something like "1.0" or "2.34" (without letters and with a dot separating the major version number to the minor version one). However, if we want to use a numeric content, we could split the major version number and the minor version one, by this way having the following attributes instead of the single "v" one: For the sake of brevity, we prefer the first solution with a more precise text describing the content of the "v" attribute. >> >> 3.Why do we need the fixed attribute “protocol” with the vale CLUE, >> this is already known from the ppid (51) of the sctp channel? I >> assume that if we will have another transport it will include the >> opening of a CLUE channel. >> > [CNG] As Paul mentioned ppid is for datachannel not CLUE. Having > "CLUE" will help with identification. Given the size of the XML I > don't think a few extra bytes for this is a problem. > I prefer to keep it because in the future an alternative transport protocol could be defined for CLUE and in that way we do not leverage the transport channel for the identification of the application protocol. Roberta ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille --------------090105080606050303050600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Christian, hi Roni,

please see below.

Il 23/06/2014 07:09, Christian Groves ha scritto:

On 23/06/2014 12:50 AM, Roni Even wrote:

1.What is the purpose of the ClueId? Is this for displaying the station name?

[CNG] The draft says its the identifier of the CP (CLUE participant???) within the telepresence system. I agree we need some more information about this.

The purpose of the identifier is providing a unique name for the CLUE entity involved in the telepresence session at the CLUE application level.
It has not been conceived (necessarily) for carrying a displayable name of the CLUE entity.
In the terminology section, in order to make a reference to both a CLUE endpoint and a CLUE MCU, we have introduced the term "CLUE participant" (for the sake of brevity/convenience).
These are the definitions we used:

CLUE Participant  An entity able to use the CLUE protocol within a
      telepresence session.  It can be an endpoint or a MCU able to use
      the CLUE protocol.

Endpoint  The logical point of final termination through receiving,
      decoding and rendering, and/or initiation through capturing,
      encoding, and sending of media streams.  An endpoint consists of
      one or more physical devices which source and sink media streams,
      and exactly one [RFC4353] Participant (which, in turn, includes
      exactly one SIP User Agent).  Endpoints can be anything from
      multiscreen/multicamera room controllers to handheld devices.

MCU  Multipoint Control Unit (MCU) - a device that connects two or
      more endpoints together into one single multimedia conference
      [RFC5117].  An MCU may include a Mixer [RFC4353].
 

2.The version (v) is defined as string, this is also the type for the version in the supported version. Being a string will make comparison in option and option response dependent on having the same string in both. For example the option can have “v1.0” while the response will be “ver 1.0”, should be positive integer also in version list type.

[CNG] I agree we should specify the exact version string to use.

I agree we need to be more precise in the describing text.
In our mind, the content of the "v" attribute would be something like "1.0" or "2.34" (without letters and with a dot separating the major version number to the minor version one).
However, if we want to use a numeric content, we could split the major version number and the minor version one, by this way having the following attributes instead of the single "v" one:

<xs:attribute name="majorVersion" type="xs:short" use="required"/>
<xs:attribute name="minorVersion" type="xs:short" use="required"/>

For the sake of brevity, we prefer the first solution with a more precise text describing the content of the "v" attribute.


3.Why do we need the fixed attribute “protocol” with the vale CLUE, this is already known from the ppid (51) of the sctp channel? I assume that if we will have another transport it will include the opening of a CLUE channel.

[CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" will help with identification. Given the size of the XML I don't think a few extra bytes for this is a problem.

I prefer to keep it because in the future an alternative transport protocol could be defined for CLUE and in that way we do not leverage the transport channel for the identification of the application protocol.

Roberta




----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­   --------------090105080606050303050600-- From nobody Mon Jun 23 07:50:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12761B2965 for ; Mon, 23 Jun 2014 07:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 5RcXD8bqrBKQ for ; Mon, 23 Jun 2014 07:50:01 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D98571B2955 for ; Mon, 23 Jun 2014 07:50:00 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id Hngt1o00327AodY59qq0rb; Mon, 23 Jun 2014 14:50:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id Hqq01o0043ZTu2S3fqq0iw; Mon, 23 Jun 2014 14:50:00 +0000 Message-ID: <53A83E98.5020304@alum.mit.edu> Date: Mon, 23 Jun 2014 10:50:00 -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: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> <539F9AD2.4040508@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.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=1403535000; bh=3h7WHbVoM7zUgs+Tsw7vuv46XREn4/c+Z4z2gvTVDyY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BF23/5ZiqBULO9F+rPf2of5PciB90BSqRTj/Dp/uA5ke+qPSCqYMBszxY6FudTTWp L67k6kigJusj3bqPBYknevCP8gO/DB/oJER1547NxKD+7Mg7rICDIjlYxlh8atnQI9 SlIjK8u1LgSyHRnQZZ0nIh8Xz7Nz7Ch6cqqCcdDkZikIRc6VlAcG/FMff32BkdFGWs 7Fp/WN7TSqUPL1W/HfgCUcWokJWTaMrhTgqM4zXr58UiVdMseTSymAOUrYbiAdw4f/ 50uXOzq82Wj5XZG9oRBgJYxHgWz1g5x0KoG4P2MYwNloishdjTrHo+bJwdDroi+0Oh yRuxe13FTSatA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xNX4oRnqVThyRPOQEoFqPDcQBzY Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:50:02 -0000 On 6/20/14 2:17 PM, Duckworth, Mark wrote: > Hi, > > There are a few suggestions below for the taxonomy document to clarify references to CLUE terms, which Bo has agreed with, or had questions which I tried to answer below. > > So I think it is not necessary to add anything in the CLUE framework that refers back to the taxonomy document, does that sound right? Or do we want to add all this information about the relationship between CLUE and taxonomy into the framework doc also? I think it is important that the relationships be clearly defined *somewhere*. In the long term I expect that other documents will reference the taxonomy and use its terminology or else explicitly relate their terminology to it. But the taxonomy has to start somewhere. If it is willing to reference the clue documents then we don't need to make the back reference. > Some more inline below. Me too. > Mark > > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Bo Burman >> Sent: Tuesday, June 17, 2014 8:09 AM >> To: Christian Groves; clue@ietf.org >> Subject: Re: [clue] more taxonomy >> >> Hi, >> >> I am currently updating the RTP Taxonomy, so this review of CLUE terms is >> really welcome. I plan to submit a new version of the Taxonomy draft within >> the next few days and would like to include the result of this discussion. >> >> Please find a few comments and questions inline below. >> >> Cheers, >> Bo >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: den 17 juni 2014 03:33 >>> To: clue@ietf.org >>> Subject: Re: [clue] more taxonomy >>> >>> Hello Mark, >>> >>> Please see my comments below. >>> >>> Regards, Christian >>> >>> On 14/05/2014 10:03 AM, Duckworth, Mark wrote: >>>> >>>> I'm looking at more terms and concepts that are used both in CLUE >>>> and in draft-ietf-avtext-rtp-grouping-taxonomy-01. >>>> >>>> Should we add some of this to the framework definitions section, to >>>> indicate how the CLUE terms relate to taxonomy terms? >>>> >>>> CLUE Media Capture: I'm not sure about this. I was going to say it >>>> is the same as taxonomy Media Capture, with either physical stimulus >>>> or synthetic stimulus. But the taxonomy draft says a CLUE Media >>>> Capture is the same as a taxonomy Media Source. I don't see how it >>>> makes any difference to CLUE either way. What do you think? >>>> >>> [CNG] I think CLUE captures can be either a RTP taxonomy media capture >>> or media source. The distinguishing factor appears to be that the >>> media capture is raw stream and a media source is a processed stream. >> CLUE media captures could be either. This could be updated in the taxonomy >> draft. >> [BoB] OK >> >>>> >>>> CLUE Individual Encoding: I think this is parameters of the taxonomy >>>> Media Encoder transformation. Taxonomy draft says "CLUE's 'Capture >>>> Encoding' provides specific encoding configuration for this purpose >>>> [Media Encoder]". I think it should be "CLUE's 'Individual >>>> Encoding'", not "Capture Encoding". (suggest change this in taxonomy >>>> draft, also in Packet Stream section) >>>> >>> [CNG] I agree individual coding would be more appropriate. >> [BoB] OK >> >>> >>>> CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest >> add >>>> this to taxonomy draft) >>>> >>> [CNG] I think its similar but not the same. A CLUE capture encoding >>> does result in an encoded stream but due to the link with a CLUE media >> capture ID there is also semantic information that is associated with the >> encoded stream. >> [BoB] OK. I get a feeling that the CLUE capture encoding term is (at least in >> the CLUE framework) mostly used to describe an Encoded Stream, but is >> sometimes also used to denote the Media Encoder transformation and the >> result is then (correctly) described as a Stream. Am I correct? If so, do you >> want to change that "duality" of capture encoding, or do you rather prefer >> that I just reflect this fact in the Taxonomy? > [Duckworth, Mark] I still think a Capture Encoding is the same as an Encoded Stream. Yes, there is a link to the semantic information, but still it is an Encoded Stream. I don't think Capture Encoding refers to the media encoder transformation. It is the output of the transformation, which is the Encoded Stream. I think it is more-or-less correct. There is a question of whether we want to dig into the distinction between the names of things and the things that are named. Specifically, the Configure message describes Capture Encodings that are being requested. But those don't exist as Encoded Streams until the Configure is received by the provider and acted upon. But I don't think we need to worry about that level of distinction. >>>> CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already >>>> equates CLUE Stream with Packet Stream). >>>> >>> >>>> CLUE Endpoint: includes a taxonomy End Point and a Participant. >>>> >>> [CNG] Yes >> [BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple >> entities running separate RTP stacks), or is that an unnecessary >> generalization? > [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. CLUE definition says "exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)". I think this is all consistent. I think Bo has it right. While a CLUE Endpoint has a single signaling address (making it a Taxonomy Participant), it can be decomposed into components that have separate RTP addresses. (E.g., one per screen.) >>>> CLUE MCU: includes multiple taxonomy End Points and a Participant >>>> for each conference. >>>> >>> [CNG] Yes >> [BoB] You mean the MCU itself is a Participant in each conference and as >> such also includes multiple End Points per conference, right? I'm don't understand the question. What do you mean by "each conference"? Are you thinking of the MCU as a server that supports multiple concurrent clue conferences? Or is an MCU an abstraction for the resources supporting a single conference? Of course real devices will support multiple concurrent conferences. But should we consider those to be one MCU or several? This is like the distinction between a UA and a server that can host multiple UAs. Right now the clue framework seems to define the MCU as supporting a single conference. And I think that is probably the right thing to do. We don't intend to define any normative behavior that applies across multiple conferences in the same server, so we don't need a term to talk about that. So having the term MCU talk about the support of a single conference is more useful to us. > [Duckworth, Mark] I think so. A CLUE MCU shouldn't be any different than any other MCU. The taxonomy document doesn't mention MCU or multipoint. I suggest neither CLUE framework nor taxonomy doc needs to add anything about relation between MCU and End Point and Participant. From a CLUE perspective an MCU is a type of endpoint. It is unclear to me whether more needs to be said about it than that. Is there anything that an MCU does that a non-MCU endpoint would *never* do? Or is it just that there are behaviors that an MCU is more likely to do than other endpoints? It may be useful for the Taxonomy to discuss MCUs in general. And ideally that would indeed be consistent with the CLUE notion of MCU. Thanks, Paul >>>> I can post suggestions to avtext to change the taxonomy draft >>>> regarding these CLUE terms, but I'd like to hear feedback from this >>>> group first. >>>> >>>> Regards, >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 23 07:56:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7011B2AF3 for ; Mon, 23 Jun 2014 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va82xb8BbYGu for ; Mon, 23 Jun 2014 07:56:33 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB861B2AE7 for ; Mon, 23 Jun 2014 07:56:33 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so6526815wgg.22 for ; Mon, 23 Jun 2014 07:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=hIYTA1n0p0hgrXasgZyFUyCqCFVo8OmSXU0WtkesXAM=; b=eqVBzUXRsMZwWjNoKEJhIMNBXm+RcQBNTb2LT+Cyj10jR9e4NSoHE55edZtIOYSpGL SaLp/EuW5Rdoq2KQFFdfVvSSnCGdQSlHK3+9RzM92jkkxeX8YXMUuLVSGX3sFxjeLyQA EJ82rIbPHYbtNCCwOvuJ9li6pzil9KJY3UEUbUNHBxl4vDd5t+AOcC8TCo9mbdFBikME Uw1igSd1f8Mkee9u06SF6IbdICUMLQnerA0lXrmuBwTDPvcCte6oaup3z6UtpXiVf2yn JhHjymYi2CPX1Fc3g73JLrIvItwipmTO7K9lYUjBKW9RYzEh8TffRCBwLHNEV9O77SB5 LpVQ== X-Received: by 10.194.243.104 with SMTP id wx8mr27856799wjc.32.1403535389265; Mon, 23 Jun 2014 07:56:29 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id ge6sm12784403wic.0.2014.06.23.07.56.27 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 07:56:28 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> <53A8356F.70806@alum.mit.edu> In-Reply-To: <53A8356F.70806@alum.mit.edu> Date: Mon, 23 Jun 2014 17:56:22 +0300 Message-ID: <03ee01cf8ef3$4fc6a7d0$ef53f770$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQIxrCemaM8g/kTDl8MiWBlyw2kAvwEu48xLmrEQbYA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qnxsNAZLJ1lSMEsf11iMsRHTVh8 Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:56:35 -0000 Paul, I am OK with the current approach but I am not sure that the reasons you give prevent using different PPID https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.6 says "The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the interpretation of the "Payload data". For identifying a JavaScript string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary" MUST be used (see Section 8)." We are not sending a JavaScript string so it is not clear that we cannot send a CLUE XML based message using a different PPID (not 51). I am not too familiar with Java script so I was wondering if we will need to do XML to string to send a clue message and string to XML when receiving a CLUE message? At least I saw such methods in java script. Still your major point is that if we use WebRTC string ppid is will be interoperable in webrtc environment, I do not see the problem since both sides need to support CLUE anyhow so they can have any PPID if the rtcweb data channel document does not prevent it. Again we can keep the "CLUE" protocol in the CLUE message header. Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 June, 2014 5:11 PM > To: clue@ietf.org > Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 > > On 6/23/14 8:30 AM, Roni Even wrote: > > Hi, > > > > Looking at the discussion in RTCweb I understand that SCTP PPID=51 is > > for UTF-16 string and they may register with IANA a new PPID for utf-8. > > > > I understand that from the RTCweb perspective defining a general > > string PPID make sense. > > > > The CLUE document in table 1 calls this PPID 51 - CLUE protocol. > > We can use anything that is allowed by rtcweb for data channels. We only need > a string format, and for now there is only one string format we can choose. If > another string format becomes available we could update to use that one > instead, or leave it as a choice. > > > The question is why we use a general string PPID and not register a > > SCTP ppid for CLUE? > > As I just replied in another message, then we would not be in compliance with > the data channel spec, and couldn't build clue clients on top of rtcweb. > > Thanks, > Paul > > > Roni > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 23 08:07:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A41B2AFF for ; Mon, 23 Jun 2014 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.029 X-Spam-Level: ** X-Spam-Status: No, score=2.029 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq3Csjm82NQo for ; Mon, 23 Jun 2014 08:07:07 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A11B2971 for ; Mon, 23 Jun 2014 08:07:07 -0700 (PDT) X-ASG-Debug-ID: 1403536024-05ce371779592120001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id IoRF47g1iVYSGzYt (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 17:07:04 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s5NF6xT6017796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 17:07:04 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_1E854BD0-5A96-4175-8C5C-CDD317B58EAA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE protocol message type comment In-Reply-To: <53A8332B.8050009@alum.mit.edu> Date: Mon, 23 Jun 2014 17:07:00 +0200 Message-Id: <8EAD79B1-DC40-4F82-8E87-8BE90147E6B2@unina.it> References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A737D4.9070808@alum.mit.edu> <03a401cf8e5d$d038f490$70aaddb0$@gmail.com> <53A74975.6050306@alum.mit.edu> <03cb01cf8ec0$163e7250$42bb56f0$@gmail.com> <53A8332B.8050009@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.2) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1403536024 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6883 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/FsVFb_JTrlMCJTNTfOsrWdXYS10 Cc: clue@ietf.org Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:07:11 -0000 --Apple-Mail=_1E854BD0-5A96-4175-8C5C-CDD317B58EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello there, I think Paul's e-mail sheds light on the issue. If I understand correctly, = if we were to use CLUE on top of SCTP, we might simply choose a CLUE-protoc= ol identifier (clue protocol ID) at the protocol layer and map (i.e., copy)= such an identifier onto the PPID field in the SCTP chunk. Since the PPID i= s a 32-bit unsigned integer, we should hence register (at IANA) a proper pr= otocol number for CLUE and put such number inside the SCTP chunk. Though, since we're actually using "CLUE on top of the RtcWeb DataChannel o= n top of SCTP", we have to stick to the PPID (51) that has been assigned to= the DataChannel. This reinforces my personal belief that keeping the yet-t= o-be-registered "clue protocol identifier" at the telepresence (i.e., CLUE)= level is definitely a good idea. What is your feeling about this? Simon > On 6/23/14 4:49 AM, Roni Even wrote: >> Hi, >> So I am confused. >> According to RFC4960 >>=20 >>=20 >> Payload Protocol Identifier: 32 bits (unsigned integer) >>=20 >> This value represents an application (or upper layer) specified >> protocol identifier. This value is passed to SCTP by its upper >> layer and sent to its peer. This identifier is not used by SCTP >> but can be used by certain network entities, as well as by the >> peer application, to identify the type of information being >> carried in this DATA chunk. This field must be sent even in >> fragmented DATA chunks (to make sure it is available for agents in >> the middle of the network). Note that this field is NOT touched >> by an SCTP implementation; therefore, its byte order is NOT >> necessarily big endian. The upper layer is responsible for any >> byte order conversions to this field. >>=20 >> The value 0 indicates that no application identifier is specified >> by the upper layer for this payload data. >>=20 >>=20 >>=20 >> And >>=20 >>=20 >> Payload Protocol Identifiers >>=20 >> Except for value 0, which is reserved by SCTP to indicate an >> unspecified payload protocol identifier in a DATA chunk, SCTP will >> not be responsible for standardizing or verifying any payload >> protocol identifiers; SCTP simply receives the identifier from the >> upper layer and carries it with the corresponding payload data. >>=20 >> The upper layer, i.e., the SCTP user, SHOULD standardize any specific >> protocol identifier with IANA if it is so desired. The use of any >> specific payload protocol identifier is out of the scope of SCTP. >>=20 >>=20 >> So what is the purpose of the IANA registry for PPIDs and why we do not >> allocate a unique CLUE PPID but re-use ones used by webRTC. This may cau= se >> confusion for applications that will look at the PPID value and take act= ion >> based on it which is OK according to SCTP. >> I am not saying we should not use the protocol-id fixed value in the CLUE >> message but it is more a question also for the CLUE data channel >=20 > This is an example of the problem of using flat namespaces for hierarchic= al structures. >=20 > If we were using SCTP directly for CLUE, then it might make sense to assi= gn a CLUE-specific PPID value. But we are instead putting CLUE over data ch= annel. So data channel is the "SCTP user", and we need to adhere to its use= of PPIDs. >=20 > If we were to use some different PPID then we couldn't build a CLUE clien= t over RTCWEB, because RTCWEB clients are restricted in how PPIDs are used. >=20 > Thanks, > Paul >=20 >> BTW: the registry >> http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sc= tp-p >> arameters-25 does not mention that some values were deprecated but still >> they should not be re-used >>=20 >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 23 June, 2014 12:24 AM >>> To: Roni Even; clue@ietf.org >>> Subject: Re: [clue] CLUE protocol message type comment >>>=20 >>> On 6/22/14 5:06 PM, Roni Even wrote: >>>> Hi Paul, >>>> This is not my understanding of the PPID parameter. >>>> There is a IANA registry for SCTP PPID >>>> http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml# >>>> sctp-p >>>> arameters-25 and looking at it PPID 51 is already assigned Roni >>>=20 >>> Yes, I know. Values 50-54 were defined for use with data channels. Of >> those, 52 >>> and 54 have already been effectively deprecated. 51 and 53 are used for >> data >>> channel payloads. The distinction between them is an artifact of >> javascript. >>>=20 >>> *All* payload data using data channels will be with either ppid 51 or 5= 3. >> We >>> can't claim 51 as being unique for clue. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: 22 June, 2014 11:09 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] CLUE protocol message type comment >>>>>=20 >>>>> On 6/22/14 10:50 AM, Roni Even wrote: >>>>>=20 >>>>>> 3.Why do we need the fixed attribute "protocol" with the vale CLUE, >>>>>> this is already known from the ppid (51) of the sctp channel? I >>>>>> assume that if we will have another transport it will include the >>>>>> opening of a CLUE channel. >>>>>=20 >>>>> ppid 51 is not unique to clue - it is used for all data channel >> payloads. >>>>>=20 >>>>> Without something in the xml, determining that this is clue will be >>>> contextual. >>>>> Having it be explicit will help with analysis tools, deep packet >>>> inspection, etc. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>=20 >>>>=20 >>=20 >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ ----=0D 5x1000 AI GIOVANI RICERCATORI=0D DELL'UNIVERSIT=C0 DI NAPOLI=0D Codice Fiscale: 00876220633=0D www.unina.it/Vademecum5permille=0D --Apple-Mail=_1E854BD0-5A96-4175-8C5C-CDD317B58EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello there,

I think Paul's e-mail sheds light on the issue. If I understand cor= rectly, if we were to use CLUE on top of SCTP, we might simply choose a CLU= E-protocol identifier (clue protocol ID) at the protocol layer and map (i.e= ., copy) such an identifier onto the PPID field in the SCTP chunk. Since th= e PPID is a 32-bit unsigned integer, we should hence register (at IANA) a p= roper protocol number for CLUE and put such number inside the SCTP chunk.
Though, since we're actually using "CLUE on top of the RtcWeb Data= Channel on top of SCTP", we have to stick to the PPID (51) that has been as= signed to the DataChannel. This reinforces my personal belief that keeping = the yet-to-be-registered "clue protocol identifier" at the telepresence (i.= e., CLUE) level is definitely a good idea.

What is= your feeling about this?

Simon


On 6/23/14 4:49 AM, Roni Even wro= te:
Hi,
So I am confused.
According to R= FC4960


Payload Protocol Identifier: 32 bits (unsigned integer)
      This value represents an applica= tion (or upper layer) specified
      pro= tocol identifier.  This value is passed to SCTP by its upper
 = ;     layer and sent to its peer.  This ident= ifier is not used by SCTP
      but can b= e used by certain network entities, as well as by the
   = ;   peer application, to identify the type of information be= ing
      carried in this DATA chunk. &nb= sp;This field must be sent even in
      = fragmented DATA chunks (to make sure it is available for agents in
&nbs= p;     the middle of the network).  Note that= this field is NOT touched
      by an SC= TP implementation; therefore, its byte order is NOT
   &= nbsp;  necessarily big endian.  The upper layer is responsib= le for any
      byte order conversions t= o this field.

      The value 0 indic= ates that no application identifier is specified
   &nbs= p;  by the upper layer for this payload data.



And<= br>

Payload Protocol Identifiers

   Except fo= r value 0, which is reserved by SCTP to indicate an
   u= nspecified payload protocol identifier in a DATA chunk, SCTP will
 = ;  not be responsible for standardizing or verifying any payload<= br>    protocol identifiers; SCTP simply receives the identi= fier from the
   upper layer and carries it with the cor= responding payload data.

   The upper layer, i.e., t= he SCTP user, SHOULD standardize any specific
   protoco= l identifier with IANA if it is so desired.  The use of any
 =   specific payload protocol identifier is out of the scope of SCT= P.


So what is the purpose of the IANA registry for PPIDs and why= we do not
allocate a unique CLUE PPID but re-use ones used by webRTC. T= his may cause
confusion for applications that will look at the PPID valu= e and take action
based on it which is OK according to SCTP.
I am not= saying we should not use the protocol-id fixed value in the CLUE
messag= e but it is more a question also for the CLUE data channel
=
This is an example of the problem of using flat namespaces for hierarch= ical structures.

If we were using SCTP directly for CLUE, then it mi= ght make sense to assign a CLUE-specific PPID value. But we are instead put= ting CLUE over data channel. So data channel is the "SCTP user", and we nee= d to adhere to its use of PPIDs.

If we were to use some different PP= ID then we couldn't build a CLUE client over RTCWEB, because RTCWEB clients= are restricted in how PPIDs are used.

Thanks,
Paul

= BTW: the registry
http://www.iana.org/assignments/sctp-par= ameters/sctp-parameters.xhtml#sctp-p
arameters-25 does not mention t= hat some values were deprecated but still
they should not be re-used
=
-----Original Message-----
From: Paul Kyzi= vat [mailto:pkyzivat@alum.mit.edu]
Sent: 23 June, 2014 12:24 AM
To: R= oni Even; clue@ietf.org
Subject: Re: [clue] CLUE protocol message type c= omment

On 6/22/14 5:06 PM, Roni Even wrote:
Hi Paul,
This is not my understanding of the PPID parameter.
The= re is a IANA registry for SCTP PPID
http://www.iana.org/assignments/sctp= -parameters/sctp-parameters.xhtml#
sctp-p
arameters-25 and looking at= it PPID 51 is already assigned Roni

Yes, I know. Value= s 50-54 were defined for use with data channels. Of
those, = 52
and 54 have already been effectively deprec= ated. 51 and 53 are used for
data
channel payloads. The distinction between them is an artifact of
javascript.

*All* payload data u= sing data channels will be with either ppid 51 or 53.
We
can't claim 51 as being unique for clue.

= Thanks, Paul
<= br>

-----Original Me= ssage-----
From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul K= yzivat
Sent: 22 June, 2014 11:09 PM
To: clue@ietf.org
Subject: Re:= [clue] CLUE protocol message type comment

On 6/22/14 10:50 AM, Roni= Even wrote:

3.Why do we need the fixed at= tribute "protocol" with the vale CLUE,
this is already known from the pp= id (51) of the sctp channel? I
assume that if we will have another trans= port it will include the
opening of a CLUE channel.

= ppid 51 is not unique to clue - it is used for all data channel
payloads.

Without something in the= xml, determining that this is clue will be
contextual.
=
Having it be explicit will help with analysis too= ls, deep packet
inspection, etc.

Tha= nks,
Pa= ul

_______________________________________________
clue mailing l= ist
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue





________= _______________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/lis= tinfo/clue


&= nbsp;                    =        _\\|//= _
                  =                 ( O-O )
&= nbsp;  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                   = ;  Simon Pietro Romano
               Universita' di Napoli Federico II
  &= nbsp;                   Computer= Engineering Department 
           &= nbsp; Phone: +39 081 7683823 -- Fax: +39 081 7683816
   = ;                     &nb= sp;                  e-mail: <= a href=3D"mailto:spromano@unina.it">spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi d= egli 
    idioti. Ci rifletto un istante; e mi scor= aggio>>. Magritte.
          =          &= nbsp;                oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~= ~~~~
=                  \= (            (   )
    &= nbsp;                    =         \_)          ) /
                   =                     &nbs= p;                     &n= bsp;        (_/

=







----
=0D 5x1000 AI GIOVANI=0D RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale:=0D 00876220633
www.unina.it= /Vademecum5permille

  ­­  = --Apple-Mail=_1E854BD0-5A96-4175-8C5C-CDD317B58EAA-- From nobody Mon Jun 23 08:14:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ACF1B2AFD for ; Mon, 23 Jun 2014 08:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln71M1as0N_C for ; Mon, 23 Jun 2014 08:14:50 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1886E1B2AF3 for ; Mon, 23 Jun 2014 08:14:20 -0700 (PDT) Received: from [216.82.254.19:41643] by server-15.bemta-7.messagelabs.com id 10/99-08061-A4448A35; Mon, 23 Jun 2014 15:14:18 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-96.messagelabs.com!1403536385!13174455!12 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20655 invoked from network); 23 Jun 2014 15:14:15 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 23 Jun 2014 15:14:15 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 23 Jun 2014 08:13:56 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" , "Bo Burman (bo.burman@ericsson.com)" Date: Mon, 23 Jun 2014 08:13:54 -0700 Thread-Topic: Endpoint and taxonomy End Point - RE: [clue] more taxonomy Thread-Index: Ac+O9b8zPxK4p/OASzySGxPEKdHutQ== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF4B4@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YWpqHtUH142Pyib65mjDRRxPcXU Subject: [clue] Endpoint and taxonomy End Point - RE: more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:14:53 -0000 Hello Paul and Bo, ... snip ... > >>>> CLUE Endpoint: includes a taxonomy End Point and a Participant. > >>>> > >>> [CNG] Yes > >> [BoB] Could not a CLUE Endpoint consist of multiple End Points > >> (multiple entities running separate RTP stacks), or is that an > >> unnecessary generalization? > > [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. CL= UE > definition says "exactly one [RFC4353] Participant (which, in turn, inclu= des > exactly one SIP User Agent)". I think this is all consistent. >=20 > I think Bo has it right. While a CLUE Endpoint has a single signaling add= ress > (making it a Taxonomy Participant), it can be decomposed into components > that have separate RTP addresses. (E.g., one per screen.) [Duckworth, Mark] Maybe you and Bo are right. Are you saying a CLUE Endpo= int includes exactly one taxonomy Participant, and one or more taxonomy End= Points? And this is because Participant relates to the SIP User Agent, wh= ile End Point relates to RTP? I'm still not sure about it, from the taxono= my point of view. The Taxonomy says a single End Point can have multiple C= NAMEs for different synchronization contexts. A CLUE Endpoint (or even a n= on-CLUE disaggregated endpoint) can have separate RTP addresses, but could = use the same CNAME for the same synchronization context. Is this consisten= t with taxonomy document calling these separate RTP addresses as separate E= nd Points associated with the same Participant? If that is what is intended by the Taxonomy, then would it be good to add a= statement in Taxonomy that a Participant can be associated with one or mor= e End Points? But an End Point is associated with only one Participant? Mark From nobody Mon Jun 23 08:46:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D61B2B50 for ; Mon, 23 Jun 2014 08:46:47 -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 bcKwrcHaE7nk for ; Mon, 23 Jun 2014 08:46:46 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id AE98A1B2B4E for ; Mon, 23 Jun 2014 08:46:45 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id HrWe1o0030cZkys59rmlJJ; Mon, 23 Jun 2014 15:46:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Hrml1o0053ZTu2S3WrmlQh; Mon, 23 Jun 2014 15:46:45 +0000 Message-ID: <53A84BE4.1000001@alum.mit.edu> Date: Mon, 23 Jun 2014 11:46:44 -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: Roni Even , clue@ietf.org References: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> <53A8356F.70806@alum.mit.edu> <03ee01cf8ef3$4fc6a7d0$ef53f770$@gmail.com> In-Reply-To: <03ee01cf8ef3$4fc6a7d0$ef53f770$@gmail.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=1403538405; bh=p1w2weimKvGPf5mhHj8EuDZg8hWG1V7HtvwDH3zXblk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mo435CLk6GIkIBaAu6pxnUBq1jZhI98ZGNPYAeRrl+VkambGvOlz5qIhZYCZDHGAL Xkz4cKa+B2uNkGqltswSkg7vwv9qSeExkYluTi1kKLShnUlxTCU4e2rEnWnKss3Mjh vGoTgMXp59U+JDA0fwmV9jn7s/sbOfq1LjUi5ZROC65fobejCrMOybccfW9GC7et9Q Upl9vSxRnFNFJ9dy+Sopd3hyhIDyNZFQwsJCQhDIYP9+UAJ8v9phTHCsh6Y/eG3eBx luoC5HMB/UqStI//GS7EwKNCkbbFO66ZzukcEmxlDUoi7/Ex8mmotznrlRtim7Km4Q FtKjPS0lJaPQQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/foL-Mb4jPyGv8zJEieANq38XdZU Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:46:47 -0000 On 6/23/14 10:56 AM, Roni Even wrote: > Paul, > I am OK with the current approach but I am not sure that the reasons you > give prevent using different PPID > > > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.6 > says > > "The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the > interpretation of the "Payload data". For identifying a JavaScript > string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for > JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary" > MUST be used (see Section 8)." > > We are not sending a JavaScript string so it is not clear that we cannot > send a CLUE XML based message using a different PPID (not 51). My understanding (may be wrong) is that the browser implementation of the data channel will determine what PPID to use based on the javascript datatype used to provide the payload to the API. The javascript application won't have direct control over the PPID. > I am not too familiar with Java script so I was wondering if we will need to > do XML to string to send a clue message and string to XML when receiving a > CLUE message? At least I saw such methods in java script. I'm not sure either, but I assume either that conversion will either be done explicitly or implicitly via coercion during the call to the API. > Still your major point is that if we use WebRTC string ppid is will be > interoperable in webrtc environment, I do not see the problem since both > sides need to support CLUE anyhow so they can have any PPID if the rtcweb > data channel document does not prevent it. If the rtcweb allows explicit control of the PPID and use of any PPID value then I agree. I don't think that is the case. (Where is the actual javascript data channel API specification?) > Again we can keep the "CLUE" protocol in the CLUE message header. Sure. Clearly the discussion has ceased to be about that. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 23 June, 2014 5:11 PM >> To: clue@ietf.org >> Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 >> >> On 6/23/14 8:30 AM, Roni Even wrote: >>> Hi, >>> >>> Looking at the discussion in RTCweb I understand that SCTP PPID=51 is >>> for UTF-16 string and they may register with IANA a new PPID for utf-8. >>> >>> I understand that from the RTCweb perspective defining a general >>> string PPID make sense. >>> >>> The CLUE document in table 1 calls this PPID 51 - CLUE protocol. >> >> We can use anything that is allowed by rtcweb for data channels. We only > need >> a string format, and for now there is only one string format we can > choose. If >> another string format becomes available we could update to use that one >> instead, or leave it as a choice. >> >>> The question is why we use a general string PPID and not register a >>> SCTP ppid for CLUE? >> >> As I just replied in another message, then we would not be in compliance > with >> the data channel spec, and couldn't build clue clients on top of rtcweb. >> >> Thanks, >> Paul >> >>> Roni >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Jun 23 08:50:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20A91B2B54 for ; Mon, 23 Jun 2014 08:50:01 -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 6Sn1uxSD7Uyl for ; Mon, 23 Jun 2014 08:50:01 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id B845A1B2B52 for ; Mon, 23 Jun 2014 08:50:00 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Hrj91o0040cZkys5Brq06z; Mon, 23 Jun 2014 15:50:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Hrq01o0013ZTu2S3Wrq023; Mon, 23 Jun 2014 15:50:00 +0000 Message-ID: <53A84CA7.3090305@alum.mit.edu> Date: Mon, 23 Jun 2014 11:49:59 -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: "Duckworth, Mark" , "clue@ietf.org" , "Bo Burman (bo.burman@ericsson.com)" References: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF4B4@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF4B4@CRPMBOXPRD08.polycom.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=1403538600; bh=KiRd+8P5DjOi6YnYKUrXctuI9qUrC5yioRHMJsl5kTc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lNvbmhnPCNmNJv2FD49Pr7XEmc5NBIi+gX+9XMS6hDPmC9CmmPwqN+KtdizE3vq0H I5SE+MlO3GjKmvAWel9t2xrD9xTgQFSdzVn2W48cYZdZtLqsY4NhNgPSvJFsr3Gmql eS0LfE0VE5C3gYoMLgVN4Rh8LVQyyMEzjYVo1cw8DctDK3Uvmhjd9jX4o6fCUrH+ek RC8Xsj5Y01lvP1tSefmgOf7aWvirysLJ4PoCisffOdMNoGSKLAjpQybillfP+JwilW j3FYfOha4dbP+1xrcpc6Fk82+POE2rxvC2Is9wSPO9Guh7HPqeVVf6l+F2ciJsh/Dr aTqAnwaVV+6bQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gMo31bsNQsn5nagmzo6_Su71RIM Subject: Re: [clue] Endpoint and taxonomy End Point - RE: more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:50:01 -0000 On 6/23/14 11:13 AM, Duckworth, Mark wrote: > Hello Paul and Bo, > > ... snip ... >>>>>> CLUE Endpoint: includes a taxonomy End Point and a Participant. >>>>>> >>>>> [CNG] Yes >>>> [BoB] Could not a CLUE Endpoint consist of multiple End Points >>>> (multiple entities running separate RTP stacks), or is that an >>>> unnecessary generalization? >>> [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. CLUE >> definition says "exactly one [RFC4353] Participant (which, in turn, includes >> exactly one SIP User Agent)". I think this is all consistent. >> >> I think Bo has it right. While a CLUE Endpoint has a single signaling address >> (making it a Taxonomy Participant), it can be decomposed into components >> that have separate RTP addresses. (E.g., one per screen.) > > [Duckworth, Mark] Maybe you and Bo are right. Are you saying a CLUE Endpoint includes exactly one taxonomy Participant, and one or more taxonomy End Points? And this is because Participant relates to the SIP User Agent, while End Point relates to RTP? Yes. > I'm still not sure about it, from the taxonomy point of view. I'm not certain. I defer to Bo or Jonathan. Thanks, Paul > The Taxonomy says a single End Point can have multiple CNAMEs for different synchronization contexts. A CLUE Endpoint (or even a non-CLUE disaggregated endpoint) can have separate RTP addresses, but could use the same CNAME for the same synchronization context. Is this consistent with taxonomy document calling these separate RTP addresses as separate End Points associated with the same Participant? > > If that is what is intended by the Taxonomy, then would it be good to add a statement in Taxonomy that a Participant can be associated with one or more End Points? But an End Point is associated with only one Participant? > > Mark > > From nobody Mon Jun 23 09:10:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625381B2C00 for ; Mon, 23 Jun 2014 09:10:10 -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 tDjji2RYiGES for ; Mon, 23 Jun 2014 09:10:09 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7F1B2C03 for ; Mon, 23 Jun 2014 09:03:19 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id HrkQ1o0050xGWP855s3Kzq; Mon, 23 Jun 2014 16:03:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Hs3J1o00Y3ZTu2S3Ys3KSp; Mon, 23 Jun 2014 16:03:19 +0000 Message-ID: <53A84FC6.1040308@alum.mit.edu> Date: Mon, 23 Jun 2014 12:03:18 -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: CLUE 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=1403539399; bh=AzCaXEwRYLvQDY6sObFRYRCAm/AM7Jwfng1njv4RhxQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AzgEO1mIFMRnRF4PRfCuoNq6Uz95VKj+B9FYDGXCAdQK0dqiVOaI8utfwhUYCuzho GAMtLZwJtlqSVa8Dt8/XByW3m3+rJC/wiBCqiNo3yAoWllwz3MDwxdss8cBVRYiKvA kI7J8qOE8uCswfK9frwhD5wkfwiUsoznZK7dbnURe3uZO73ywhHRLh8mcK68fwdg1f BqR3VWQheAdp37ABl5BglefplpIx6iUiFehfIOx08Fsb7MXdYJ3O12csqhn5tnALpK G06SjBlSofS9kTp3dmRiN0Feioj/IycL1UaBzaZugcmShIkkQwU5LGTkWFbQtSDwMF fQBHFBWV0tyQA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PYYbN9Zqf1bnmaCcT5MVgp6nOxI Subject: [clue] Design Team meeting Tuesday June 24 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 16:10:10 -0000 The design team meeting tomorrow was scheduled for discussion of the planned call flows document. To date we haven't had a submission for that yet, though I know Roni has one in the works. Even in the absence of a document, let's have the call tomorrow, to discuss what sort of content we want to see in it - level of detail, number and complexity of cases covered, etc. Thanks, Paul From nobody Mon Jun 23 10:00:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D521B2BC8 for ; Mon, 23 Jun 2014 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HaR9gNGuNJI for ; Mon, 23 Jun 2014 10:00:19 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24051B2BCD for ; Mon, 23 Jun 2014 09:51:11 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so4758891wib.9 for ; Mon, 23 Jun 2014 09:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=sCvHu5yFHO41K7AV389jIq1Ay/lJ3kwNNPf42/dDYR0=; b=MImx58eOiRFiFY3iG5DOMqu2PzS3hOxzjgpgmGREJr8BPeVGzCE/JK7rmxh3QdB/ow cKuolqSY12lZ2qRY/1uZTp+yeqjVB3tTSpzbiXwfNmaTcfWAn7oA/A681Mz5PwA2JgEV JvYUpudAm5/fO6WZZJamtnwxuTbolnDTiPPApkpYCoQk2VYgnpR+PwglVumjxPXCo5kK wv0SVaueFJg2lTKiDU/6Tkd4OO89WSXchA79TYnmu+nMxFu/0VhSSiseUGrF7zaeJUlT I7Y1TNiHdfBqp+wUaem51P8K2AS+43gSgQoWKgndVYK/Q/hDrQMT12hn4IBh51EfY3Wl d+/g== X-Received: by 10.180.79.38 with SMTP id g6mr12145676wix.61.1403542269101; Mon, 23 Jun 2014 09:51:09 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id i8sm34920762wiw.22.2014.06.23.09.51.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 09:51:08 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <53A84FC6.1040308@alum.mit.edu> In-Reply-To: <53A84FC6.1040308@alum.mit.edu> Date: Mon, 23 Jun 2014 19:51:03 +0300 Message-ID: <040501cf8f03$545eda50$fd1c8ef0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQGjRtx1fjL8oKOf2kp6vXkivH5PKJvXeHRA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZSLs7M44GVdlH1twjtorsJ4pxRA Subject: Re: [clue] Design Team meeting Tuesday June 24 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:00:20 -0000 Paul, I submitted a document yesterday http://www.ietf.org/id/draft-even-clue-call-flows-00.txt I also sent an email to the list about it Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 June, 2014 7:03 PM > To: CLUE > Subject: [clue] Design Team meeting Tuesday June 24 > > The design team meeting tomorrow was scheduled for discussion of the > planned call flows document. > > To date we haven't had a submission for that yet, though I know Roni has one in > the works. > > Even in the absence of a document, let's have the call tomorrow, to discuss > what sort of content we want to see in it - level of detail, number and > complexity of cases covered, etc. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 23 10:13:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30E61B2AE7 for ; Mon, 23 Jun 2014 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS_6rcpyi5yU for ; Mon, 23 Jun 2014 10:12:59 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D431B2982 for ; Mon, 23 Jun 2014 10:12:47 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so6604826wgg.1 for ; Mon, 23 Jun 2014 10:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=o8J4u7qsn7azkMe57jw8DGXi7KQN60rQnuNKBOZrvs0=; b=pMlu/LiQUiZXhAC3LndMHJw34pDN+f6aYXPObgiqXBw0ifUsn9LLbhGECYx1T21vuZ mj9hAm94HQ1d49IHWX0A5UyykVat2HAAUoEyNt1OzshbH5BmR7389WG6lZZSF/+ZMFEE inAMU+QE53puPWjKhliGzubGQ7xauBzztm0lhDQ7j+vetdx9daq6CCPz/ibPSQKdc4CZ vBp8Jy9r8GVeMxjuwFXYToabZ0Hc3K4zQWCA5gaCe1Dw/wN3SU212U+buOXQccbfk2VV sKwlQHqJaUxsQeqlpSyMUk7BMUJyyevozKnnSYhNzkr7RHiChTPPWCUs6f7WlscbJMvV SRyA== X-Received: by 10.194.92.244 with SMTP id cp20mr5802911wjb.109.1403543566564; Mon, 23 Jun 2014 10:12:46 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id cx5sm37543869wjb.8.2014.06.23.10.12.44 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 10:12:45 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> <53A8356F.70806@alum.mit.edu> <03ee01cf8ef3$4fc6a7d0$ef53f770$@gmail.com> <53A84BE4.1000001@alum.mit.edu> In-Reply-To: <53A84BE4.1000001@alum.mit.edu> Date: Mon, 23 Jun 2014 20:12:42 +0300 Message-ID: <040a01cf8f06$59c6cbd0$0d546370$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQIxrCemaM8g/kTDl8MiWBlyw2kAvwEu48xLAZfIxjcC3GA8O5qNmvoA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Gh6GsNA44bOZG6n3vKnDTIYuDks Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:13:01 -0000 Hi Paul, Looking at the discussion about ppid in the RTCweb mailing list I got the following points 1. The application have no control on the PPID so we MUST use the ones specified by webrtc and do the right conversions 2. The current DOMstring PPID=51 is specified as UTF-16 string and I think that the current approach will be to define a new PPID for UTF-8 string possibly also not to name it as DOMstring but utf-8 string Is this correct? Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 23 June, 2014 6:47 PM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 > > On 6/23/14 10:56 AM, Roni Even wrote: > > Paul, > > I am OK with the current approach but I am not sure that the reasons > > you give prevent using different PPID > > > > > > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section- > > 6.6 > > says > > > > "The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the > > interpretation of the "Payload data". For identifying a JavaScript > > string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for > > JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary" > > MUST be used (see Section 8)." > > > > We are not sending a JavaScript string so it is not clear that we > > cannot send a CLUE XML based message using a different PPID (not 51). > > My understanding (may be wrong) is that the browser implementation of the > data channel will determine what PPID to use based on the javascript datatype > used to provide the payload to the API. The javascript application won't have > direct control over the PPID. > > > I am not too familiar with Java script so I was wondering if we will > > need to do XML to string to send a clue message and string to XML when > > receiving a CLUE message? At least I saw such methods in java script. > > I'm not sure either, but I assume either that conversion will either be done > explicitly or implicitly via coercion during the call to the API. > > > Still your major point is that if we use WebRTC string ppid is will be > > interoperable in webrtc environment, I do not see the problem since > > both sides need to support CLUE anyhow so they can have any PPID if > > the rtcweb data channel document does not prevent it. > > If the rtcweb allows explicit control of the PPID and use of any PPID value then I > agree. I don't think that is the case. (Where is the actual javascript data > channel API specification?) > > > Again we can keep the "CLUE" protocol in the CLUE message header. > > Sure. Clearly the discussion has ceased to be about that. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 23 June, 2014 5:11 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 > >> > >> On 6/23/14 8:30 AM, Roni Even wrote: > >>> Hi, > >>> > >>> Looking at the discussion in RTCweb I understand that SCTP PPID=51 > >>> is for UTF-16 string and they may register with IANA a new PPID for utf-8. > >>> > >>> I understand that from the RTCweb perspective defining a general > >>> string PPID make sense. > >>> > >>> The CLUE document in table 1 calls this PPID 51 - CLUE protocol. > >> > >> We can use anything that is allowed by rtcweb for data channels. We > >> only > > need > >> a string format, and for now there is only one string format we can > > choose. If > >> another string format becomes available we could update to use that > >> one instead, or leave it as a choice. > >> > >>> The question is why we use a general string PPID and not register a > >>> SCTP ppid for CLUE? > >> > >> As I just replied in another message, then we would not be in > >> compliance > > with > >> the data channel spec, and couldn't build clue clients on top of rtcweb. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From nobody Mon Jun 23 10:20:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192691B2B81 for ; Mon, 23 Jun 2014 10:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5U_8ahcoeD9 for ; Mon, 23 Jun 2014 10:20:45 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46921B2B79 for ; Mon, 23 Jun 2014 10:20:44 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so7159232wes.26 for ; Mon, 23 Jun 2014 10:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=5SZZmKubhBV2wQzNe1tBCeBUzrdtCjcBp4VlIhUNCnY=; b=ydxG0TEfal/T5oQ4AQ2OfrWPZ++cnhWxiMTxnWFNcoNDsz1+XdcO4rcLJewUl2rQgx hwg3/DweEcQdl6YEbhwTIlul76GUX0QUxz6Ttjgrv84va3xIg5jXyJtaZtx7q1ast4RZ Gp3NVqQ22j+ra/48sqcp0fHO2332yXdPj6OLLpvzBqV3QlSo3M0VBThyTi+7SegpfgG/ NhY6WWBNW6l0rfl4l0gXt1L8I9rwZDvcpHo2S7ZSR2FNQbcGOCRpszFV0j3zHq0bhcta JyXetG7QpjEMq85arMYrtLrGlX8NXq3VLaYpCdQ8nNph0g9lpt18rlNt+JTn1w4AWWcT hB3g== X-Received: by 10.180.206.73 with SMTP id lm9mr27692254wic.54.1403544043350; Mon, 23 Jun 2014 10:20:43 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id wp6sm27407268wjb.9.2014.06.23.10.20.41 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jun 2014 10:20:42 -0700 (PDT) From: "Roni Even" To: "'Roberta Presta'" , References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A7B678.9070808@nteczone.com> <53A83D3C.5060207@unina.it> In-Reply-To: <53A83D3C.5060207@unina.it> Date: Mon, 23 Jun 2014 20:20:39 +0300 Message-ID: <040b01cf8f07$759dc290$60d947b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040C_01CF8F20.9AEC5A20" X-Mailer: Microsoft Outlook 14.0 thread-index: AQJFKbhM3XYMAHeDWEWDfRd7RrdWlAG0XYGqAdxwBnyadzPacA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/n_kYDysr8Vf8FEXdK0gFVKQcnYI Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:20:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040C_01CF8F20.9AEC5A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Roberta, Inline Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roberta Presta Sent: 23 June, 2014 5:44 PM To: clue@ietf.org Subject: Re: [clue] CLUE protocol message type comment Hi Christian, hi Roni, please see below. Il 23/06/2014 07:09, Christian Groves ha scritto: On 23/06/2014 12:50 AM, Roni Even wrote: 1.What is the purpose of the ClueId? Is this for displaying the station name? [CNG] The draft says its the identifier of the CP (CLUE participant???) within the telepresence system. I agree we need some more information about this. The purpose of the identifier is providing a unique name for the CLUE entity involved in the telepresence session at the CLUE application level. [Roni Even] Still not sure what is the usage, if we need a unique name for some purpose we need to define how to create it as a unique string If it was a displayed string than uniqueness in not an issue. It has not been conceived (necessarily) for carrying a displayable name of the CLUE entity. In the terminology section, in order to make a reference to both a CLUE endpoint and a CLUE MCU, we have introduced the term "CLUE participant" (for the sake of brevity/convenience). These are the definitions we used: CLUE Participant An entity able to use the CLUE protocol within a telepresence session. It can be an endpoint or a MCU able to use the CLUE protocol. Endpoint The logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices which source and sink media streams, and exactly one [RFC4353 ] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera room controllers to handheld devices. MCU Multipoint Control Unit (MCU) - a device that connects two or more endpoints together into one single multimedia conference [RFC5117 ]. An MCU may include a Mixer [RFC4353 ]. 2.The version (v) is defined as string, this is also the type for the version in the supported version. Being a string will make comparison in option and option response dependent on having the same string in both. For example the option can have "v1.0" while the response will be "ver 1.0", should be positive integer also in version list type. [CNG] I agree we should specify the exact version string to use. I agree we need to be more precise in the describing text. In our mind, the content of the "v" attribute would be something like "1.0" or "2.34" (without letters and with a dot separating the major version number to the minor version one). However, if we want to use a numeric content, we could split the major version number and the minor version one, by this way having the following attributes instead of the single "v" one: For the sake of brevity, we prefer the first solution with a more precise text describing the content of the "v" attribute. [Roni Even] My preference will be on numeric that can be compared and have less probability of different representations of the same value. 3.Why do we need the fixed attribute "protocol" with the vale CLUE, this is already known from the ppid (51) of the sctp channel? I assume that if we will have another transport it will include the opening of a CLUE channel. [CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" will help with identification. Given the size of the XML I don't think a few extra bytes for this is a problem. I prefer to keep it because in the future an alternative transport protocol could be defined for CLUE and in that way we do not leverage the transport channel for the identification of the application protocol. [Roni Even] OK Roberta ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITA' DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille -- ------=_NextPart_000_040C_01CF8F20.9AEC5A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roberta,

Inline

Roni

 

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roberta = Presta
Sent: 23 June, 2014 5:44 PM
To: = clue@ietf.org
Subject: Re: [clue] CLUE protocol message type = comment

 

Hi = Christian, hi Roni,

please see below.

Il 23/06/2014 07:09, = Christian Groves ha scritto:


On 23/06/2014 12:50 AM, Roni Even wrote: =


1.What is the purpose of the ClueId? = Is this for displaying the station name?

[CNG] The draft says its the identifier of the CP = (CLUE participant???) within the telepresence system. I agree we need = some more information about this.

 

The purpose of the identifier is = providing a unique name for the CLUE entity involved in the telepresence = session at the CLUE application level.

[Roni Even] Still not sure what is the usage, if we need a unique = name for some purpose we need to define how to create it as a unique = string

If it was a displayed string than uniqueness in not an = issue.


It has not been conceived = (necessarily) for carrying a displayable name of the CLUE entity.
In = the terminology section, in order to make a reference to both a CLUE = endpoint and a CLUE MCU, we have introduced the term "CLUE = participant" (for the sake of brevity/convenience).
These are = the definitions we used:

CLUE Participant  An =
entity able to use the CLUE protocol within =
a
      telepresence =
session.  It can be an endpoint or a MCU able to =
use
      the CLUE =
protocol.
 
Endpoint =
 The logical point of final termination through =
receiving,
      decoding =
and rendering, and/or initiation through =
capturing,
      encoding, =
and sending of media streams.  An endpoint consists =
of
      one or more =
physical devices which source and sink media =
streams,
      and exactly =
one [RFC4353] Participant (which, in turn, =
includes
      exactly one =
SIP User Agent).  Endpoints can be anything =
from
      =
multiscreen/multicamera room controllers to handheld =
devices.
 
MCU  =
Multipoint Control Unit (MCU) - a device that connects two =
or
      more endpoints =
together into one single multimedia =
conference
      [RFC5117].  An MCU may include a Mixer [RFC4353].
 


2.The version (v) is defined as string, = this is also the type for the version in the supported version. Being a = string will make comparison in option and option response dependent on = having the same string in both. For example the option can have = “v1.0” while the response will be “ver 1.0”, = should be positive integer also in version list type. =

[CNG] I agree we should = specify the exact version string to use.


I agree we need to be more precise in the = describing text.
In our mind, the content of the "v" = attribute would be something like "1.0" or "2.34" = (without letters and with a dot separating the major version number to = the minor version one).
However, if we want to use a numeric content, = we could split the major version number and the minor version one, by = this way having the following attributes instead of the single = "v" one:

<xs:attribute = name=3D"majorVersion" type=3D"xs:short" = use=3D"required"/>
<xs:attribute = name=3D"minorVersion" type=3D"xs:short" = use=3D"required"/>

For the sake of brevity, we = prefer the first solution with a more precise text describing the = content of the "v" attribute.

[Roni Even] My preference will be on numeric that can be compared and = have less probability of different representations of the same = value.





3.Why do we need the fixed attribute = “protocol” with the vale CLUE, this is already known from = the ppid (51) of the sctp channel? I assume that if we will have another = transport it will include the opening of a CLUE channel. =

[CNG] As Paul mentioned ppid is for = datachannel not CLUE. Having "CLUE" will help with = identification. Given the size of the XML I don't think a few extra = bytes for this is a problem.

I prefer to keep it because in the future = an alternative transport protocol could be defined for CLUE and in that = way we do not leverage the transport channel for the identification of = the application protocol.

[Roni Even] OK



Roberta



=

----
5x100= 0 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice = Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­  

=
------=_NextPart_000_040C_01CF8F20.9AEC5A20-- From nobody Mon Jun 23 10:51:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6FB1B2BDD for ; Mon, 23 Jun 2014 10:51:50 -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 4NgpEpYTQ-y3 for ; Mon, 23 Jun 2014 10:51:49 -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 CF4531B2B83 for ; Mon, 23 Jun 2014 10:50:56 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id HtRJ1o0090cZkys5CtqwGE; Mon, 23 Jun 2014 17:50:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Htqw1o00C3ZTu2S3WtqwBA; Mon, 23 Jun 2014 17:50:56 +0000 Message-ID: <53A86900.9080403@alum.mit.edu> Date: Mon, 23 Jun 2014 13:50:56 -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: Roni Even , 'CLUE' References: <53A84FC6.1040308@alum.mit.edu> <040501cf8f03$545eda50$fd1c8ef0$@gmail.com> In-Reply-To: <040501cf8f03$545eda50$fd1c8ef0$@gmail.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=1403545856; bh=mzO49QKrZF1phYLa+srCl1Y5fQC3ZYbnkaNPUNugMoQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hm+xcn6dhVWStkqho34OQgw9abkUaqkfg4WaHLqofYR7zkS1bfn8sQQLJPWiUVrPl MpBTUYUytD8PGiq75FrtI7CPFMXXlDfsEXCMFpebSwysERQKnZiQvqLKUikeqys2d/ 2eH4wcC26PdQfn30rrzY8C+RKL68eZ03K49iFQQPaMi6uPFe+NBOUOsWkfnjNXJFv0 8dtoRiVIxAgZJFSBbt07NJYDA/+puNw9Hl1QXHfV3ylmbi8DSZCAZzROnwOc3npL+p KLEXc7jX8opZzYC9p/M5ie7SGEmj3Q96/RDB60Sj1aI5S3Ds0KyZEsm39RjmwwlCf6 f0iKHGQpM49FA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/CwNWt7sDYLiVujnGSMlHiEf5-ko Subject: Re: [clue] Design Team meeting Tuesday June 24 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:51:50 -0000 On 6/23/14 12:51 PM, Roni Even wrote: > Paul, > I submitted a document yesterday > http://www.ietf.org/id/draft-even-clue-call-flows-00.txt Thank you. I will read it. > I also sent an email to the list about it I don't know what happened, but I cannot find any mail from you in the last two days on this. I even looked in the clue email archive. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 23 June, 2014 7:03 PM >> To: CLUE >> Subject: [clue] Design Team meeting Tuesday June 24 >> >> The design team meeting tomorrow was scheduled for discussion of the >> planned call flows document. >> >> To date we haven't had a submission for that yet, though I know Roni has > one in >> the works. >> >> Even in the absence of a document, let's have the call tomorrow, to > discuss >> what sort of content we want to see in it - level of detail, number and >> complexity of cases covered, etc. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Jun 23 10:55:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DFD1B27C8 for ; Mon, 23 Jun 2014 10:55:17 -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 MQMhxVYbdSZO for ; Mon, 23 Jun 2014 10:55:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 08FF41B2B83 for ; Mon, 23 Jun 2014 10:55:15 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id HtfF1o0050ldTLk5FtvFpt; Mon, 23 Jun 2014 17:55:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id HtvF1o00C3ZTu2S01tvFpY; Mon, 23 Jun 2014 17:55:15 +0000 Message-ID: <53A86A03.7090004@alum.mit.edu> Date: Mon, 23 Jun 2014 13:55:15 -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: Roni Even , clue@ietf.org References: <03d301cf8ede$f2961640$d7c242c0$@gmail.com> <53A8356F.70806@alum.mit.edu> <03ee01cf8ef3$4fc6a7d0$ef53f770$@gmail.com> <53A84BE4.1000001@alum.mit.edu> <040a01cf8f06$59c6cbd0$0d546370$@gmail.com> In-Reply-To: <040a01cf8f06$59c6cbd0$0d546370$@gmail.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=1403546115; bh=UgkjZYjRVZlbb9/ETTxKqpZ85YcNNihFOA+KaUz5/xE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rq6ZVbabSa+I5WwobQmI3Uo89SXlFSSlMc5f9qxp5GOw/MzxfXp5VL75WUbTeWLWU VIgSU/TSpsD7vuNl1sH26ptwcCQqNU5R7klQlej0VYBP6iaacSAH7ytWp8RiKSGYBX 9szt2ay5FbqDttnyIVRIB81MQWy50SxI590uFMP3x3Jp2gY36qfEl3oGAh9t/qC3h5 ZusUVinfGNkBTMFNNqzUa2iiV61F9VnRxkaSc1/2+6kvKYX0qbNbHEPMeNsj6DpFRf ENpg0Jc48HpSh2YCqZOTXK021YpEXh0sqzpCd3Ovg3dB+Pt8Gl6SoQ0ijzcJCcwQl8 Kj2BHuKhCJ5cQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/H7pXT3btwEUX2B6AJVgNxA-y5k8 Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:55:17 -0000 On 6/23/14 1:12 PM, Roni Even wrote: > Hi Paul, > Looking at the discussion about ppid in the RTCweb mailing list I got the > following points > 1. The application have no control on the PPID so we MUST use the ones > specified by webrtc and do the right conversions > 2. The current DOMstring PPID=51 is specified as UTF-16 string and I think > that the current approach will be to define a new PPID for UTF-8 string > possibly also not to name it as DOMstring but utf-8 string > > Is this correct? It is consistent with my understanding. I don't know for sure whether the UTF-8 is intended to *replace* UTF-16, or is to another alternative. My recollection from discussions in London is that it was intended, at least in the long term, to replace. But I expect they have a migration issue since there are implementations deployed. Thanks, Paul > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 23 June, 2014 6:47 PM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 >> >> On 6/23/14 10:56 AM, Roni Even wrote: >>> Paul, >>> I am OK with the current approach but I am not sure that the reasons >>> you give prevent using different PPID >>> >>> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section- >>> 6.6 >>> says >>> >>> "The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the >>> interpretation of the "Payload data". For identifying a JavaScript >>> string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for >>> JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC > Binary" >>> MUST be used (see Section 8)." >>> >>> We are not sending a JavaScript string so it is not clear that we >>> cannot send a CLUE XML based message using a different PPID (not 51). >> >> My understanding (may be wrong) is that the browser implementation of the >> data channel will determine what PPID to use based on the javascript > datatype >> used to provide the payload to the API. The javascript application won't > have >> direct control over the PPID. >> >>> I am not too familiar with Java script so I was wondering if we will >>> need to do XML to string to send a clue message and string to XML when >>> receiving a CLUE message? At least I saw such methods in java script. >> >> I'm not sure either, but I assume either that conversion will either be > done >> explicitly or implicitly via coercion during the call to the API. >> >>> Still your major point is that if we use WebRTC string ppid is will be >>> interoperable in webrtc environment, I do not see the problem since >>> both sides need to support CLUE anyhow so they can have any PPID if >>> the rtcweb data channel document does not prevent it. >> >> If the rtcweb allows explicit control of the PPID and use of any PPID > value then I >> agree. I don't think that is the case. (Where is the actual javascript > data >> channel API specification?) >> >>> Again we can keep the "CLUE" protocol in the CLUE message header. >> >> Sure. Clearly the discussion has ceased to be about that. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 23 June, 2014 5:11 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00 >>>> >>>> On 6/23/14 8:30 AM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> Looking at the discussion in RTCweb I understand that SCTP PPID=51 >>>>> is for UTF-16 string and they may register with IANA a new PPID for > utf-8. >>>>> >>>>> I understand that from the RTCweb perspective defining a general >>>>> string PPID make sense. >>>>> >>>>> The CLUE document in table 1 calls this PPID 51 - CLUE protocol. >>>> >>>> We can use anything that is allowed by rtcweb for data channels. We >>>> only >>> need >>>> a string format, and for now there is only one string format we can >>> choose. If >>>> another string format becomes available we could update to use that >>>> one instead, or leave it as a choice. >>>> >>>>> The question is why we use a general string PPID and not register a >>>>> SCTP ppid for CLUE? >>>> >>>> As I just replied in another message, then we would not be in >>>> compliance >>> with >>>> the data channel spec, and couldn't build clue clients on top of > rtcweb. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> > > From nobody Mon Jun 23 11:37:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8801B2CD2 for ; Mon, 23 Jun 2014 11:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oooi7iZhzNtF for ; Mon, 23 Jun 2014 11:37:13 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9850D1B2CBB for ; Mon, 23 Jun 2014 11:35:50 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so7426090wes.41 for ; Mon, 23 Jun 2014 11:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Qinjpkdgw4zeyepzGUplvhfkpV7qly8pLgc1PXz+GUA=; b=SNZfCBLYZB/1n1CLYxr+HBHeDR6BbiGlhBZDio7R4ymy6vosL9j2ZNFcUPyMmhM0mV prvYj675yZsF2fXrMfkFO740t/sS41LE6OGQ9Zx6nbFihPTFqUfi71bWzXIHQPGzhmwZ lDZjxQ6v8Vdqm0i2wB6BDa/ONFMZ4ZJLCwm86BIuFQBVgqPqjsS3sdXc+iHZFU7gPnTu bZ/s64G9Zsaet4rgp7B8MSHRrqajOgZMryZzPkkl4+857kBip1zmafaVqG00aBQZ8aEu PCudMlXoH4XA5Bg1gcD6E9wNw6Bxw+GgQCzIOBGdMSLjP3DyG1YLMpFAIPyo9V0MY5OI /vrQ== MIME-Version: 1.0 X-Received: by 10.180.36.225 with SMTP id t1mr12755333wij.38.1403548549208; Mon, 23 Jun 2014 11:35:49 -0700 (PDT) Received: by 10.217.116.201 with HTTP; Mon, 23 Jun 2014 11:35:49 -0700 (PDT) In-Reply-To: <20140623183123.30660.5975.idtracker@ietfa.amsl.com> References: <20140623183123.30660.5975.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 13:35:49 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8f642c9ab35fc404fc851cc9 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sQ7u0sJK2Y0w0wZyC-2gJj5Huys Subject: [clue] Fwd: clue - Requested sessions have been scheduled for IETF 90 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:37:15 -0000 --e89a8f642c9ab35fc404fc851cc9 Content-Type: text/plain; charset=UTF-8 It's not at all what we would have liked. But it seems it's the best that could be managed this time around. ---------- Forwarded message ---------- From: *"IETF Secretariat"* Date: Monday, June 23, 2014 Subject: clue - Requested sessions have been scheduled for IETF 90 To: mary.ietf.barnes@gmail.com Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (2:00:00) Monday, Afternoon Session II 1520-1650 Room Name: Salon A size: 75 --------------------------------------------- clue Session 2 (2:00:00) Tuesday, Morning Session I 0900-1130 Room Name: Manitoba size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: ControLling mUltiple streams for tElepresence Area Name: Real-time Applications and Infrastructure Area Session Requester: Mary Barnes Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: dispatch xrblock xmpp siprec sipcore straw rtcweb payload mmusic insipid geopriv ecrit bfcpbis avtext avtcore rmcat stir Second Priority: drinks soc p2psip Special Requests: --------------------------------------------------------- --e89a8f642c9ab35fc404fc851cc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's not at all what we would have liked. =C2=A0But it see= ms it's the best that could be managed this time around.=C2=A0

-= --------- Forwarded message ----------
From: "IETF Secretariat&q= uot; <agenda@ietf.org>
Date: Monday, June 23, 2014
Subject: clue - Requested sessions have been= scheduled for IETF 90
To: mary.ietf.barnes@gmail.com
Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu


Dear Mary Barnes,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

clue Session 1 (2:00:00)
=C2=A0 =C2=A0 Monday, Afternoon Session II 1520-1650
=C2=A0 =C2=A0 Room Name: Salon A size: 75
=C2=A0 =C2=A0 ---------------------------------------------
=C2=A0 =C2=A0 clue Session 2 (2:00:00)
=C2=A0 =C2=A0 Tuesday, Morning Session I 0900-1130
=C2=A0 =C2=A0 Room Name: Manitoba size: 75
=C2=A0 =C2=A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name: ControLling mUltiple streams for tElepresence
Area Name: Real-time Applications and Infrastructure Area
Session Requester: Mary Barnes

Number of Sessions: 2
Length of Session(s): =C2=A02 Hours, 2 Hours
Number of Attendees: 40
Conflicts to Avoid:
=C2=A0First Priority: dispatch xrblock xmpp siprec sipcore straw rtcweb pay= load mmusic insipid geopriv ecrit bfcpbis avtext avtcore rmcat stir
=C2=A0Second Priority: drinks soc p2psip



Special Requests:

---------------------------------------------------------


--e89a8f642c9ab35fc404fc851cc9-- From nobody Mon Jun 23 12:11:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FBD1B2C18 for ; Mon, 23 Jun 2014 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=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 BhmxCK6sEh7F for ; Mon, 23 Jun 2014 12:11:14 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 812941B2C0B for ; Mon, 23 Jun 2014 12:11:10 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta08.westchester.pa.mail.comcast.net with comcast id HqT91o00117dt5G58vBAXm; Mon, 23 Jun 2014 19:11:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id HvB91o00p3ZTu2S3ZvB92u; Mon, 23 Jun 2014 19:11:10 +0000 Message-ID: <53A87BCD.5000801@alum.mit.edu> Date: Mon, 23 Jun 2014 15:11: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: Roni Even 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=1403550670; bh=fwvAg8rDQDPuJ/Q98NexLxFLv2WbI3wdNG5fesxlx+s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cKRBZOSAB0Lj6nfSMxq3mXF6WLcYPlTf13v5CkStCq5s2AMlufOoRctqtlPQMYYHy 1EX3cMz0EsFTNFKLqWllSXwzG0LIRkjnroel2eBd57MsRS5qZyextde5/by7i/4iFn u9BUioYTmV90JIqfjp2e35Qzwl9NQhvtUpp5bxrEiyl1aofUShOdbdSLS2ubmvvHHm ghey4k7BReh4AUonbvcJ52I/oUCWk/i306PUUKxj+hk0rlOGq+GFYPvSmDdaQBjxHd ByoyTD9EUxk/gATxQfWfiKAoM2xC62jq8XbFgSzYUL6IkEbz9wCWSFkDDcSjiTeSAR y1zsENbeH8XzA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/umV67eQThS1VW9fuoC_GX2KuxpU Cc: CLUE Subject: [clue] Initial comments on draft-even-clue-call-flows-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:11:20 -0000 My most general observation - you ask: Question: do we want full XML for CLUE messages or just pseudo code providing the parameters? Good question. IMO using XML will make the call flows hard to write and hard to read - the essential features get buried in a mass of uninteresting detail. OTOH, if we use pseudo-code then we run the risk of being imprecise and accidentally leaving out essential detail. If we go with pseudo-code then we had better agree on what it will be. After the option exchange, what is shown is: -> ADV <- CFG -> CFG Resp <- ADV -> CFG <- CFG Resp I think this is not a reasonable sequence without some intervening O/As. In particular, an offer with the encodings needs to be received before a CFG can be sent. Also, there are multiple valid sequences. For instance, Alice and Bob may send ADV more or less simultaneously. IMO we ought to show multiple possibilities, while recognizing that we can't show them all. But showing alternatives can also get tedious to write and read if done in full detail. I suspect we need a way to show these things at various levels of detail. For instance show sequences of clue messages with no detail (like I just did above) as alternative ways that things might transpire. And then pick one of those to show in more detail - showing the actual messages. Similarly, we might at a high level simply show where offers and answers are being sent, and then detail out some of them. This might work for the content of clue messages too - mostly use pseudo-code, but then show the expansion of one or a few pseudo-code messages into actual xml. This same principle could be used for ICE and SRTP - abbreviate or omit from most examples but expand in one or a few. The following are more detailed comments. They may be moot given the above. Section 1: The examples will not include ICE and SRTP negotiations but the actual usage SHOULD include ICE and SRTP. I think it is fine that early drafts don't worry about these. But we may want to eventually include at least one example of each. I have an open mind about this. Section 3: The Invite message doesn't have a To header. The feature tag on the Contact should be '+sip.clue', not 'CLUE'. In the SDP of the 200 ok: m=application 54100 DTLS/SCTP 54111 a=sctpmap:54100 webrtc-datachannel s/54111/54100/ In the establishment of the data channel the labeling of the messages is confusing. Is this what you mean: (This will be messed up due to proportional font): Alice Bob ClientHello --------> Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] <-------- ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data I assume the statement "The SCTP messages are carried in the DATA messages" means "The SCTP messages are carried in DTLS DATA messages". Thanks, Paul From nobody Mon Jun 23 17:47:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24F41A04FA for ; Mon, 23 Jun 2014 17:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2] 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 scvICjkehY_K for ; Mon, 23 Jun 2014 17:47:25 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D94C1A04E7 for ; Mon, 23 Jun 2014 17:47:25 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:55360 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzEsv-0006h8-6G for clue@ietf.org; Tue, 24 Jun 2014 10:46:53 +1000 Message-ID: <53A8CA98.1080404@nteczone.com> Date: Tue, 24 Jun 2014 10:47:20 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <038d01cf8e29$45bb7470$d1325d50$@gmail.com> <53A7B678.9070808@nteczone.com> <53A83D3C.5060207@unina.it> In-Reply-To: <53A83D3C.5060207@unina.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HzXznUs_SAiD32fWzxWLUcaQ5Hk Subject: Re: [clue] CLUE protocol message type comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 00:47:29 -0000 Hello Roberta, Please see below. Regards, Christian On 24/06/2014 12:44 AM, Roberta Presta wrote: > Hi Christian, hi Roni, > > please see below. > > Il 23/06/2014 07:09, Christian Groves ha scritto: >> >> On 23/06/2014 12:50 AM, Roni Even wrote: >>> >>> 1.What is the purpose of the ClueId? Is this for displaying the >>> station name? >>> >> [CNG] The draft says its the identifier of the CP (CLUE >> participant???) within the telepresence system. I agree we need some >> more information about this. >>> > The purpose of the identifier is providing a unique name for the CLUE > entity involved in the telepresence session at the CLUE application level. > It has not been conceived (necessarily) for carrying a displayable > name of the CLUE entity. [CNG] I think we probably need to describe more about the "unique name" aspect. What is the intended scope of the "uniqueness"? > In the terminology section, in order to make a reference to both a > CLUE endpoint and a CLUE MCU, we have introduced the term "CLUE > participant" (for the sake of brevity/convenience). > These are the definitions we used: > > CLUE Participant An entity able to use the CLUE protocol within a > telepresence session. It can be an endpoint or a MCU able to use > the CLUE protocol. > > Endpoint The logical point of final termination through receiving, > decoding and rendering, and/or initiation through capturing, > encoding, and sending of media streams. An endpoint consists of > one or more physical devices which source and sink media streams, > and exactly one [RFC4353 ] Participant (which, in turn, includes > exactly one SIP User Agent). Endpoints can be anything from > multiscreen/multicamera room controllers to handheld devices. > > MCU Multipoint Control Unit (MCU) - a device that connects two or > more endpoints together into one single multimedia conference > [RFC5117 ]. An MCU may include a Mixer [RFC4353 ]. > > >>> 2.The version (v) is defined as string, this is also the type for >>> the version in the supported version. Being a string will make >>> comparison in option and option response dependent on having the >>> same string in both. For example the option can have “v1.0” while >>> the response will be “ver 1.0”, should be positive integer also in >>> version list type. >>> >> [CNG] I agree we should specify the exact version string to use. > > I agree we need to be more precise in the describing text. > In our mind, the content of the "v" attribute would be something like > "1.0" or "2.34" (without letters and with a dot separating the major > version number to the minor version one). > However, if we want to use a numeric content, we could split the major > version number and the minor version one, by this way having the > following attributes instead of the single "v" one: > > > > > For the sake of brevity, we prefer the first solution with a more > precise text describing the content of the "v" attribute. [CNG] I think the first solution would be OK. From nobody Mon Jun 23 19:02:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC891A03AF for ; Mon, 23 Jun 2014 19:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=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 N-oUFMrQDbDM for ; Mon, 23 Jun 2014 19:02:00 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30921A05CB for ; Mon, 23 Jun 2014 19:01:59 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:56015 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzG34-000124-U1 for clue@ietf.org; Tue, 24 Jun 2014 12:01:27 +1000 Message-ID: <53A8DC13.4010500@nteczone.com> Date: Tue, 24 Jun 2014 12:01:55 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A87BCD.5000801@alum.mit.edu> In-Reply-To: <53A87BCD.5000801@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/p_4HBSOdvqvSuKYT0qUrBDFBuzE Subject: Re: [clue] Initial comments on draft-even-clue-call-flows-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 02:02:04 -0000 Hello Roni, Thanks for the initial draft. Some additional comments: 0. General: Perhaps we should focus on the use cases that we want to document? Do we want just the basic symmetric flow described in detail and then maybe only parts of other use cases? etc. Do we want to show unsuccessfull/error cases? Fall back case? 1. General: Would it be possible to have numbered sub-headings for the various stages in the flow. e.g. cl.3.1 Invite, cl.3.2 200OK, cl.3.3 DTLS establishment, etc. I think this would make it easier to review, comment etc. 2. Cl.3 : Should we describe what approach will be taken with the call flow. E.g. we have the option to send both the basic media and clue media in the first INVITE or to only send basic media. 3. Cl.3: Do we need the fingerprint attribute given we're doing DTLS? 4. Cl.3: Pseudo code vs XML : I think it depends what the goal of the document is? I would lean towards the XML as this gives an example of the data model and going through the exercise of writing XML will serve as a check of the data model draft. 5. Cl.3 pg 6: In the option response it uses sequenceNr=4. Is there any reason you used that number? The last configure from Alice also uses sequenceNr=4. I know this is valid from an implementation view but if you were hoping to avoid overlap in the flows there is one. 6. Cl.3 - CLUE flows seem to be missing the Advertisement ACK. Regards, Christian On 24/06/2014 5:11 AM, Paul Kyzivat wrote: > My most general observation - you ask: > > Question: do we want full XML for CLUE messages or just pseudo code > providing the parameters? > > Good question. IMO using XML will make the call flows hard to write > and hard to read - the essential features get buried in a mass of > uninteresting detail. OTOH, if we use pseudo-code then we run the risk > of being imprecise and accidentally leaving out essential detail. > > If we go with pseudo-code then we had better agree on what it will be. > > After the option exchange, what is shown is: > > -> ADV > <- CFG > -> CFG Resp > <- ADV > -> CFG > <- CFG Resp > > I think this is not a reasonable sequence without some intervening > O/As. In particular, an offer with the encodings needs to be received > before a CFG can be sent. > > Also, there are multiple valid sequences. For instance, Alice and Bob > may send ADV more or less simultaneously. > > IMO we ought to show multiple possibilities, while recognizing that we > can't show them all. But showing alternatives can also get tedious to > write and read if done in full detail. I suspect we need a way to show > these things at various levels of detail. For instance show sequences > of clue messages with no detail (like I just did above) as alternative > ways that things might transpire. And then pick one of those to show > in more detail - showing the actual messages. > > Similarly, we might at a high level simply show where offers and > answers are being sent, and then detail out some of them. > > This might work for the content of clue messages too - mostly use > pseudo-code, but then show the expansion of one or a few pseudo-code > messages into actual xml. > > This same principle could be used for ICE and SRTP - abbreviate or > omit from most examples but expand in one or a few. > > The following are more detailed comments. They may be moot given the > above. > > Section 1: > > The examples will not include ICE and SRTP negotiations but the > actual usage SHOULD include ICE and SRTP. > > I think it is fine that early drafts don't worry about these. > But we may want to eventually include at least one example of each. I > have an open mind about this. > > Section 3: > > The Invite message doesn't have a To header. > > The feature tag on the Contact should be '+sip.clue', not 'CLUE'. > > In the SDP of the 200 ok: > > m=application 54100 DTLS/SCTP 54111 > a=sctpmap:54100 webrtc-datachannel > > s/54111/54100/ > > In the establishment of the data channel the labeling of the messages > is confusing. Is this what you mean: (This will be messed up due to > proportional font): > > Alice Bob > > ClientHello --------> > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > <-------- ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > > <-------- ServerHelloDone > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > I assume the statement "The SCTP messages are carried in the DATA > messages" means "The SCTP messages are carried in DTLS DATA messages". > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 23 20:19:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D711B281B for ; Mon, 23 Jun 2014 20:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=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 WhrbCRemnvWm for ; Mon, 23 Jun 2014 20:19:50 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A3E1B2803 for ; Mon, 23 Jun 2014 20:19:50 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:56541 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzHGO-000418-OH for clue@ietf.org; Tue, 24 Jun 2014 13:19:16 +1000 Message-ID: <53A8EE51.1030705@nteczone.com> Date: Tue, 24 Jun 2014 13:19:45 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A87BCD.5000801@alum.mit.edu> <53A8DC13.4010500@nteczone.com> In-Reply-To: <53A8DC13.4010500@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HzD2L0xddczvdm4YXjR6OHdS7IM Subject: Re: [clue] Initial comments on draft-even-clue-call-flows-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 03:19:52 -0000 Just a followup to the pseudo code vs XML issue. Perhaps we can align the XML in the call flow draft with the examples provided in the data model draft (e.g. cl.22)? That way we'd only need to specify it in one place. Christian On 24/06/2014 12:01 PM, Christian Groves wrote: > Hello Roni, > > Thanks for the initial draft. > > Some additional comments: > 0. General: Perhaps we should focus on the use cases that we want to > document? Do we want just the basic symmetric flow described in detail > and then maybe only parts of other use cases? etc. Do we want to show > unsuccessfull/error cases? Fall back case? > > 1. General: Would it be possible to have numbered sub-headings for the > various stages in the flow. e.g. cl.3.1 Invite, cl.3.2 200OK, cl.3.3 > DTLS establishment, etc. I think this would make it easier to review, > comment etc. > > 2. Cl.3 : Should we describe what approach will be taken with the call > flow. E.g. we have the option to send both the basic media and clue > media in the first INVITE or to only send basic media. > > 3. Cl.3: Do we need the fingerprint attribute given we're doing DTLS? > > 4. Cl.3: Pseudo code vs XML : I think it depends what the goal of the > document is? I would lean towards the XML as this gives an example of > the data model and going through the exercise of writing XML will > serve as a check of the data model draft. > > 5. Cl.3 pg 6: In the option response it uses sequenceNr=4. Is there > any reason you used that number? The last configure from Alice also > uses sequenceNr=4. I know this is valid from an implementation view > but if you were hoping to avoid overlap in the flows there is one. > > 6. Cl.3 - CLUE flows seem to be missing the Advertisement ACK. > > Regards, Christian > > On 24/06/2014 5:11 AM, Paul Kyzivat wrote: >> My most general observation - you ask: >> >> Question: do we want full XML for CLUE messages or just pseudo code >> providing the parameters? >> >> Good question. IMO using XML will make the call flows hard to write >> and hard to read - the essential features get buried in a mass of >> uninteresting detail. OTOH, if we use pseudo-code then we run the >> risk of being imprecise and accidentally leaving out essential detail. >> >> If we go with pseudo-code then we had better agree on what it will be. >> >> After the option exchange, what is shown is: >> >> -> ADV >> <- CFG >> -> CFG Resp >> <- ADV >> -> CFG >> <- CFG Resp >> >> I think this is not a reasonable sequence without some intervening >> O/As. In particular, an offer with the encodings needs to be received >> before a CFG can be sent. >> >> Also, there are multiple valid sequences. For instance, Alice and Bob >> may send ADV more or less simultaneously. >> >> IMO we ought to show multiple possibilities, while recognizing that >> we can't show them all. But showing alternatives can also get tedious >> to write and read if done in full detail. I suspect we need a way to >> show these things at various levels of detail. For instance show >> sequences of clue messages with no detail (like I just did above) as >> alternative ways that things might transpire. And then pick one of >> those to show in more detail - showing the actual messages. >> >> Similarly, we might at a high level simply show where offers and >> answers are being sent, and then detail out some of them. >> >> This might work for the content of clue messages too - mostly use >> pseudo-code, but then show the expansion of one or a few pseudo-code >> messages into actual xml. >> >> This same principle could be used for ICE and SRTP - abbreviate or >> omit from most examples but expand in one or a few. >> >> The following are more detailed comments. They may be moot given the >> above. >> >> Section 1: >> >> The examples will not include ICE and SRTP negotiations but the >> actual usage SHOULD include ICE and SRTP. >> >> I think it is fine that early drafts don't worry about these. >> But we may want to eventually include at least one example of each. I >> have an open mind about this. >> >> Section 3: >> >> The Invite message doesn't have a To header. >> >> The feature tag on the Contact should be '+sip.clue', not 'CLUE'. >> >> In the SDP of the 200 ok: >> >> m=application 54100 DTLS/SCTP 54111 >> a=sctpmap:54100 webrtc-datachannel >> >> s/54111/54100/ >> >> In the establishment of the data channel the labeling of the messages >> is confusing. Is this what you mean: (This will be messed up due to >> proportional font): >> >> Alice Bob >> >> ClientHello --------> >> Certificate* >> ClientKeyExchange >> CertificateVerify* >> [ChangeCipherSpec] >> <-------- ServerHello >> Certificate* >> ServerKeyExchange* >> CertificateRequest* >> >> <-------- ServerHelloDone >> Finished --------> >> [ChangeCipherSpec] >> <-------- Finished >> Application Data <-------> Application Data >> >> I assume the statement "The SCTP messages are carried in the DATA >> messages" means "The SCTP messages are carried in DTLS DATA messages". >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jun 23 20:28:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327661B27C5 for ; Mon, 23 Jun 2014 20:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 Por5sdXSj5iA for ; Mon, 23 Jun 2014 20:28:35 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D351B281B for ; Mon, 23 Jun 2014 20:28:34 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:56603 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzHOr-0005Ys-9Q for clue@ietf.org; Tue, 24 Jun 2014 13:28:01 +1000 Message-ID: <53A8F05E.6080902@nteczone.com> Date: Tue, 24 Jun 2014 13:28:30 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/iU_--hT9aS1zaExndC-Kvl7K0Fk Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 03:28:38 -0000 Hello Roberta, all, Please find attached some comments on the draft. Summary: I think its in good shape. Obviously aligning with the framework is the main issue. I think the other issue that needs to be addressed is how to update data model in the future? What method/process do we need? Do we need to register updated attribute values with IANA etc? Specific comments: ================== - Cl.1 Do we need to provide some link to the CLUE protocol document? i.e. the XML schema is used by the protocol messages defined in draft-ietf-clue-protocol. - Cl.1 3rd para: The paragraph sounds like a proposal. I would propose to reword along the lines of: "This document defines a structure for information associated with the description of a telepresence scenario." - Cl.2: I think it would be good to separate terms from the framework vs ones introduced in this document. i.e. the introduction sounds that the terms all come from the framework. CLUE participant however isn't defined by the framework. I haven't checked which other terms are different. - Cl.3 1st para: Can remove "proposed", e.g. "This section contains the CLUE data ...." - Cl.3 2nd para: "... given the Provider's offer." Does this relate to a SIP offer or CLUE advertisement? Maybe we could more CLUE specific language "... given the Provider's Advertisement." - Cl.10 : This still contains the composed and switched elements (also applies to cl.3, cl.10.8, cl.10.9). These were removed from the framework so should be removed here. - Cl.10.2: "Each each media capture must be associated with one and only one capture scene", how about when the media capture is used in an MCC? May it would be better to say "Each media capture must be defined in one and only one capture but may be referenced by other scenes through multiple content captures" or similar. - Cl.10.4: I guess this would need to be updated to take into account that there's no capture area information associated with audio captures? - Cl.10.7: "...coming from the same room endpoint". I propose to remove "room". - Cl.10.11: MaxCaptures needs to be updated to reflect to "<=" and "=" constructs added to the framework. - Cl.10.16/General: There a reference to CLUE framework for a definition of the behaviour of an element. However there's no references for other elements. In general should we provide a reference to the section in the framework that describes the attribute? - General: Do we need a statement about whether the framework or the data model takes precedence regarding the definition of attributes? - General: Do we need some text regarding how to extend the data model? e.g. what do I need to do if I want to add another value to the presentationType. - Cl.10.21: I'm OK with the proposal. - Cl.11: This needs to be updated to align with the framework regarding the new audio parameters. - Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"? - Cl.15.3: Do we need the mediaType attribute if mediaType is also an attribute of the referenced media captures? We don't have a mediaType for STSs. - Cl.18 : Is "mediaType" required when "globalSceneEntryID" isn't included? - Cl.19.1 : "Such an element currently provides at least the vcard of the person (via the element, see Section 19.1.2) and optionally his conference role(s)." I think that these are independent. The person Type may be provided without the need to provide a vCard. There's no dependency in the framework. - Cl.19.1.2: This clause makes reference to ietf-ecrit-additional-data for the Xcard XML schema. What's the purpose of this? I thought a reference to the Xcard RFC 6351 is sufficient however the definitions of XML schemas is still a mystery. - Cl.20: "A possible solution to model...", I think we could strike that sentence. I think we are defining "the" method. Regards, Christian On 21/06/2014 1:41 AM, Mary Barnes wrote: > Per the schedule on the wiki, we are starting a pre-WGLC on the data > model document: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ > > The objective of this pre-WGLC review is for folks to take a fresh > look at the document and re-review the entire document. If you missed > the design team meeting on June 10th, you might also find it helpful > to look at the minutes/presentation for some background: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140610.txt > > There are currently two open issues against this document in the tracker: > #35: Consistency between framework and data model > #48: Linking participant Information with Participant Type > > This review is intended to ensure that there are no other outstanding > issues so that once we close the above open issues the document is > ready for WGLC. > > Note, reviews that provide a general summary and then separate the > major and minor issues from the editorial nits, something like the > following, would be quite helpful. > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > Major issues: > > Minor Issues: > > Editorial nits: > > Please review and send any comments to the mailing list no later than > Friday, July 4th, 2014. > > Thanks, > Mary. > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 24 03:41:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9861B28D2 for ; Tue, 24 Jun 2014 03:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm9-XNKXU83p for ; Tue, 24 Jun 2014 03:40:59 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41001B28BC for ; Tue, 24 Jun 2014 03:40:58 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-b2-53a955b81a16 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.2C.28642.8B559A35; Tue, 24 Jun 2014 12:40:56 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 12:40:56 +0200 From: Bo Burman To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] more taxonomy Thread-Index: Ac9u8GFqVUnsOP5fTpiqTclwzPXLpgayvGAAABlQ6PAAo/Zb0ACMTTMAACsN5YA= Date: Tue, 24 Jun 2014 10:40:55 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@CRPMBOXPRD08.polycom.com> <539F9AD2.4040508@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF3F7@CRPMBOXPRD08.polycom.com> <53A83E98.5020304@alum.mit.edu> In-Reply-To: <53A83E98.5020304@alum.mit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6O0JXBBuvOW1vsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGjr49bAXbFCt2b7JvYNwi1cXIySEhYCKx f8EnFghbTOLCvfVsXYxcHEICRxklrpz/xwrhLGGU+PFmPSNIFZuAhsT8HXfBbBEBT4kdH6cw g9jCAooSt9b9ZYGIK0k8OLMHyvaTON+4hw3EZhFQldhxp50dxOYV8JWY0voMasFcJolT5z+A FXEK6EicmdIHNpRRQFbi/vd7YIOYBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj0Eu5QCylSSmbU2D KNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUBI8sqRtHi1OLi3HQj I73Uoszk4uL8PL281JJNjMA4Objlt9UOxoPPHQ8xCnAwKvHwKmSvCBZiTSwrrsw9xCjNwaIk zrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYz5hfJef614/vwW/x546kFv854U3n8f /VSVLl2WvHeqUWLJjdJa/gvzxdhf1jm9mKqhViGbsVey8R9P2iZjf+kjtY1n1cpeXHhsfiVv 5zZLl3dP/MKTfj+QEjl6KemoxYMyz7n1n6oii7MZ7219Pjv3LlPGmoOvWAN0ozWU3fM9dgv9 8FqXXKjEUpyRaKjFXFScCACa65OwdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5i5Nl67nG9Fgb5tUMsAWkACax_4 Subject: Re: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:41:01 -0000 Responses inline > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 23 juni 2014 16:50 > To: clue@ietf.org > Subject: Re: [clue] more taxonomy ...snip... > >>>> CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest > >> add > >>>> this to taxonomy draft) > >>>> > >>> [CNG] I think its similar but not the same. A CLUE capture encoding > >>> does result in an encoded stream but due to the link with a CLUE > >>> media > >> capture ID there is also semantic information that is associated with > >> the encoded stream. > >> [BoB] OK. I get a feeling that the CLUE capture encoding term is (at > >> least in the CLUE framework) mostly used to describe an Encoded > >> Stream, but is sometimes also used to denote the Media Encoder > >> transformation and the result is then (correctly) described as a > >> Stream. Am I correct? If so, do you want to change that "duality" of > >> capture encoding, or do you rather prefer that I just reflect this fac= t in the Taxonomy? > > [Duckworth, Mark] I still think a Capture Encoding is the same as an En= coded Stream. Yes, there is a link to the semantic > information, but still it is an Encoded Stream. I don't think Capture En= coding refers to the media encoder transformation. > It is the output of the transformation, which is the Encoded Stream. >=20 > I think it is more-or-less correct. >=20 > There is a question of whether we want to dig into the distinction betwee= n the names of things and the things that are > named. >=20 > Specifically, the Configure message describes Capture Encodings that are = being requested. But those don't exist as > Encoded Streams until the Configure is received by the provider and acted= upon. >=20 > But I don't think we need to worry about that level of distinction. >=20 [BoB] OK. Agree that we don't need that level of distinction in Taxonomy. I= 'll list Capture Encoding as an Encoded Stream related to CLUE specific sem= antic information. ...snip... (will respond to End Point discussion in a separate mail) > >>>> CLUE MCU: includes multiple taxonomy End Points and a Participant > >>>> for each conference. > >>>> > >>> [CNG] Yes > >> [BoB] You mean the MCU itself is a Participant in each conference and > >> as such also includes multiple End Points per conference, right? >=20 > I'm don't understand the question. What do you mean by "each conference"? >=20 > Are you thinking of the MCU as a server that supports multiple concurrent= clue conferences? [BoB] I was. >=20 > Or is an MCU an abstraction for the resources supporting a single confere= nce? [BoB] No. >=20 > Of course real devices will support multiple concurrent conferences. But = should we consider those to be one MCU or > several? >=20 > This is like the distinction between a UA and a server that can host mult= iple UAs. >=20 > Right now the clue framework seems to define the MCU as supporting a sing= le conference. And I think that is probably > the right thing to do. > We don't intend to define any normative behavior that applies across mult= iple conferences in the same server, so we > don't need a term to talk about that. So having the term MCU talk about t= he support of a single conference is more > useful to us. [BoB] OK. Agree. >=20 > > [Duckworth, Mark] I think so. A CLUE MCU shouldn't be any different th= an any other MCU. The taxonomy document > doesn't mention MCU or multipoint. I suggest neither CLUE framework nor = taxonomy doc needs to add anything about > relation between MCU and End Point and Participant. >=20 > From a CLUE perspective an MCU is a type of endpoint. It is unclear to m= e whether more needs to be said about it than > that. Is there anything that an MCU does that a non-MCU endpoint would *n= ever* do? Or is it just that there are > behaviors that an MCU is more likely to do than other endpoints? >=20 > It may be useful for the Taxonomy to discuss MCUs in general. > And ideally that would indeed be consistent with the CLUE notion of MCU. [BoB] OK. I'll include a short provisional text on MCU in the Taxonomy, but= I will not make it specific to CLUE in any way. From nobody Tue Jun 24 04:06:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0A41B29C2; Tue, 24 Jun 2014 04:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g56xHskgbB_b; Tue, 24 Jun 2014 04:06:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9241B2903; Tue, 24 Jun 2014 04:06:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624110619.8847.79568.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 04:06:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GjTw-20Y31SGHQwnymgNcb39ruM Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:06:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-01.txt Pages : 50 Date : 2014-06-24 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [I-D.ietf-clue-telepresence-requirements]. The companion document [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-protocol-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 24 04:15:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B01A035B for ; Tue, 24 Jun 2014 04:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lHvGBky8VxC for ; Tue, 24 Jun 2014 04:15:01 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A861B2859 for ; Tue, 24 Jun 2014 04:15:01 -0700 (PDT) X-ASG-Debug-ID: 1403608499-05ce37177b657590001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id U9cLUcMAvnVEOYCC (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jun 2014 13:14:59 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s5OBEvKw028716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 24 Jun 2014 13:14:58 +0200 Message-ID: <53A95DB1.60801@unina.it> Date: Tue, 24 Jun 2014 13:14:57 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A46013.1060108@alum.mit.edu> X-ASG-Orig-Subj: Re: [clue] Homework - "test" of CLUE In-Reply-To: <53A46013.1060108@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------080905010107070804090101" X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1403608499 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6911 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_v15Q0R9lsHFo9sDkldfmYwdZ2I Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:15:05 -0000 This is a multi-part message in MIME format. --------------080905010107070804090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, we have just uploaded version 01 of the protocol draft with the following updates: 1. The XML schema of the ADVERTISEMENT and of the READV have been aligned with the current definitions in [I-D.ietf-clue-data-model-schema] (example of updates: --> , --> ) 2. Text has been added to clarify that, in the OPTIONS RESPONSE, when the response code is not an error response code, both and are mandatory. 3. The content of the "v" attribute and of the elements carried in the OPTIONS and OPTIONS RESPONSE messages has been described more precisely. 4. Advertisement examples have been added. The ADV examples that we have included in the protocol draft represent the situations described in Section 22 and 23 of the data model draft. They can be downloaded here: http://wpage.unina.it/spromano/CLUE/ Regards, Roberta Il 20/06/2014 18:23, Paul Kyzivat ha scritto: > During a past design team call I proposed a homework task that I > thought would be very helpful. The idea was well received, but nothing > has happened. So I'll spell it out in more detail: > > The idea is to do a "test run" of the key aspects of clue, especially > from an interoperability perspective. Specifically, I propose that, as > a first step, everybody who can represent a possible implementation of > CLUE should write down a proposed advertisement for each of their > likely device configurations, and share that with the group. (E.g., if > you have a one-screen system and a three-screen system, then provide > an advertisement for each.) > > The next step would be for each person to look at all the > advertisements other than their own, and decide if they can make sense > of each and make a good choice of what to configure, and how they > would render that on their device(s). > > Yet another step will be to extend the above to MCUs. We could pick > combinations of endpoints and ask people with MCUs to decide what they > would configure and then what they would advertise as a result. And > then people to review those advertisements as well. > > (Ideally there will be no surprises here. But what I *expect* to > happen here is that people will be surprised to find things they don't > understand and/or can't deal with in any useful way. Discussions to > clarify these would follow, and perhaps lead to some clarifications > and maybe fixes.) > > This exercise is a bit like doing call flows, but the level of detail > is different. Initially I think we only need the advertisements, and > the corresponding SDP that contains the encodings. The advertisements > could be encoded according to the message syntax in the protocol > document, but for simplicity I think people can take liberties and use > informal shorthand, as long as they include all the pieces. > > This is extra work for everybody, so I'd like to make it as easy as > possible. One possibility is for people to submit contributions via > email and then collate them into an individual draft. (I am willing to > do the collation.) Or we could do this on the CLUE Wiki. (The Wiki > might be easier.) Your thoughts on this are welcome. > > Who would be willing to participate in such an exercise? > > Thanks, > Paul > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille --------------080905010107070804090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

we have just uploaded version 01 of the protocol draft with the following updates:

  1. The XML schema of the ADVERTISEMENT and of the READV have been aligned with the current definitions in [I‑D.ietf‑clue‑data‑model‑schema] (example of updates: <participants> --> <people>, <globalCaptureEntries> --> <globalSceneEntries>)
  2. Text has been added to clarify that, in the OPTIONS RESPONSE, when the response code is not an error response code, both <mediaProvider> and <mediaConsumer> are mandatory.
  3. The content of the "v" attribute and of the <version> elements carried in the OPTIONS and OPTIONS RESPONSE messages has been described more precisely.
  4. Advertisement examples have been added.


The ADV examples  that we have included in the protocol draft represent the situations described in Section 22 and 23 of the data model draft.
They can be downloaded here:

http://wpage.unina.it/spromano/CLUE/


Regards,

Roberta






Il 20/06/2014 18:23, Paul Kyzivat ha scritto:
During a past design team call I proposed a homework task that I thought would be very helpful. The idea was well received, but nothing has happened. So I'll spell it out in more detail:

The idea is to do a "test run" of the key aspects of clue, especially from an interoperability perspective. Specifically, I propose that, as a first step, everybody who can represent a possible implementation of CLUE should write down a proposed advertisement for each of their likely device configurations, and share that with the group. (E.g., if you have a one-screen system and a three-screen system, then provide an advertisement for each.)

The next step would be for each person to look at all the advertisements other than their own, and decide if they can make sense of each and make a good choice of what to configure, and how they would render that on their device(s).

Yet another step will be to extend the above to MCUs. We could pick combinations of endpoints and ask people with MCUs to decide what they would configure and then what they would advertise as a result. And then people to review those advertisements as well.

(Ideally there will be no surprises here. But what I *expect* to happen here is that people will be surprised to find things they don't understand and/or can't deal with in any useful way. Discussions to clarify these would follow, and perhaps lead to some clarifications and maybe fixes.)

This exercise is a bit like doing call flows, but the level of detail is different. Initially I think we only need the advertisements, and the corresponding SDP that contains the encodings. The advertisements could be encoded according to the message syntax in the protocol document, but for simplicity I think people can take liberties and use informal shorthand, as long as they include all the pieces.

This is extra work for everybody, so I'd like to make it as easy as possible. One possibility is for people to submit contributions via email and then collate them into an individual draft. (I am willing to do the collation.) Or we could do this on the CLUE Wiki. (The Wiki might be easier.) Your thoughts on this are welcome.

Who would be willing to participate in such an exercise?

    Thanks,
    Paul



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





----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­   --------------080905010107070804090101-- From nobody Tue Jun 24 04:39:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB51A0652 for ; Tue, 24 Jun 2014 04:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwDyBMSFzeWk for ; Tue, 24 Jun 2014 04:39:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2603D1A0294 for ; Tue, 24 Jun 2014 04:39:10 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-5a-53a9635c96d1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.FC.16420.C5369A35; Tue, 24 Jun 2014 13:39:09 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 13:39:08 +0200 From: Bo Burman To: Paul Kyzivat , "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: Endpoint and taxonomy End Point - RE: [clue] more taxonomy Thread-Index: Ac+O9b8zPxK4p/OASzySGxPEKdHutf//6I2A//6iUjA= Date: Tue, 24 Jun 2014 11:39:07 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F012EF4B4@CRPMBOXPRD08.polycom.com> <53A84CA7.3090305@alum.mit.edu> In-Reply-To: <53A84CA7.3090305@alum.mit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW5s8spgg29TuS32n7rMbLHuyFNm ixUbDrA6MHv8ff+ByWPJkp9MHi8eKAUwR3HZpKTmZJalFunbJXBltL/NLPgpWvGucytrA+Mq wS5GTg4JAROJ9jUd7BC2mMSFe+vZuhi5OIQEjjJKPLyzmBnCWcIosWf9RTaQKjYBDYn5O+4y gtgiAtUSP3aeB+sWFnCXeHbkHxtE3EPi9f7XzBC2lcS8uc+YQGwWAVWJm4vvgtm8Ar4S85// AarhAFpQKPHwcDFImFNAR2LJAYgxjAKyEve/32MBsZkFxCVuPZnPBHGogMSSPeeZIWxRiZeP /7GCjJEQUJKYtjUNolxHYsHuT2wQtrbEsoUQ1/AKCEqcnPmEZQKj6CwkU2chaZmFpGUWkpYF jCyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj5uCW36o7GC+/cTzEKMDBqMTDq5C9IliI NbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAGBFS6eAX8aXgx V32Kz6/pooe/uM67Wes1N5LVdttrr7Pf/HzfS9z98W5r34uEicGbrcrz/CTrmv0ExSYtZ3PT bdiS67nnrLSDTEV65h8zvvlTjx26kVF+oytpvh7zu4Tfm9bl7r03hfN/7sXC84VfWO9KHe7+ +Eo1menF3unT7jjeu3g57dxuJZbijERDLeai4kQAdMW83nsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MM7_W3jPoqY3ShpNObSWTxk1v7I Subject: Re: [clue] Endpoint and taxonomy End Point - RE: more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:39:13 -0000 Inline > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: den 23 juni 2014 17:50 > To: Duckworth, Mark; clue@ietf.org; Bo Burman > Subject: Re: Endpoint and taxonomy End Point - RE: [clue] more taxonomy >=20 > On 6/23/14 11:13 AM, Duckworth, Mark wrote: > > Hello Paul and Bo, > > > > ... snip ... > >>>>>> CLUE Endpoint: includes a taxonomy End Point and a Participant. > >>>>>> > >>>>> [CNG] Yes > >>>> [BoB] Could not a CLUE Endpoint consist of multiple End Points > >>>> (multiple entities running separate RTP stacks), or is that an > >>>> unnecessary generalization? > >>> [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point. > >>> CLUE > >> definition says "exactly one [RFC4353] Participant (which, in turn, > >> includes exactly one SIP User Agent)". I think this is all consistent= . > >> > >> I think Bo has it right. While a CLUE Endpoint has a single signaling > >> address (making it a Taxonomy Participant), it can be decomposed into > >> components that have separate RTP addresses. (E.g., one per screen.) > > > > [Duckworth, Mark] Maybe you and Bo are right. Are you saying a CLUE = Endpoint includes exactly one taxonomy > Participant, and one or more taxonomy End Points? And this is because Pa= rticipant relates to the SIP User Agent, while > End Point relates to RTP? >=20 > Yes. [BoB] Agree. >=20 > > I'm still not sure about it, from the taxonomy point of view. >=20 > I'm not certain. I defer to Bo or Jonathan. [BoB] That was at least the intent with current Taxonomy text, but I agree = that it could use a bit more clarification. I will add that. >=20 > Thanks, > Paul >=20 > > The Taxonomy says a single End Point can have multiple CNAMEs for diffe= rent synchronization contexts. A CLUE > Endpoint (or even a non-CLUE disaggregated endpoint) can have separate RT= P addresses, but could use the same > CNAME for the same synchronization context. Is this consistent with taxo= nomy document calling these separate RTP > addresses as separate End Points associated with the same Participant? [BoB] Yes, but maybe not that clear. That statement related to CNAME is int= ended to highlight that CNAME is neither an ID for an End Point nor for a P= articipant, but an ID for a synchronization context. That synchronization c= ontext can be shared among a set of End Points belonging to the same Partic= ipant. Maybe that clarification is needed in the Taxonomy? =20 > > > > If that is what is intended by the Taxonomy, then would it be good to a= dd a statement in Taxonomy that a Participant > can be associated with one or more End Points? But an End Point is assoc= iated with only one Participant? [BoB] OK. Will do. > > > > Mark > > > > From nobody Tue Jun 24 04:47:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC2B1A0294 for ; Tue, 24 Jun 2014 04:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 TlXbGFW6O76f for ; Tue, 24 Jun 2014 04:46:59 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13A41A035B for ; Tue, 24 Jun 2014 04:46:58 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:51325 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzPB5-0004ER-Rd for clue@ietf.org; Tue, 24 Jun 2014 21:46:19 +1000 Message-ID: <53A9652C.7060800@nteczone.com> Date: Tue, 24 Jun 2014 21:46:52 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> In-Reply-To: <53A95DB1.60801@unina.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/UWj3sebPr196jLrkSg11qaao_nA Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:47:01 -0000 Hello Roberta, all, I have a few questions regarding the protocol draft: 1. General: Response String: In several messages the response string is listed as mandatory. If we have the response code why do we also need to send the string? 2. Clause 4.5: Do we still have a strong requirement to have ACK piggybacking in a CONFIGURE message? 3. Clause 4.8: The text indicates that the READV response contains the CLUE data. Would an alternative be to simply trigger the sending of an ADV with the CLUE data? That way we keep CLUE data in ADV and CONF only. The READV then only needs a simple ACK. I've also sent off list a number of editorial suggestions. Regards, Christian On 24/06/2014 9:14 PM, Roberta Presta wrote: > Dear all, > > we have just uploaded version 01 of the protocol draft with the > following updates: > > 1. The XML schema of the ADVERTISEMENT and of the READV have been > aligned with the current definitions in > [I‑D.ietf‑clue‑data‑model‑schema] > > (example of updates: --> , > --> ) > 2. Text has been added to clarify that, in the OPTIONS RESPONSE, when > the response code is not an error response code, both > and are mandatory. > 3. The content of the "v" attribute and of the elements > carried in the OPTIONS and OPTIONS RESPONSE messages has been > described more precisely. > 4. Advertisement examples have been added. > > > The ADV examples that we have included in the protocol draft represent > the situations described in Section 22 and 23 of the data model draft. > They can be downloaded here: > > http://wpage.unina.it/spromano/CLUE/ > > > Regards, > > Roberta > > > > > > > Il 20/06/2014 18:23, Paul Kyzivat ha scritto: >> During a past design team call I proposed a homework task that I >> thought would be very helpful. The idea was well received, but >> nothing has happened. So I'll spell it out in more detail: >> >> The idea is to do a "test run" of the key aspects of clue, especially >> from an interoperability perspective. Specifically, I propose that, >> as a first step, everybody who can represent a possible >> implementation of CLUE should write down a proposed advertisement for >> each of their likely device configurations, and share that with the >> group. (E.g., if you have a one-screen system and a three-screen >> system, then provide an advertisement for each.) >> >> The next step would be for each person to look at all the >> advertisements other than their own, and decide if they can make >> sense of each and make a good choice of what to configure, and how >> they would render that on their device(s). >> >> Yet another step will be to extend the above to MCUs. We could pick >> combinations of endpoints and ask people with MCUs to decide what >> they would configure and then what they would advertise as a result. >> And then people to review those advertisements as well. >> >> (Ideally there will be no surprises here. But what I *expect* to >> happen here is that people will be surprised to find things they >> don't understand and/or can't deal with in any useful way. >> Discussions to clarify these would follow, and perhaps lead to some >> clarifications and maybe fixes.) >> >> This exercise is a bit like doing call flows, but the level of detail >> is different. Initially I think we only need the advertisements, and >> the corresponding SDP that contains the encodings. The advertisements >> could be encoded according to the message syntax in the protocol >> document, but for simplicity I think people can take liberties and >> use informal shorthand, as long as they include all the pieces. >> >> This is extra work for everybody, so I'd like to make it as easy as >> possible. One possibility is for people to submit contributions via >> email and then collate them into an individual draft. (I am willing >> to do the collation.) Or we could do this on the CLUE Wiki. (The Wiki >> might be easier.) Your thoughts on this are welcome. >> >> Who would be willing to participate in such an exercise? >> >> Thanks, >> Paul >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > > > ---- > 5x1000 AI GIOVANI RICERCATORI > DELL'UNIVERSITA' DI NAPOLI > Codice Fiscale: 00876220633 > www.unina.it/Vademecum5permille > > ­­ > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 24 04:57:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225F51B2833 for ; Tue, 24 Jun 2014 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_61=0.6, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thX7WMirRTHp for ; Tue, 24 Jun 2014 04:57:08 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B1A1ABB90 for ; Tue, 24 Jun 2014 04:57:07 -0700 (PDT) X-ASG-Debug-ID: 1403611024-05f27516da62d380001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 9tDjgv6ZxsMJz1Da (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 13:57:04 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s5OBv1OC014754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 13:57:03 +0200 Message-ID: <53A9678D.9010603@unina.it> Date: Tue, 24 Jun 2014 13:57:01 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christian Groves References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> <53A96378.5010800@nteczone.com> X-ASG-Orig-Subj: Re: [clue] Homework - "test" of CLUE In-Reply-To: <53A96378.5010800@nteczone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1403611024 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6912 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/clue/booaM218SqICz622LraWcYogrbQ Cc: "clue@ietf.org" Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:57:12 -0000 Hello Christian, thank you for the review(s!), I'm going through it. While I was making the ADV XML samples, I noticed something needed to be changed in the protocol schema as a consequence of the changes in the data model schema (element names), so I preferred to post a new protocol draft version and to provide examples that are compliant with the updated protocol schema. I will reply to your review asap. Regards, Roberta Il 24/06/2014 13:39, Christian Groves ha scritto: > Hello Roberta, > > I just finished reviewing v0 when you posted v1 of the protocol. I > have a few editorial update suggestions which I've marked up in the > attached word document. I thought it would be easier to send a marked > up form rather than trying to explain them via email. There's also a > few word comments which I can raise on the mailing list. They're > against the v0 version but I think most of them are valid for v1. > > Regards, Christian > > On 24/06/2014 9:14 PM, Roberta Presta wrote: >> Dear all, >> >> we have just uploaded version 01 of the protocol draft with the >> following updates: >> >> 1. The XML schema of the ADVERTISEMENT and of the READV have been >> aligned with the current definitions in >> [I‑D.ietf‑clue‑data‑model‑schema] >> >> (example of updates: --> , >> --> ) >> 2. Text has been added to clarify that, in the OPTIONS RESPONSE, when >> the response code is not an error response code, both >> and are mandatory. >> 3. The content of the "v" attribute and of the elements >> carried in the OPTIONS and OPTIONS RESPONSE messages has been >> described more precisely. >> 4. Advertisement examples have been added. >> >> >> The ADV examples that we have included in the protocol draft >> represent the situations described in Section 22 and 23 of the data >> model draft. >> They can be downloaded here: >> >> http://wpage.unina.it/spromano/CLUE/ >> >> >> Regards, >> >> Roberta >> >> >> >> >> >> >> Il 20/06/2014 18:23, Paul Kyzivat ha scritto: >>> During a past design team call I proposed a homework task that I >>> thought would be very helpful. The idea was well received, but >>> nothing has happened. So I'll spell it out in more detail: >>> >>> The idea is to do a "test run" of the key aspects of clue, >>> especially from an interoperability perspective. Specifically, I >>> propose that, as a first step, everybody who can represent a >>> possible implementation of CLUE should write down a proposed >>> advertisement for each of their likely device configurations, and >>> share that with the group. (E.g., if you have a one-screen system >>> and a three-screen system, then provide an advertisement for each.) >>> >>> The next step would be for each person to look at all the >>> advertisements other than their own, and decide if they can make >>> sense of each and make a good choice of what to configure, and how >>> they would render that on their device(s). >>> >>> Yet another step will be to extend the above to MCUs. We could pick >>> combinations of endpoints and ask people with MCUs to decide what >>> they would configure and then what they would advertise as a result. >>> And then people to review those advertisements as well. >>> >>> (Ideally there will be no surprises here. But what I *expect* to >>> happen here is that people will be surprised to find things they >>> don't understand and/or can't deal with in any useful way. >>> Discussions to clarify these would follow, and perhaps lead to some >>> clarifications and maybe fixes.) >>> >>> This exercise is a bit like doing call flows, but the level of >>> detail is different. Initially I think we only need the >>> advertisements, and the corresponding SDP that contains the >>> encodings. The advertisements could be encoded according to the >>> message syntax in the protocol document, but for simplicity I think >>> people can take liberties and use informal shorthand, as long as >>> they include all the pieces. >>> >>> This is extra work for everybody, so I'd like to make it as easy as >>> possible. One possibility is for people to submit contributions via >>> email and then collate them into an individual draft. (I am willing >>> to do the collation.) Or we could do this on the CLUE Wiki. (The >>> Wiki might be easier.) Your thoughts on this are welcome. >>> >>> Who would be willing to participate in such an exercise? >>> >>> Thanks, >>> Paul >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> >> >> >> ---- >> 5x1000 AI GIOVANI RICERCATORI >> DELL'UNIVERSITA' DI NAPOLI >> Codice Fiscale: 00876220633 >> www.unina.it/Vademecum5permille >> >> ­­ >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille From nobody Tue Jun 24 06:00:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B061B2908 for ; Tue, 24 Jun 2014 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlwhosvkS5XA for ; Tue, 24 Jun 2014 06:00:43 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38E11B290A for ; Tue, 24 Jun 2014 06:00:43 -0700 (PDT) Received: from [216.82.254.20:41829] by server-7.bemta-7.messagelabs.com id B6/85-28826-B7679A35; Tue, 24 Jun 2014 13:00:43 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-2.tower-47.messagelabs.com!1403614842!13176104!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32040 invoked from network); 24 Jun 2014 13:00:42 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-2.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2014 13:00:42 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 24 Jun 2014 06:00:41 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 24 Jun 2014 06:00:40 -0700 Thread-Topic: [clue] Homework - "test" of CLUE Thread-Index: Ac+PnZCHO284SS0vStGphl+f5TalqgADj/jA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> In-Reply-To: <53A95DB1.60801@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Ai_1aLlHR0HWhGeluq8YX4fJzQ8 Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:00:48 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24CRPMBOXPRD08p_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KSeKAmWQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBhbHNvLiAgSeKAmWxsIHRyeSB0 byBwdXQgdG9nZXRoZXIgYW4gQWR2ZXJ0aXNlbWVudCBhbmQgcG9zdCBpdCBiZWZvcmUgSUVURjkw LiAgSSB3aWxsIGFsc28gbG9vayB0aHJvdWdoIFNpbW9uIGFuZCBSb2JlcnRh4oCZcyBBZHZlcnRp c2VtZW50cy4NCg0KTWFyaw0KDQpGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0YSBQcmVzdGENClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjQs IDIwMTQgNzoxNSBBTQ0KVG86IGNsdWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY2x1ZV0gSG9t ZXdvcmsgLSAidGVzdCIgb2YgQ0xVRQ0KDQpEZWFyIGFsbCwNCg0Kd2UgaGF2ZSBqdXN0IHVwbG9h ZGVkIHZlcnNpb24gMDEgb2YgdGhlIHByb3RvY29sIGRyYWZ0IHdpdGggdGhlIGZvbGxvd2luZyB1 cGRhdGVzOg0KDQogMS4gIFRoZSBYTUwgc2NoZW1hIG9mIHRoZSBBRFZFUlRJU0VNRU5UIGFuZCBv ZiB0aGUgUkVBRFYgaGF2ZSBiZWVuIGFsaWduZWQgd2l0aCB0aGUgY3VycmVudCBkZWZpbml0aW9u cyBpbiBbSeKAkUQuaWV0ZuKAkWNsdWXigJFkYXRh4oCRbW9kZWzigJFzY2hlbWFdPGh0dHA6Ly94 bWwycmZjLnRvb2xzLmlldGYub3JnL2NnaS1iaW4veG1sMnJmYy1vbGQuY2dpI0ktRC5pZXRmLWNs dWUtZGF0YS1tb2RlbC1zY2hlbWE+IChleGFtcGxlIG9mIHVwZGF0ZXM6IDxwYXJ0aWNpcGFudHM+ IC0tPiA8cGVvcGxlPiwgPGdsb2JhbENhcHR1cmVFbnRyaWVzPiAtLT4gPGdsb2JhbFNjZW5lRW50 cmllcz4pDQogMi4gIFRleHQgaGFzIGJlZW4gYWRkZWQgdG8gY2xhcmlmeSB0aGF0LCBpbiB0aGUg T1BUSU9OUyBSRVNQT05TRSwgd2hlbiB0aGUgcmVzcG9uc2UgY29kZSBpcyBub3QgYW4gZXJyb3Ig cmVzcG9uc2UgY29kZSwgYm90aCA8bWVkaWFQcm92aWRlcj4gYW5kIDxtZWRpYUNvbnN1bWVyPiBh cmUgbWFuZGF0b3J5Lg0KIDMuICBUaGUgY29udGVudCBvZiB0aGUgInYiIGF0dHJpYnV0ZSBhbmQg b2YgdGhlIDx2ZXJzaW9uPiBlbGVtZW50cyBjYXJyaWVkIGluIHRoZSBPUFRJT05TIGFuZCBPUFRJ T05TIFJFU1BPTlNFIG1lc3NhZ2VzIGhhcyBiZWVuIGRlc2NyaWJlZCBtb3JlIHByZWNpc2VseS4N CiA0LiAgQWR2ZXJ0aXNlbWVudCBleGFtcGxlcyBoYXZlIGJlZW4gYWRkZWQuDQoNClRoZSBBRFYg ZXhhbXBsZXMgIHRoYXQgd2UgaGF2ZSBpbmNsdWRlZCBpbiB0aGUgcHJvdG9jb2wgZHJhZnQgcmVw cmVzZW50IHRoZSBzaXR1YXRpb25zIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIyIGFuZCAyMyBvZiB0 aGUgZGF0YSBtb2RlbCBkcmFmdC4NClRoZXkgY2FuIGJlIGRvd25sb2FkZWQgaGVyZToNCg0KaHR0 cDovL3dwYWdlLnVuaW5hLml0L3Nwcm9tYW5vL0NMVUUvDQoNCg0KUmVnYXJkcywNCg0KUm9iZXJ0 YQ0KDQoNCklsIDIwLzA2LzIwMTQgMTg6MjMsIFBhdWwgS3l6aXZhdCBoYSBzY3JpdHRvOg0KRHVy aW5nIGEgcGFzdCBkZXNpZ24gdGVhbSBjYWxsIEkgcHJvcG9zZWQgYSBob21ld29yayB0YXNrIHRo YXQgSSB0aG91Z2h0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bC4gVGhlIGlkZWEgd2FzIHdlbGwgcmVj ZWl2ZWQsIGJ1dCBub3RoaW5nIGhhcyBoYXBwZW5lZC4gU28gSSdsbCBzcGVsbCBpdCBvdXQgaW4g bW9yZSBkZXRhaWw6DQoNClRoZSBpZGVhIGlzIHRvIGRvIGEgInRlc3QgcnVuIiBvZiB0aGUga2V5 IGFzcGVjdHMgb2YgY2x1ZSwgZXNwZWNpYWxseSBmcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgcGVy c3BlY3RpdmUuIFNwZWNpZmljYWxseSwgSSBwcm9wb3NlIHRoYXQsIGFzIGEgZmlyc3Qgc3RlcCwg ZXZlcnlib2R5IHdobyBjYW4gcmVwcmVzZW50IGEgcG9zc2libGUgaW1wbGVtZW50YXRpb24gb2Yg Q0xVRSBzaG91bGQgd3JpdGUgZG93biBhIHByb3Bvc2VkIGFkdmVydGlzZW1lbnQgZm9yIGVhY2gg b2YgdGhlaXIgbGlrZWx5IGRldmljZSBjb25maWd1cmF0aW9ucywgYW5kIHNoYXJlIHRoYXQgd2l0 aCB0aGUgZ3JvdXAuIChFLmcuLCBpZiB5b3UgaGF2ZSBhIG9uZS1zY3JlZW4gc3lzdGVtIGFuZCBh IHRocmVlLXNjcmVlbiBzeXN0ZW0sIHRoZW4gcHJvdmlkZSBhbiBhZHZlcnRpc2VtZW50IGZvciBl YWNoLikNCg0KVGhlIG5leHQgc3RlcCB3b3VsZCBiZSBmb3IgZWFjaCBwZXJzb24gdG8gbG9vayBh dCBhbGwgdGhlIGFkdmVydGlzZW1lbnRzIG90aGVyIHRoYW4gdGhlaXIgb3duLCBhbmQgZGVjaWRl IGlmIHRoZXkgY2FuIG1ha2Ugc2Vuc2Ugb2YgZWFjaCBhbmQgbWFrZSBhIGdvb2QgY2hvaWNlIG9m IHdoYXQgdG8gY29uZmlndXJlLCBhbmQgaG93IHRoZXkgd291bGQgcmVuZGVyIHRoYXQgb24gdGhl aXIgZGV2aWNlKHMpLg0KDQpZZXQgYW5vdGhlciBzdGVwIHdpbGwgYmUgdG8gZXh0ZW5kIHRoZSBh Ym92ZSB0byBNQ1VzLiBXZSBjb3VsZCBwaWNrIGNvbWJpbmF0aW9ucyBvZiBlbmRwb2ludHMgYW5k IGFzayBwZW9wbGUgd2l0aCBNQ1VzIHRvIGRlY2lkZSB3aGF0IHRoZXkgd291bGQgY29uZmlndXJl IGFuZCB0aGVuIHdoYXQgdGhleSB3b3VsZCBhZHZlcnRpc2UgYXMgYSByZXN1bHQuIEFuZCB0aGVu IHBlb3BsZSB0byByZXZpZXcgdGhvc2UgYWR2ZXJ0aXNlbWVudHMgYXMgd2VsbC4NCg0KKElkZWFs bHkgdGhlcmUgd2lsbCBiZSBubyBzdXJwcmlzZXMgaGVyZS4gQnV0IHdoYXQgSSAqZXhwZWN0KiB0 byBoYXBwZW4gaGVyZSBpcyB0aGF0IHBlb3BsZSB3aWxsIGJlIHN1cnByaXNlZCB0byBmaW5kIHRo aW5ncyB0aGV5IGRvbid0IHVuZGVyc3RhbmQgYW5kL29yIGNhbid0IGRlYWwgd2l0aCBpbiBhbnkg dXNlZnVsIHdheS4gRGlzY3Vzc2lvbnMgdG8gY2xhcmlmeSB0aGVzZSB3b3VsZCBmb2xsb3csIGFu ZCBwZXJoYXBzIGxlYWQgdG8gc29tZSBjbGFyaWZpY2F0aW9ucyBhbmQgbWF5YmUgZml4ZXMuKQ0K DQpUaGlzIGV4ZXJjaXNlIGlzIGEgYml0IGxpa2UgZG9pbmcgY2FsbCBmbG93cywgYnV0IHRoZSBs ZXZlbCBvZiBkZXRhaWwgaXMgZGlmZmVyZW50LiBJbml0aWFsbHkgSSB0aGluayB3ZSBvbmx5IG5l ZWQgdGhlIGFkdmVydGlzZW1lbnRzLCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgU0RQIHRoYXQgY29u dGFpbnMgdGhlIGVuY29kaW5ncy4gVGhlIGFkdmVydGlzZW1lbnRzIGNvdWxkIGJlIGVuY29kZWQg YWNjb3JkaW5nIHRvIHRoZSBtZXNzYWdlIHN5bnRheCBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQs IGJ1dCBmb3Igc2ltcGxpY2l0eSBJIHRoaW5rIHBlb3BsZSBjYW4gdGFrZSBsaWJlcnRpZXMgYW5k IHVzZSBpbmZvcm1hbCBzaG9ydGhhbmQsIGFzIGxvbmcgYXMgdGhleSBpbmNsdWRlIGFsbCB0aGUg cGllY2VzLg0KDQpUaGlzIGlzIGV4dHJhIHdvcmsgZm9yIGV2ZXJ5Ym9keSwgc28gSSdkIGxpa2Ug dG8gbWFrZSBpdCBhcyBlYXN5IGFzIHBvc3NpYmxlLiBPbmUgcG9zc2liaWxpdHkgaXMgZm9yIHBl b3BsZSB0byBzdWJtaXQgY29udHJpYnV0aW9ucyB2aWEgZW1haWwgYW5kIHRoZW4gY29sbGF0ZSB0 aGVtIGludG8gYW4gaW5kaXZpZHVhbCBkcmFmdC4gKEkgYW0gd2lsbGluZyB0byBkbyB0aGUgY29s bGF0aW9uLikgT3Igd2UgY291bGQgZG8gdGhpcyBvbiB0aGUgQ0xVRSBXaWtpLiAoVGhlIFdpa2kg bWlnaHQgYmUgZWFzaWVyLikgWW91ciB0aG91Z2h0cyBvbiB0aGlzIGFyZSB3ZWxjb21lLg0KDQpX aG8gd291bGQgYmUgd2lsbGluZyB0byBwYXJ0aWNpcGF0ZSBpbiBzdWNoIGFuIGV4ZXJjaXNlPw0K DQogICAgVGhhbmtzLA0KICAgIFBhdWwNCg0K --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24CRPMBOXPRD08p_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoyMTM4NDA1MTk0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjM4MjU4OTg2 O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SGkgUGF1bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPknigJlkIGxpa2UgdG8g cGFydGljaXBhdGUgYWxzby7CoCBJ4oCZbGwgdHJ5IHRvIHB1dCB0b2dldGhlciBhbiBBZHZlcnRp c2VtZW50IGFuZCBwb3N0IGl0IGJlZm9yZSBJRVRGOTAuwqAgSSB3aWxsIGFsc28gbG9vayB0aHJv dWdoIFNpbW9uIGFuZCBSb2JlcnRh4oCZcyBBZHZlcnRpc2VtZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPk1hcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9y OndpbmRvd3RleHQnPiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJvYmVydGEgUHJlc3RhPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5l IDI0LCAyMDE0IDc6MTUgQU08YnI+PGI+VG86PC9iPiBjbHVlQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2NsdWVdIEhvbWV3b3JrIC0gJnF1b3Q7dGVzdCZxdW90OyBvZiBDTFVFPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPkRlYXIgYWxsLCA8YnI+PGJyPndlIGhhdmUganVzdCB1cGxvYWRlZCB2ZXJzaW9u IDAxIG9mIHRoZSBwcm90b2NvbCBkcmFmdCB3aXRoIHRoZSBmb2xsb3dpbmcgdXBkYXRlczo8bzpw PjwvbzpwPjwvcD48b2wgc3RhcnQ9MSB0eXBlPTE+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEnPlRoZSBYTUwgc2NoZW1hIG9mIHRoZSBBRFZFUlRJU0VNRU5UIGFu ZCBvZiB0aGUgUkVBRFYgaGF2ZSBiZWVuIGFsaWduZWQgd2l0aCB0aGUgY3VycmVudCBkZWZpbml0 aW9ucyBpbiA8YSBocmVmPSJodHRwOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy9jZ2ktYmluL3ht bDJyZmMtb2xkLmNnaSNJLUQuaWV0Zi1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hIj5bSeKAkUQuaWV0 ZuKAkWNsdWXigJFkYXRh4oCRbW9kZWzigJFzY2hlbWFdPC9hPiAoZXhhbXBsZSBvZiB1cGRhdGVz OiAmbHQ7cGFydGljaXBhbnRzJmd0OyAtLSZndDsgJmx0O3Blb3BsZSZndDssICZsdDtnbG9iYWxD YXB0dXJlRW50cmllcyZndDsgLS0mZ3Q7ICZsdDtnbG9iYWxTY2VuZUVudHJpZXMmZ3Q7KSA8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn PlRleHQgaGFzIGJlZW4gYWRkZWQgdG8gY2xhcmlmeSB0aGF0LCBpbiB0aGUgT1BUSU9OUyBSRVNQ T05TRSwgd2hlbiB0aGUgcmVzcG9uc2UgY29kZSBpcyBub3QgYW4gZXJyb3IgcmVzcG9uc2UgY29k ZSwgYm90aCAmbHQ7bWVkaWFQcm92aWRlciZndDsgYW5kICZsdDttZWRpYUNvbnN1bWVyJmd0OyBh cmUgbWFuZGF0b3J5LiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEnPlRoZSBjb250ZW50IG9mIHRoZSAmcXVvdDt2JnF1b3Q7IGF0dHJp YnV0ZSBhbmQgb2YgdGhlICZsdDt2ZXJzaW9uJmd0OyBlbGVtZW50cyBjYXJyaWVkIGluIHRoZSBP UFRJT05TIGFuZCBPUFRJT05TIFJFU1BPTlNFIG1lc3NhZ2VzIGhhcyBiZWVuIGRlc2NyaWJlZCBt b3JlIHByZWNpc2VseS4gPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xJz5BZHZlcnRpc2VtZW50IGV4YW1wbGVzIGhhdmUgYmVlbiBhZGRl ZC4gPG86cD48L286cD48L2xpPjwvb2w+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5UaGUgQURWIGV4 YW1wbGVzJm5ic3A7IHRoYXQgd2UgaGF2ZSBpbmNsdWRlZCBpbiB0aGUgcHJvdG9jb2wgZHJhZnQg cmVwcmVzZW50IHRoZSBzaXR1YXRpb25zIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIyIGFuZCAyMyBv ZiB0aGUgZGF0YSBtb2RlbCBkcmFmdC4gPGJyPlRoZXkgY2FuIGJlIGRvd25sb2FkZWQgaGVyZTo8 YnI+PGJyPjxhIGhyZWY9Imh0dHA6Ly93cGFnZS51bmluYS5pdC9zcHJvbWFuby9DTFVFLyI+aHR0 cDovL3dwYWdlLnVuaW5hLml0L3Nwcm9tYW5vL0NMVUUvPC9hPjxicj48YnI+PGJyPlJlZ2FyZHMs PGJyPjxicj5Sb2JlcnRhPGJyPjxicj48YnI+SWwgMjAvMDYvMjAxNCAxODoyMywgUGF1bCBLeXpp dmF0IGhhIHNjcml0dG86PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6NDEuMjVwdCc+RHVyaW5nIGEgcGFzdCBkZXNpZ24gdGVh bSBjYWxsIEkgcHJvcG9zZWQgYSBob21ld29yayB0YXNrIHRoYXQgSSB0aG91Z2h0IHdvdWxkIGJl IHZlcnkgaGVscGZ1bC4gVGhlIGlkZWEgd2FzIHdlbGwgcmVjZWl2ZWQsIGJ1dCBub3RoaW5nIGhh cyBoYXBwZW5lZC4gU28gSSdsbCBzcGVsbCBpdCBvdXQgaW4gbW9yZSBkZXRhaWw6IDxicj48YnI+ VGhlIGlkZWEgaXMgdG8gZG8gYSAmcXVvdDt0ZXN0IHJ1biZxdW90OyBvZiB0aGUga2V5IGFzcGVj dHMgb2YgY2x1ZSwgZXNwZWNpYWxseSBmcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgcGVyc3BlY3Rp dmUuIFNwZWNpZmljYWxseSwgSSBwcm9wb3NlIHRoYXQsIGFzIGEgZmlyc3Qgc3RlcCwgZXZlcnli b2R5IHdobyBjYW4gcmVwcmVzZW50IGEgcG9zc2libGUgaW1wbGVtZW50YXRpb24gb2YgQ0xVRSBz aG91bGQgd3JpdGUgZG93biBhIHByb3Bvc2VkIGFkdmVydGlzZW1lbnQgZm9yIGVhY2ggb2YgdGhl aXIgbGlrZWx5IGRldmljZSBjb25maWd1cmF0aW9ucywgYW5kIHNoYXJlIHRoYXQgd2l0aCB0aGUg Z3JvdXAuIChFLmcuLCBpZiB5b3UgaGF2ZSBhIG9uZS1zY3JlZW4gc3lzdGVtIGFuZCBhIHRocmVl LXNjcmVlbiBzeXN0ZW0sIHRoZW4gcHJvdmlkZSBhbiBhZHZlcnRpc2VtZW50IGZvciBlYWNoLikg PGJyPjxicj5UaGUgbmV4dCBzdGVwIHdvdWxkIGJlIGZvciBlYWNoIHBlcnNvbiB0byBsb29rIGF0 IGFsbCB0aGUgYWR2ZXJ0aXNlbWVudHMgb3RoZXIgdGhhbiB0aGVpciBvd24sIGFuZCBkZWNpZGUg aWYgdGhleSBjYW4gbWFrZSBzZW5zZSBvZiBlYWNoIGFuZCBtYWtlIGEgZ29vZCBjaG9pY2Ugb2Yg d2hhdCB0byBjb25maWd1cmUsIGFuZCBob3cgdGhleSB3b3VsZCByZW5kZXIgdGhhdCBvbiB0aGVp ciBkZXZpY2UocykuIDxicj48YnI+WWV0IGFub3RoZXIgc3RlcCB3aWxsIGJlIHRvIGV4dGVuZCB0 aGUgYWJvdmUgdG8gTUNVcy4gV2UgY291bGQgcGljayBjb21iaW5hdGlvbnMgb2YgZW5kcG9pbnRz IGFuZCBhc2sgcGVvcGxlIHdpdGggTUNVcyB0byBkZWNpZGUgd2hhdCB0aGV5IHdvdWxkIGNvbmZp Z3VyZSBhbmQgdGhlbiB3aGF0IHRoZXkgd291bGQgYWR2ZXJ0aXNlIGFzIGEgcmVzdWx0LiBBbmQg dGhlbiBwZW9wbGUgdG8gcmV2aWV3IHRob3NlIGFkdmVydGlzZW1lbnRzIGFzIHdlbGwuIDxicj48 YnI+KElkZWFsbHkgdGhlcmUgd2lsbCBiZSBubyBzdXJwcmlzZXMgaGVyZS4gQnV0IHdoYXQgSSAq ZXhwZWN0KiB0byBoYXBwZW4gaGVyZSBpcyB0aGF0IHBlb3BsZSB3aWxsIGJlIHN1cnByaXNlZCB0 byBmaW5kIHRoaW5ncyB0aGV5IGRvbid0IHVuZGVyc3RhbmQgYW5kL29yIGNhbid0IGRlYWwgd2l0 aCBpbiBhbnkgdXNlZnVsIHdheS4gRGlzY3Vzc2lvbnMgdG8gY2xhcmlmeSB0aGVzZSB3b3VsZCBm b2xsb3csIGFuZCBwZXJoYXBzIGxlYWQgdG8gc29tZSBjbGFyaWZpY2F0aW9ucyBhbmQgbWF5YmUg Zml4ZXMuKSA8YnI+PGJyPlRoaXMgZXhlcmNpc2UgaXMgYSBiaXQgbGlrZSBkb2luZyBjYWxsIGZs b3dzLCBidXQgdGhlIGxldmVsIG9mIGRldGFpbCBpcyBkaWZmZXJlbnQuIEluaXRpYWxseSBJIHRo aW5rIHdlIG9ubHkgbmVlZCB0aGUgYWR2ZXJ0aXNlbWVudHMsIGFuZCB0aGUgY29ycmVzcG9uZGlu ZyBTRFAgdGhhdCBjb250YWlucyB0aGUgZW5jb2RpbmdzLiBUaGUgYWR2ZXJ0aXNlbWVudHMgY291 bGQgYmUgZW5jb2RlZCBhY2NvcmRpbmcgdG8gdGhlIG1lc3NhZ2Ugc3ludGF4IGluIHRoZSBwcm90 b2NvbCBkb2N1bWVudCwgYnV0IGZvciBzaW1wbGljaXR5IEkgdGhpbmsgcGVvcGxlIGNhbiB0YWtl IGxpYmVydGllcyBhbmQgdXNlIGluZm9ybWFsIHNob3J0aGFuZCwgYXMgbG9uZyBhcyB0aGV5IGlu Y2x1ZGUgYWxsIHRoZSBwaWVjZXMuIDxicj48YnI+VGhpcyBpcyBleHRyYSB3b3JrIGZvciBldmVy eWJvZHksIHNvIEknZCBsaWtlIHRvIG1ha2UgaXQgYXMgZWFzeSBhcyBwb3NzaWJsZS4gT25lIHBv c3NpYmlsaXR5IGlzIGZvciBwZW9wbGUgdG8gc3VibWl0IGNvbnRyaWJ1dGlvbnMgdmlhIGVtYWls IGFuZCB0aGVuIGNvbGxhdGUgdGhlbSBpbnRvIGFuIGluZGl2aWR1YWwgZHJhZnQuIChJIGFtIHdp bGxpbmcgdG8gZG8gdGhlIGNvbGxhdGlvbi4pIE9yIHdlIGNvdWxkIGRvIHRoaXMgb24gdGhlIENM VUUgV2lraS4gKFRoZSBXaWtpIG1pZ2h0IGJlIGVhc2llci4pIFlvdXIgdGhvdWdodHMgb24gdGhp cyBhcmUgd2VsY29tZS4gPGJyPjxicj5XaG8gd291bGQgYmUgd2lsbGluZyB0byBwYXJ0aWNpcGF0 ZSBpbiBzdWNoIGFuIGV4ZXJjaXNlPyA8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Ro YW5rcywgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1BhdWwgPGJyPjxicj48bzpwPjwvbzpw PjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24CRPMBOXPRD08p_-- From nobody Tue Jun 24 06:02:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319AF1B290A for ; Tue, 24 Jun 2014 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, 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 PaqGaPHtkcvY for ; Tue, 24 Jun 2014 06:02:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2D21B2901 for ; Tue, 24 Jun 2014 06:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15704; q=dns/txt; s=iport; t=1403614963; x=1404824563; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=4ur4Bh2d5uG5Wwb8CV/FzrbkwRIKnSkF5QUjNZv6KMQ=; b=j+05as0XGTSUbfNNCquANJB0GpsMtUsz/Wj6DTDDQILoBAY79DB6RaTw AIyz3ixM80rHD+F2Lvqt7Jlg0gaoBO/+mVyru8AixzwNGTO/vWXzWjODe 9h07UhXKMxysCSEeB2AdOJueec24FlPm4jLDg4nUnEsYvZBOsGzSmKPaX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoEAI52qVOtJssW/2dsb2JhbABZgkaBGYkioXgFAZF6AYc/AYEbdYQDAQEBBAEBASQGOgcKEQsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQGIPg3DaReFY4g3EQFWAQaEPQWaUYFGhTiMbYNDPC8BAYEJ X-IronPort-AV: E=Sophos; i="5.01,537,1400025600"; d="scan'208,217"; a="97666763" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Jun 2014 13:02:40 +0000 Received: from [10.47.200.113] ([10.47.200.113]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5OD2cev017583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 24 Jun 2014 13:02:38 GMT Message-ID: <53A97775.2060901@cisco.com> Date: Tue, 24 Jun 2014 14:04:53 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> Content-Type: multipart/alternative; boundary="------------080806000705050501020201" X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NwSCY8B28lcwYfra1ZWCNyHf28c Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:02:47 -0000 This is a multi-part message in MIME format. --------------080806000705050501020201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm in too - did we come up with a good place to put them? Rob On 24/06/14 14:00, Duckworth, Mark wrote: > > Hi Paul, > > I'd like to participate also. I'll try to put together an > Advertisement and post it before IETF90. I will also look through > Simon and Roberta's Advertisements. > > Mark > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roberta Presta > *Sent:* Tuesday, June 24, 2014 7:15 AM > *To:* clue@ietf.org > *Subject:* Re: [clue] Homework - "test" of CLUE > > Dear all, > > we have just uploaded version 01 of the protocol draft with the > following updates: > > 1. The XML schema of the ADVERTISEMENT and of the READV have been > aligned with the current definitions in > [I-D.ietf-clue-data-model-schema] > > (example of updates: --> , > --> ) > 2. Text has been added to clarify that, in the OPTIONS RESPONSE, when > the response code is not an error response code, both > and are mandatory. > 3. The content of the "v" attribute and of the elements > carried in the OPTIONS and OPTIONS RESPONSE messages has been > described more precisely. > 4. Advertisement examples have been added. > > > The ADV examples that we have included in the protocol draft > represent the situations described in Section 22 and 23 of the data > model draft. > They can be downloaded here: > > http://wpage.unina.it/spromano/CLUE/ > > > Regards, > > Roberta > > > Il 20/06/2014 18:23, Paul Kyzivat ha scritto: > > During a past design team call I proposed a homework task that I > thought would be very helpful. The idea was well received, but > nothing has happened. So I'll spell it out in more detail: > > The idea is to do a "test run" of the key aspects of clue, > especially from an interoperability perspective. Specifically, I > propose that, as a first step, everybody who can represent a > possible implementation of CLUE should write down a proposed > advertisement for each of their likely device configurations, and > share that with the group. (E.g., if you have a one-screen system > and a three-screen system, then provide an advertisement for each.) > > The next step would be for each person to look at all the > advertisements other than their own, and decide if they can make > sense of each and make a good choice of what to configure, and how > they would render that on their device(s). > > Yet another step will be to extend the above to MCUs. We could > pick combinations of endpoints and ask people with MCUs to decide > what they would configure and then what they would advertise as a > result. And then people to review those advertisements as well. > > (Ideally there will be no surprises here. But what I *expect* to > happen here is that people will be surprised to find things they > don't understand and/or can't deal with in any useful way. > Discussions to clarify these would follow, and perhaps lead to > some clarifications and maybe fixes.) > > This exercise is a bit like doing call flows, but the level of > detail is different. Initially I think we only need the > advertisements, and the corresponding SDP that contains the > encodings. The advertisements could be encoded according to the > message syntax in the protocol document, but for simplicity I > think people can take liberties and use informal shorthand, as > long as they include all the pieces. > > This is extra work for everybody, so I'd like to make it as easy > as possible. One possibility is for people to submit contributions > via email and then collate them into an individual draft. (I am > willing to do the collation.) Or we could do this on the CLUE > Wiki. (The Wiki might be easier.) Your thoughts on this are welcome. > > Who would be willing to participate in such an exercise? > > Thanks, > Paul > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------080806000705050501020201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm in too - did we come up with a good place to put them?

Rob

On 24/06/14 14:00, Duckworth, Mark wrote:

Hi Paul,

 

I’d like to participate also.  I’ll try to put together an Advertisement and post it before IETF90.  I will also look through Simon and Roberta’s Advertisements.

 

Mark

 

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roberta Presta
Sent: Tuesday, June 24, 2014 7:15 AM
To: clue@ietf.org
Subject: Re: [clue] Homework - "test" of CLUE

 

Dear all,

we have just uploaded version 01 of the protocol draft with the following updates:

  1. The XML schema of the ADVERTISEMENT and of the READV have been aligned with the current definitions in [I‑D.ietf‑clue‑data‑model‑schema] (example of updates: <participants> --> <people>, <globalCaptureEntries> --> <globalSceneEntries>)
  2. Text has been added to clarify that, in the OPTIONS RESPONSE, when the response code is not an error response code, both <mediaProvider> and <mediaConsumer> are mandatory.
  3. The content of the "v" attribute and of the <version> elements carried in the OPTIONS and OPTIONS RESPONSE messages has been described more precisely.
  4. Advertisement examples have been added.


The ADV examples  that we have included in the protocol draft represent the situations described in Section 22 and 23 of the data model draft.
They can be downloaded here:

http://wpage.unina.it/spromano/CLUE/


Regards,

Roberta


Il 20/06/2014 18:23, Paul Kyzivat ha scritto:

During a past design team call I proposed a homework task that I thought would be very helpful. The idea was well received, but nothing has happened. So I'll spell it out in more detail:

The idea is to do a "test run" of the key aspects of clue, especially from an interoperability perspective. Specifically, I propose that, as a first step, everybody who can represent a possible implementation of CLUE should write down a proposed advertisement for each of their likely device configurations, and share that with the group. (E.g., if you have a one-screen system and a three-screen system, then provide an advertisement for each.)

The next step would be for each person to look at all the advertisements other than their own, and decide if they can make sense of each and make a good choice of what to configure, and how they would render that on their device(s).

Yet another step will be to extend the above to MCUs. We could pick combinations of endpoints and ask people with MCUs to decide what they would configure and then what they would advertise as a result. And then people to review those advertisements as well.

(Ideally there will be no surprises here. But what I *expect* to happen here is that people will be surprised to find things they don't understand and/or can't deal with in any useful way. Discussions to clarify these would follow, and perhaps lead to some clarifications and maybe fixes.)

This exercise is a bit like doing call flows, but the level of detail is different. Initially I think we only need the advertisements, and the corresponding SDP that contains the encodings. The advertisements could be encoded according to the message syntax in the protocol document, but for simplicity I think people can take liberties and use informal shorthand, as long as they include all the pieces.

This is extra work for everybody, so I'd like to make it as easy as possible. One possibility is for people to submit contributions via email and then collate them into an individual draft. (I am willing to do the collation.) Or we could do this on the CLUE Wiki. (The Wiki might be easier.) Your thoughts on this are welcome.

Who would be willing to participate in such an exercise?

    Thanks,
    Paul 



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

--------------080806000705050501020201-- From nobody Tue Jun 24 07:46:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B201B2AD2 for ; Tue, 24 Jun 2014 07:46:19 -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 gqq-vsi8AwG2 for ; Tue, 24 Jun 2014 07:46:15 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE721B2ADA for ; Tue, 24 Jun 2014 07:46:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id JDU41o0051ap0As5DEm2fL; Tue, 24 Jun 2014 14:46:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id JEm21o00Q3ZTu2S3iEm239; Tue, 24 Jun 2014 14:46:02 +0000 Message-ID: <53A98F2A.1090002@alum.mit.edu> Date: Tue, 24 Jun 2014 10:46:02 -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: clue@ietf.org References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> <53A97775.2060901@cisco.com> In-Reply-To: <53A97775.2060901@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403621162; bh=P3p3LItUs2ZxdxTzCUovQ+ua01z5Z4F9uX48Jkrv+nM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T8UvSXdOd0kyZlkjJHR1mpSOYPYyNA+pWYjMH0qZSWIWSLLSQ7otv8RxaSMN7BX+6 7DG7WE71I4ZhYmPhNLrPessEq51R49PfhmSVR0dHtuHJjMze31lp4Hk+qmabEGFkYI nsDyGIC6kRn2SyYAPxqAue8Oa8unml/Te7Jki2y3GVdzEKN6l1KVblBLdpr0IdcDeh sKAxeaUAcVKV3S2JDp60C8FaW81NabrNMQ3qk6/6ca510Qj20HzStiVQDcx3M4Tkut mLFZTizU4i/LzUhE9z19EZYWouaF9h0VgVJwnQx7bgPXbQDXGkSeEPuR2Ri8Gt6NX8 FKfR+GpH/Y0Fw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3ww9yVsypg0aMvWPnXaMAAkNpxw Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:46:20 -0000 On 6/24/14 9:04 AM, Robert Hansen wrote: > I'm in too - did we come up with a good place to put them? Not yet. I'm inclined to prefer adding a page for the purpose to our clue wiki. Does that work for people? Thanks, Paul > Rob > > On 24/06/14 14:00, Duckworth, Mark wrote: >> >> Hi Paul, >> >> I’d like to participate also. I’ll try to put together an >> Advertisement and post it before IETF90. I will also look through >> Simon and Roberta’s Advertisements. >> >> Mark >> >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roberta Presta >> *Sent:* Tuesday, June 24, 2014 7:15 AM >> *To:* clue@ietf.org >> *Subject:* Re: [clue] Homework - "test" of CLUE >> >> Dear all, >> >> we have just uploaded version 01 of the protocol draft with the >> following updates: >> >> 1. The XML schema of the ADVERTISEMENT and of the READV have been >> aligned with the current definitions in >> [I‑D.ietf‑clue‑data‑model‑schema] >> >> (example of updates: --> , >> --> ) >> 2. Text has been added to clarify that, in the OPTIONS RESPONSE, when >> the response code is not an error response code, both >> and are mandatory. >> 3. The content of the "v" attribute and of the elements >> carried in the OPTIONS and OPTIONS RESPONSE messages has been >> described more precisely. >> 4. Advertisement examples have been added. >> >> >> The ADV examples that we have included in the protocol draft >> represent the situations described in Section 22 and 23 of the data >> model draft. >> They can be downloaded here: >> >> http://wpage.unina.it/spromano/CLUE/ >> >> >> Regards, >> >> Roberta >> >> >> Il 20/06/2014 18:23, Paul Kyzivat ha scritto: >> >> During a past design team call I proposed a homework task that I >> thought would be very helpful. The idea was well received, but >> nothing has happened. So I'll spell it out in more detail: >> >> The idea is to do a "test run" of the key aspects of clue, >> especially from an interoperability perspective. Specifically, I >> propose that, as a first step, everybody who can represent a >> possible implementation of CLUE should write down a proposed >> advertisement for each of their likely device configurations, and >> share that with the group. (E.g., if you have a one-screen system >> and a three-screen system, then provide an advertisement for each.) >> >> The next step would be for each person to look at all the >> advertisements other than their own, and decide if they can make >> sense of each and make a good choice of what to configure, and how >> they would render that on their device(s). >> >> Yet another step will be to extend the above to MCUs. We could >> pick combinations of endpoints and ask people with MCUs to decide >> what they would configure and then what they would advertise as a >> result. And then people to review those advertisements as well. >> >> (Ideally there will be no surprises here. But what I *expect* to >> happen here is that people will be surprised to find things they >> don't understand and/or can't deal with in any useful way. >> Discussions to clarify these would follow, and perhaps lead to >> some clarifications and maybe fixes.) >> >> This exercise is a bit like doing call flows, but the level of >> detail is different. Initially I think we only need the >> advertisements, and the corresponding SDP that contains the >> encodings. The advertisements could be encoded according to the >> message syntax in the protocol document, but for simplicity I >> think people can take liberties and use informal shorthand, as >> long as they include all the pieces. >> >> This is extra work for everybody, so I'd like to make it as easy >> as possible. One possibility is for people to submit contributions >> via email and then collate them into an individual draft. (I am >> willing to do the collation.) Or we could do this on the CLUE >> Wiki. (The Wiki might be easier.) Your thoughts on this are welcome. >> >> Who would be willing to participate in such an exercise? >> >> Thanks, >> Paul >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Jun 24 08:27:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692AB1B2D59 for ; Tue, 24 Jun 2014 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaPtAkhH_9QG for ; Tue, 24 Jun 2014 08:27:13 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DEC1B2D98 for ; Tue, 24 Jun 2014 08:23:31 -0700 (PDT) Received: from [216.82.254.19:10705] by server-13.bemta-7.messagelabs.com id AB/F1-02169-2F799A35; Tue, 24 Jun 2014 15:23:30 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-96.messagelabs.com!1403623406!6124737!12 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8484 invoked from network); 24 Jun 2014 15:23:30 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-8.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2014 15:23:30 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 24 Jun 2014 08:23:20 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Tue, 24 Jun 2014 08:23:19 -0700 Thread-Topic: [clue] Homework - "test" of CLUE Thread-Index: Ac+PuxKoqDygYx9bStmTuTOA6ff0vAABR1Tw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B4D@CRPMBOXPRD08.polycom.com> References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> <53A97775.2060901@cisco.com> <53A98F2A.1090002@alum.mit.edu> In-Reply-To: <53A98F2A.1090002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sQvJZEL4e6ujkFbBo9n3KAqvT_U Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:27:20 -0000 SSB0aGluayB0aGUgY2x1ZSB3aWtpIGlzIGEgZ29vZCBpZGVhLg0KTWFyaw0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4gU2VudDogVHVlc2RheSwgSnVuZSAy NCwgMjAxNCAxMDo0NiBBTQ0KPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Ns dWVdIEhvbWV3b3JrIC0gInRlc3QiIG9mIENMVUUNCj4gDQo+IE9uIDYvMjQvMTQgOTowNCBBTSwg Um9iZXJ0IEhhbnNlbiB3cm90ZToNCj4gPiBJJ20gaW4gdG9vIC0gZGlkIHdlIGNvbWUgdXAgd2l0 aCBhIGdvb2QgcGxhY2UgdG8gcHV0IHRoZW0/DQo+IA0KPiBOb3QgeWV0LiBJJ20gaW5jbGluZWQg dG8gcHJlZmVyIGFkZGluZyBhIHBhZ2UgZm9yIHRoZSBwdXJwb3NlIHRvIG91ciBjbHVlIHdpa2ku DQo+IERvZXMgdGhhdCB3b3JrIGZvciBwZW9wbGU/DQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0K PiANCj4gPiBSb2INCj4gPg0KPiA+IE9uIDI0LzA2LzE0IDE0OjAwLCBEdWNrd29ydGgsIE1hcmsg d3JvdGU6DQo+ID4+DQo+ID4+IEhpIFBhdWwsDQo+ID4+DQo+ID4+IEnigJlkIGxpa2UgdG8gcGFy dGljaXBhdGUgYWxzby4gIEnigJlsbCB0cnkgdG8gcHV0IHRvZ2V0aGVyIGFuDQo+ID4+IEFkdmVy dGlzZW1lbnQgYW5kIHBvc3QgaXQgYmVmb3JlIElFVEY5MC4gIEkgd2lsbCBhbHNvIGxvb2sgdGhy b3VnaA0KPiA+PiBTaW1vbiBhbmQgUm9iZXJ0YeKAmXMgQWR2ZXJ0aXNlbWVudHMuDQo+ID4+DQo+ ID4+IE1hcmsNCj4gPj4NCj4gPj4gKkZyb206KmNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0 Zi5vcmddICpPbiBCZWhhbGYgT2YgKlJvYmVydGENCj4gPj4gUHJlc3RhDQo+ID4+ICpTZW50Oiog VHVlc2RheSwgSnVuZSAyNCwgMjAxNCA3OjE1IEFNDQo+ID4+ICpUbzoqIGNsdWVAaWV0Zi5vcmcN Cj4gPj4gKlN1YmplY3Q6KiBSZTogW2NsdWVdIEhvbWV3b3JrIC0gInRlc3QiIG9mIENMVUUNCj4g Pj4NCj4gPj4gRGVhciBhbGwsDQo+ID4+DQo+ID4+IHdlIGhhdmUganVzdCB1cGxvYWRlZCB2ZXJz aW9uIDAxIG9mIHRoZSBwcm90b2NvbCBkcmFmdCB3aXRoIHRoZQ0KPiA+PiBmb2xsb3dpbmcgdXBk YXRlczoNCj4gPj4NCj4gPj4gIDEuIFRoZSBYTUwgc2NoZW1hIG9mIHRoZSBBRFZFUlRJU0VNRU5U IGFuZCBvZiB0aGUgUkVBRFYgaGF2ZSBiZWVuDQo+ID4+ICAgICBhbGlnbmVkIHdpdGggdGhlIGN1 cnJlbnQgZGVmaW5pdGlvbnMgaW4NCj4gPj4gICAgIFtJ4oCRRC5pZXRm4oCRY2x1ZeKAkWRhdGHi gJFtb2RlbOKAkXNjaGVtYV0NCj4gPj4gICAgIDxodHRwOi8veG1sMnJmYy50b29scy5pZXRmLm9y Zy9jZ2ktYmluL3htbDJyZmMtb2xkLmNnaSNJLUQuaWV0Zi1jbHVlLWRhdGEtDQo+IG1vZGVsLXNj aGVtYT4NCj4gPj4gICAgIChleGFtcGxlIG9mIHVwZGF0ZXM6IDxwYXJ0aWNpcGFudHM+IC0tPiA8 cGVvcGxlPiwNCj4gPj4gICAgIDxnbG9iYWxDYXB0dXJlRW50cmllcz4gLS0+IDxnbG9iYWxTY2Vu ZUVudHJpZXM+KSAgMi4gVGV4dCBoYXMNCj4gPj4gYmVlbiBhZGRlZCB0byBjbGFyaWZ5IHRoYXQs IGluIHRoZSBPUFRJT05TIFJFU1BPTlNFLCB3aGVuDQo+ID4+ICAgICB0aGUgcmVzcG9uc2UgY29k ZSBpcyBub3QgYW4gZXJyb3IgcmVzcG9uc2UgY29kZSwgYm90aA0KPiA+PiAgICAgPG1lZGlhUHJv dmlkZXI+IGFuZCA8bWVkaWFDb25zdW1lcj4gYXJlIG1hbmRhdG9yeS4NCj4gPj4gIDMuIFRoZSBj b250ZW50IG9mIHRoZSAidiIgYXR0cmlidXRlIGFuZCBvZiB0aGUgPHZlcnNpb24+IGVsZW1lbnRz DQo+ID4+ICAgICBjYXJyaWVkIGluIHRoZSBPUFRJT05TIGFuZCBPUFRJT05TIFJFU1BPTlNFIG1l c3NhZ2VzIGhhcyBiZWVuDQo+ID4+ICAgICBkZXNjcmliZWQgbW9yZSBwcmVjaXNlbHkuDQo+ID4+ ICA0LiBBZHZlcnRpc2VtZW50IGV4YW1wbGVzIGhhdmUgYmVlbiBhZGRlZC4NCj4gPj4NCj4gPj4N Cj4gPj4gVGhlIEFEViBleGFtcGxlcyAgdGhhdCB3ZSBoYXZlIGluY2x1ZGVkIGluIHRoZSBwcm90 b2NvbCBkcmFmdA0KPiA+PiByZXByZXNlbnQgdGhlIHNpdHVhdGlvbnMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMjIgYW5kIDIzIG9mIHRoZSBkYXRhDQo+ID4+IG1vZGVsIGRyYWZ0Lg0KPiA+PiBUaGV5 IGNhbiBiZSBkb3dubG9hZGVkIGhlcmU6DQo+ID4+DQo+ID4+IGh0dHA6Ly93cGFnZS51bmluYS5p dC9zcHJvbWFuby9DTFVFLw0KPiA+Pg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+Pg0KPiA+PiBS b2JlcnRhDQo+ID4+DQo+ID4+DQo+ID4+IElsIDIwLzA2LzIwMTQgMTg6MjMsIFBhdWwgS3l6aXZh dCBoYSBzY3JpdHRvOg0KPiA+Pg0KPiA+PiAgICAgRHVyaW5nIGEgcGFzdCBkZXNpZ24gdGVhbSBj YWxsIEkgcHJvcG9zZWQgYSBob21ld29yayB0YXNrIHRoYXQgSQ0KPiA+PiAgICAgdGhvdWdodCB3 b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuIFRoZSBpZGVhIHdhcyB3ZWxsIHJlY2VpdmVkLCBidXQNCj4g Pj4gICAgIG5vdGhpbmcgaGFzIGhhcHBlbmVkLiBTbyBJJ2xsIHNwZWxsIGl0IG91dCBpbiBtb3Jl IGRldGFpbDoNCj4gPj4NCj4gPj4gICAgIFRoZSBpZGVhIGlzIHRvIGRvIGEgInRlc3QgcnVuIiBv ZiB0aGUga2V5IGFzcGVjdHMgb2YgY2x1ZSwNCj4gPj4gICAgIGVzcGVjaWFsbHkgZnJvbSBhbiBp bnRlcm9wZXJhYmlsaXR5IHBlcnNwZWN0aXZlLiBTcGVjaWZpY2FsbHksIEkNCj4gPj4gICAgIHBy b3Bvc2UgdGhhdCwgYXMgYSBmaXJzdCBzdGVwLCBldmVyeWJvZHkgd2hvIGNhbiByZXByZXNlbnQg YQ0KPiA+PiAgICAgcG9zc2libGUgaW1wbGVtZW50YXRpb24gb2YgQ0xVRSBzaG91bGQgd3JpdGUg ZG93biBhIHByb3Bvc2VkDQo+ID4+ICAgICBhZHZlcnRpc2VtZW50IGZvciBlYWNoIG9mIHRoZWly IGxpa2VseSBkZXZpY2UgY29uZmlndXJhdGlvbnMsIGFuZA0KPiA+PiAgICAgc2hhcmUgdGhhdCB3 aXRoIHRoZSBncm91cC4gKEUuZy4sIGlmIHlvdSBoYXZlIGEgb25lLXNjcmVlbiBzeXN0ZW0NCj4g Pj4gICAgIGFuZCBhIHRocmVlLXNjcmVlbiBzeXN0ZW0sIHRoZW4gcHJvdmlkZSBhbiBhZHZlcnRp c2VtZW50IGZvcg0KPiA+PiBlYWNoLikNCj4gPj4NCj4gPj4gICAgIFRoZSBuZXh0IHN0ZXAgd291 bGQgYmUgZm9yIGVhY2ggcGVyc29uIHRvIGxvb2sgYXQgYWxsIHRoZQ0KPiA+PiAgICAgYWR2ZXJ0 aXNlbWVudHMgb3RoZXIgdGhhbiB0aGVpciBvd24sIGFuZCBkZWNpZGUgaWYgdGhleSBjYW4gbWFr ZQ0KPiA+PiAgICAgc2Vuc2Ugb2YgZWFjaCBhbmQgbWFrZSBhIGdvb2QgY2hvaWNlIG9mIHdoYXQg dG8gY29uZmlndXJlLCBhbmQgaG93DQo+ID4+ICAgICB0aGV5IHdvdWxkIHJlbmRlciB0aGF0IG9u IHRoZWlyIGRldmljZShzKS4NCj4gPj4NCj4gPj4gICAgIFlldCBhbm90aGVyIHN0ZXAgd2lsbCBi ZSB0byBleHRlbmQgdGhlIGFib3ZlIHRvIE1DVXMuIFdlIGNvdWxkDQo+ID4+ICAgICBwaWNrIGNv bWJpbmF0aW9ucyBvZiBlbmRwb2ludHMgYW5kIGFzayBwZW9wbGUgd2l0aCBNQ1VzIHRvIGRlY2lk ZQ0KPiA+PiAgICAgd2hhdCB0aGV5IHdvdWxkIGNvbmZpZ3VyZSBhbmQgdGhlbiB3aGF0IHRoZXkg d291bGQgYWR2ZXJ0aXNlIGFzIGENCj4gPj4gICAgIHJlc3VsdC4gQW5kIHRoZW4gcGVvcGxlIHRv IHJldmlldyB0aG9zZSBhZHZlcnRpc2VtZW50cyBhcyB3ZWxsLg0KPiA+Pg0KPiA+PiAgICAgKElk ZWFsbHkgdGhlcmUgd2lsbCBiZSBubyBzdXJwcmlzZXMgaGVyZS4gQnV0IHdoYXQgSSAqZXhwZWN0 KiB0bw0KPiA+PiAgICAgaGFwcGVuIGhlcmUgaXMgdGhhdCBwZW9wbGUgd2lsbCBiZSBzdXJwcmlz ZWQgdG8gZmluZCB0aGluZ3MgdGhleQ0KPiA+PiAgICAgZG9uJ3QgdW5kZXJzdGFuZCBhbmQvb3Ig Y2FuJ3QgZGVhbCB3aXRoIGluIGFueSB1c2VmdWwgd2F5Lg0KPiA+PiAgICAgRGlzY3Vzc2lvbnMg dG8gY2xhcmlmeSB0aGVzZSB3b3VsZCBmb2xsb3csIGFuZCBwZXJoYXBzIGxlYWQgdG8NCj4gPj4g ICAgIHNvbWUgY2xhcmlmaWNhdGlvbnMgYW5kIG1heWJlIGZpeGVzLikNCj4gPj4NCj4gPj4gICAg IFRoaXMgZXhlcmNpc2UgaXMgYSBiaXQgbGlrZSBkb2luZyBjYWxsIGZsb3dzLCBidXQgdGhlIGxl dmVsIG9mDQo+ID4+ICAgICBkZXRhaWwgaXMgZGlmZmVyZW50LiBJbml0aWFsbHkgSSB0aGluayB3 ZSBvbmx5IG5lZWQgdGhlDQo+ID4+ICAgICBhZHZlcnRpc2VtZW50cywgYW5kIHRoZSBjb3JyZXNw b25kaW5nIFNEUCB0aGF0IGNvbnRhaW5zIHRoZQ0KPiA+PiAgICAgZW5jb2RpbmdzLiBUaGUgYWR2 ZXJ0aXNlbWVudHMgY291bGQgYmUgZW5jb2RlZCBhY2NvcmRpbmcgdG8gdGhlDQo+ID4+ICAgICBt ZXNzYWdlIHN5bnRheCBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQsIGJ1dCBmb3Igc2ltcGxpY2l0 eSBJDQo+ID4+ICAgICB0aGluayBwZW9wbGUgY2FuIHRha2UgbGliZXJ0aWVzIGFuZCB1c2UgaW5m b3JtYWwgc2hvcnRoYW5kLCBhcw0KPiA+PiAgICAgbG9uZyBhcyB0aGV5IGluY2x1ZGUgYWxsIHRo ZSBwaWVjZXMuDQo+ID4+DQo+ID4+ICAgICBUaGlzIGlzIGV4dHJhIHdvcmsgZm9yIGV2ZXJ5Ym9k eSwgc28gSSdkIGxpa2UgdG8gbWFrZSBpdCBhcyBlYXN5DQo+ID4+ICAgICBhcyBwb3NzaWJsZS4g T25lIHBvc3NpYmlsaXR5IGlzIGZvciBwZW9wbGUgdG8gc3VibWl0IGNvbnRyaWJ1dGlvbnMNCj4g Pj4gICAgIHZpYSBlbWFpbCBhbmQgdGhlbiBjb2xsYXRlIHRoZW0gaW50byBhbiBpbmRpdmlkdWFs IGRyYWZ0LiAoSSBhbQ0KPiA+PiAgICAgd2lsbGluZyB0byBkbyB0aGUgY29sbGF0aW9uLikgT3Ig d2UgY291bGQgZG8gdGhpcyBvbiB0aGUgQ0xVRQ0KPiA+PiAgICAgV2lraS4gKFRoZSBXaWtpIG1p Z2h0IGJlIGVhc2llci4pIFlvdXIgdGhvdWdodHMgb24gdGhpcyBhcmUgd2VsY29tZS4NCj4gPj4N Cj4gPj4gICAgIFdobyB3b3VsZCBiZSB3aWxsaW5nIHRvIHBhcnRpY2lwYXRlIGluIHN1Y2ggYW4g ZXhlcmNpc2U/DQo+ID4+DQo+ID4+ICAgICAgICAgVGhhbmtzLA0KPiA+PiAgICAgICAgIFBhdWwN Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gPj4gY2x1ZUBpZXRmLm9y Zw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gPg0K PiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+DQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcg bGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2x1ZQ0K From nobody Tue Jun 24 08:40:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC41B28AD for ; Tue, 24 Jun 2014 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 HLJibDl-JmX7 for ; Tue, 24 Jun 2014 02:48:59 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id F3FCF1B2894 for ; Tue, 24 Jun 2014 02:48:58 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E9B5C32E567 for ; Tue, 24 Jun 2014 18:48:56 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 299b_2096_9e7f6584_07b4_4596_872a_4d07b460a732; Tue, 24 Jun 2014 18:48:55 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1ABDFBFB5A for ; Tue, 24 Jun 2014 18:48:56 +0900 (JST) Message-ID: <53A94978.7030403@it.aoyama.ac.jp> Date: Tue, 24 Jun 2014 18:48:40 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140619181813.12714.60680.idtracker@ietfa.amsl.com> In-Reply-To: <20140619181813.12714.60680.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/clue/i7uq1tC9TuTAEVXRVUbXUA0-Tz8 X-Mailman-Approved-At: Tue, 24 Jun 2014 08:40:23 -0700 Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 09:49:01 -0000 Dear Clue WG, I read the abstract below with interest, but I have to admit that it doesn't give me a clue (sic.) about what CLUE is about. I think people in the IETF in general would appreciate abstracts that are less self-referential and more informative to the IETF and the general public. Many thanks in advance for your consideration! Regards, Martin. On 2014/06/20 03:18, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : CLUE protocol > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-protocol-00.txt > Pages : 36 > Date : 2014-06-19 > > Abstract: > The CLUE protocol is an application protocol conceived for the > description and negotiation of a CLUE telepresence session. The > design of the CLUE protocol takes into account the requirements and > the framework defined, respectively, in [I-D.ietf-clue-framework] and > [I-D.ietf-clue-telepresence-requirements]. The companion document > [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as > well as on the SIP/SDP session establishment phase. CLUE messages > flow upon the CLUE data channel, based on reliable and ordered SCTP > over DTLS transport, as described in [I-D.ietf-clue-datachannel]. > Message details, together with the behavior of CLUE Participants > acting as Media Providers and/or Media Consumers, are herein > discussed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-protocol-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Tue Jun 24 15:46:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F96E1B2961 for ; Tue, 24 Jun 2014 15:46:03 -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 S5P2Xp_7IKke for ; Tue, 24 Jun 2014 15:46:01 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 754431B295D for ; Tue, 24 Jun 2014 15:46:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id JNHm1o0041GhbT853Nlzky; Tue, 24 Jun 2014 22:45:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id JNlz1o00s3ZTu2S3TNlzwW; Tue, 24 Jun 2014 22:45:59 +0000 Message-ID: <53A9FFA7.8050300@alum.mit.edu> Date: Tue, 24 Jun 2014 18:45:59 -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: "Duckworth, Mark" , "clue@ietf.org" References: <53A46013.1060108@alum.mit.edu> <53A95DB1.60801@unina.it> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B24@CRPMBOXPRD08.polycom.com> <53A97775.2060901@cisco.com> <53A98F2A.1090002@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B4D@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19B4D@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403649959; bh=bWcZCV0CFQoEYLl93vKaEbz8zdSF1AQu8X+NwKIpNxk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hXZsVOZQfUgZwu9GNydDn8hIGvRN5g54NiuenbjxsdybDiYyn2SZcEQQuwU8TdnO2 HK/YNTi+WEjeiWcuhVK/9d6R5tdbP3Gr48krI4F3mNv1AaJ2KmhGreRpAYLiQN5zbK HFDfFQQZpklKIPfJ1EJEKvngBKOQRpYTLfXKM+iQ7jkE45HKd9suuPpTjNZX5Cqd6O Y/tmWqy4vjqW7jT5dFp/hF0J443xpoqjWC7NgRn+pjXtvwMxnVWXp5AuVmnp5lQBVV mU5cYq5VpPxAHZf2pii2kDu6B7v/k8Y95w4L2/A/SlJhFyZPGLlyx+VAjHMdQMbNrB ao74XXjALTbIg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TNNYWtF-fRmN0evKbfJ9OtEMIa8 Subject: Re: [clue] Homework - "test" of CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 22:46:03 -0000 On 6/24/14 11:23 AM, Duckworth, Mark wrote: > I think the clue wiki is a good idea. OK. I created another wiki page for this purpose subordinate to the main clue wiki page. You will fine a reference to it under the heading "Repository of Sample Advertisements", or you can go directly to: http://trac.tools.ietf.org/wg/clue/trac/wiki/SampleAdvertisements. The page isn't populated with anything real yet. Feel free to go at it! Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Tuesday, June 24, 2014 10:46 AM >> To: clue@ietf.org >> Subject: Re: [clue] Homework - "test" of CLUE >> >> On 6/24/14 9:04 AM, Robert Hansen wrote: >>> I'm in too - did we come up with a good place to put them? >> >> Not yet. I'm inclined to prefer adding a page for the purpose to our clue wiki. >> Does that work for people? >> >> Thanks, >> Paul >> >>> Rob >>> >>> On 24/06/14 14:00, Duckworth, Mark wrote: >>>> >>>> Hi Paul, >>>> >>>> I’d like to participate also. I’ll try to put together an >>>> Advertisement and post it before IETF90. I will also look through >>>> Simon and Roberta’s Advertisements. >>>> >>>> Mark >>>> >>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roberta >>>> Presta >>>> *Sent:* Tuesday, June 24, 2014 7:15 AM >>>> *To:* clue@ietf.org >>>> *Subject:* Re: [clue] Homework - "test" of CLUE >>>> >>>> Dear all, >>>> >>>> we have just uploaded version 01 of the protocol draft with the >>>> following updates: >>>> >>>> 1. The XML schema of the ADVERTISEMENT and of the READV have been >>>> aligned with the current definitions in >>>> [I‑D.ietf‑clue‑data‑model‑schema] >>>> > model-schema> >>>> (example of updates: --> , >>>> --> ) 2. Text has >>>> been added to clarify that, in the OPTIONS RESPONSE, when >>>> the response code is not an error response code, both >>>> and are mandatory. >>>> 3. The content of the "v" attribute and of the elements >>>> carried in the OPTIONS and OPTIONS RESPONSE messages has been >>>> described more precisely. >>>> 4. Advertisement examples have been added. >>>> >>>> >>>> The ADV examples that we have included in the protocol draft >>>> represent the situations described in Section 22 and 23 of the data >>>> model draft. >>>> They can be downloaded here: >>>> >>>> http://wpage.unina.it/spromano/CLUE/ >>>> >>>> >>>> Regards, >>>> >>>> Roberta >>>> >>>> >>>> Il 20/06/2014 18:23, Paul Kyzivat ha scritto: >>>> >>>> During a past design team call I proposed a homework task that I >>>> thought would be very helpful. The idea was well received, but >>>> nothing has happened. So I'll spell it out in more detail: >>>> >>>> The idea is to do a "test run" of the key aspects of clue, >>>> especially from an interoperability perspective. Specifically, I >>>> propose that, as a first step, everybody who can represent a >>>> possible implementation of CLUE should write down a proposed >>>> advertisement for each of their likely device configurations, and >>>> share that with the group. (E.g., if you have a one-screen system >>>> and a three-screen system, then provide an advertisement for >>>> each.) >>>> >>>> The next step would be for each person to look at all the >>>> advertisements other than their own, and decide if they can make >>>> sense of each and make a good choice of what to configure, and how >>>> they would render that on their device(s). >>>> >>>> Yet another step will be to extend the above to MCUs. We could >>>> pick combinations of endpoints and ask people with MCUs to decide >>>> what they would configure and then what they would advertise as a >>>> result. And then people to review those advertisements as well. >>>> >>>> (Ideally there will be no surprises here. But what I *expect* to >>>> happen here is that people will be surprised to find things they >>>> don't understand and/or can't deal with in any useful way. >>>> Discussions to clarify these would follow, and perhaps lead to >>>> some clarifications and maybe fixes.) >>>> >>>> This exercise is a bit like doing call flows, but the level of >>>> detail is different. Initially I think we only need the >>>> advertisements, and the corresponding SDP that contains the >>>> encodings. The advertisements could be encoded according to the >>>> message syntax in the protocol document, but for simplicity I >>>> think people can take liberties and use informal shorthand, as >>>> long as they include all the pieces. >>>> >>>> This is extra work for everybody, so I'd like to make it as easy >>>> as possible. One possibility is for people to submit contributions >>>> via email and then collate them into an individual draft. (I am >>>> willing to do the collation.) Or we could do this on the CLUE >>>> Wiki. (The Wiki might be easier.) Your thoughts on this are welcome. >>>> >>>> Who would be willing to participate in such an exercise? >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jun 25 01:14:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0E1B2B0B for ; Wed, 25 Jun 2014 01:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBU6T1TQNhnX for ; Wed, 25 Jun 2014 01:14:36 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7B01B2AF2 for ; Wed, 25 Jun 2014 01:14:35 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so1538347wes.9 for ; Wed, 25 Jun 2014 01:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m5vbtDwUe8gA7CdiZzBOt5eQV/PyVAwpksvvEAH8imo=; b=BWDcDoty+dzXJhKl/xIs13RZ+mr4XvpyYbk0veDl3NRFQlu4VsqJeKE4B+RpPeKJ2O 5bzQYfRAaO5stih4PVw9sdsO+j7t4W6OCMP0esFe37D7T5tJLNpuxw/Oio3ipLT5chnI kmiQTUm0OOQFtexQX9Pi+S9b5MYfjeExA0CW+Q66fjjxkUArslsSB44/btEMzRpc/Toq CfeX4EZiJSA3axut0BJGqG/qt+LUmBFrY+uRv/CfTfvBfjaA/jPLEkkdlDZ6YYYLYEtG zzjvVYaEi4vBe9kgMSdNu9WOBeQW2Z7LOJ3jj0um1XYwD9928I0zl3lxI41O2/KwtFE6 +OFw== MIME-Version: 1.0 X-Received: by 10.180.188.144 with SMTP id ga16mr3782054wic.72.1403684071291; Wed, 25 Jun 2014 01:14:31 -0700 (PDT) Received: by 10.217.116.201 with HTTP; Wed, 25 Jun 2014 01:14:31 -0700 (PDT) In-Reply-To: <53A94978.7030403@it.aoyama.ac.jp> References: <20140619181813.12714.60680.idtracker@ietfa.amsl.com> <53A94978.7030403@it.aoyama.ac.jp> Date: Wed, 25 Jun 2014 03:14:31 -0500 Message-ID: From: Mary Barnes To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a11c380e6725f0104fca4aa88 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lquRUCFw2NOUWUX9MK0XnQrRM4Q Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:14:40 -0000 --001a11c380e6725f0104fca4aa88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you have a suggestion? I think the abstract is quite complete and we are talking about the details of the protocol solution. It starts out saying that we use CLUE for telepresence sessions, which I realize might not be so informative for people with no background in telepresence. There is a CLUE tutorial on the wiki. Then, the abstract goes on to provide references to other documents that can provide more detailed background information. Now, it might be possible to actually make that less detailed and more generalized. But, again, a suggestion is always helpful. Regards, Mary On Tue, Jun 24, 2014 at 4:48 AM, "Martin J. D=C3=BCrst" wrote: > Dear Clue WG, > > I read the abstract below with interest, but I have to admit that it > doesn't give me a clue (sic.) about what CLUE is about. I think people in > the IETF in general would appreciate abstracts that are less > self-referential and more informative to the IETF and the general public. > > Many thanks in advance for your consideration! > > Regards, Martin. > > On 2014/06/20 03:18, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : CLUE protocol >> Authors : Roberta Presta >> Simon Pietro Romano >> Filename : draft-ietf-clue-protocol-00.txt >> Pages : 36 >> Date : 2014-06-19 >> >> Abstract: >> The CLUE protocol is an application protocol conceived for the >> description and negotiation of a CLUE telepresence session. The >> design of the CLUE protocol takes into account the requirements and >> the framework defined, respectively, in [I-D.ietf-clue-framework] an= d >> [I-D.ietf-clue-telepresence-requirements]. The companion document >> [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as >> well as on the SIP/SDP session establishment phase. CLUE messages >> flow upon the CLUE data channel, based on reliable and ordered SCTP >> over DTLS transport, as described in [I-D.ietf-clue-datachannel]. >> Message details, together with the behavior of CLUE Participants >> acting as Media Providers and/or Media Consumers, are herein >> discussed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-clue-protocol-00 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a11c380e6725f0104fca4aa88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do you have a suggestion? =C2=A0I think the abstract is qu= ite complete and we are talking about the details of the protocol solution.= =C2=A0 =C2=A0It starts out saying that we use CLUE for telepresence sessio= ns, which I realize might not be so informative for people with no backgrou= nd in telepresence. =C2=A0There is a CLUE tutorial on the wiki. Then, the a= bstract goes on to provide references to other documents that can provide m= ore detailed background information. Now, it might be possible to actually = make that less detailed and more generalized. But, again, a suggestion is a= lways helpful.

Regards,
Mary


On Tue, Jun 24, 2014 at 4:48 AM, "= ;Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wr= ote:
Dear Clue WG,

I read the abstract below with interest, but I have to admit that it doesn&= #39;t give me a clue (sic.) about what CLUE is about. I think people in the= IETF in general would appreciate abstracts that are less self-referential = and more informative to the IETF and the general public.

Many thanks in advance for your consideration!

Regards, =C2=A0 Martin.

On 2014/06/20 03:18, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0 This draft is a work item of the ControLling mUltiple streams for tE= lepresence Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : CLUE protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rob= erta Presta
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Simon Pietro Romano
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-clue-protocol-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 36 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-06-19

Abstract:
=C2=A0 =C2=A0 The CLUE protocol is an application protocol conceived for th= e
=C2=A0 =C2=A0 description and negotiation of a CLUE telepresence session. = =C2=A0The
=C2=A0 =C2=A0 design of the CLUE protocol takes into account the requiremen= ts and
=C2=A0 =C2=A0 the framework defined, respectively, in [I-D.ietf-clue-framew= ork] and
=C2=A0 =C2=A0 [I-D.ietf-clue-telepresence-requirements]. =C2=A0The c= ompanion document
=C2=A0 =C2=A0 [I-D.kyzivat-clue-signaling] delves into CLUE signaling detai= ls, as
=C2=A0 =C2=A0 well as on the SIP/SDP session establishment phase. =C2=A0CLU= E messages
=C2=A0 =C2=A0 flow upon the CLUE data channel, based on reliable and ordere= d SCTP
=C2=A0 =C2=A0 over DTLS transport, as described in [I-D.ietf-clue-datachann= el].
=C2=A0 =C2=A0 Message details, together with the behavior of CLUE Participa= nts
=C2=A0 =C2=A0 acting as Media Providers and/or Media Consumers, are herein<= br> =C2=A0 =C2=A0 discussed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-proto= col/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-protocol-00


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--001a11c380e6725f0104fca4aa88-- From nobody Wed Jun 25 10:50:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A462D1B2D90 for ; Wed, 25 Jun 2014 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVceJs8a1IBI for ; Wed, 25 Jun 2014 10:50:29 -0700 (PDT) Received: from BLU004-OMC1S2.hotmail.com (blu004-omc1s2.hotmail.com [65.55.116.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C5F1B2DA1 for ; Wed, 25 Jun 2014 10:50:29 -0700 (PDT) Received: from BLU436-SMTP98 ([65.55.116.7]) by BLU004-OMC1S2.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Wed, 25 Jun 2014 10:50:29 -0700 X-TMN: [WvDk4S785EElet51PJviQpWQV8GrVZWC] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.62.229]) by smtphm.sympatico.ca over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384); Wed, 25 Jun 2014 10:50:28 -0700 From: Paul Coverdale To: "'Christian Groves'" , References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> <53A7B48F.4030405@nteczone.com> In-Reply-To: <53A7B48F.4030405@nteczone.com> Date: Wed, 25 Jun 2014 13:50:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+OoCX4VxDxJzuFSCGyECobmxHCCQAR7Q8g Content-Language: en-us X-OriginalArrivalTime: 25 Jun 2014 17:50:28.0418 (UTC) FILETIME=[F35BD220:01CF909D] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6sR43-aW8o1l1gxyZOw1GsowD5U Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:50:32 -0000 Hi Christian, I'm assuming such a description would go in the proposed new section 7.1.1.x. I don't know what level of detail is appropriate, but here's some possible text, although we really need a picture for clarity. At the Consumer, the sensitivity pattern attribute may be combined with the point of capture and point on line of capture (which together define the major axis of the sensitivity pattern) to define a 3-dimensional volume of capture where sounds can be expected to be picked up by the microphone providing this specific audio capture. This volume can be compared with the area of capture for video media to provide a check on whether the audio capture is indeed appropriate for the video capture that it is supposed to be associated with. For example, a video area of capture that fails to intersect at all with the audio volume of capture, or is at such a long radial distance from the microphone point of capture that the audio level would be very low, would be inappropriate. Regards, ..Paul >-----Original Message----- >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >Sent: Monday, June 23, 2014 1:01 AM >To: clue@ietf.org >Subject: Re: [clue] How to do deal with CLUE spatial audio aspects > >Hello Paul, Mark, > >Paul: Thanks for providing the text. For the sensitivity pattern >attribute is there some short description giving an example how it could >be used by the Consumer? > >Mark: I agree with your suggestion. I think its better to capture the >changes that way. > >Regards, Christian > >On 21/06/2014 4:48 AM, Duckworth, Mark wrote: >> Thanks Paul, >> >> I agree with your suggestion, but I would like to add a new section >7.1.1.x for the new sensitivity pattern attribute. Then split your >proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of >Capture and the new section. >> >> I can also update the section 12 examples that mention spatial >information for audio. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale >>> Sent: Thursday, June 19, 2014 10:46 AM >>> To: clue@ietf.org >>> Subject: [clue] How to do deal with CLUE spatial audio aspects >>> >>> Colleagues, >>> >>> Following up on the action from the Design Team meeting of June 17, I >>> propose the following text to be added at the end of section 7.1.1.3 >>> in the Framework document. >>> >>> ................ >>> Note that area of capture is not a valid concept for audio. To >>> capture spatial information related to audio, the point of capture >>> and point on line of capture ( as defined in sections 7.1.1.1 and >>> 7.1.1.2) may be used, along with another element defining the nominal >>> sensitivity pattern of the microphone (bearing in mind that the >>> actual microphone sensitivity pattern, in situ, may be somewhat >>> different due to local obstacles). Nominal microphone sensitivity >>> patterns to choose from include: Omni; Bi-directional; Cardioid; >>> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone >>> pair, the point of capture is defined as the mid-point between the >point of capture of the individual microphones. >>> .................. >>> >>> Regards, >>> >>> ...Paul >>> >>> _______________________________________________ From nobody Wed Jun 25 12:06:40 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA891B2E33 for ; Wed, 25 Jun 2014 12:06:31 -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 Bz8BRLJDeYgQ for ; Wed, 25 Jun 2014 12:06:29 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 02EA41B2E2C for ; Wed, 25 Jun 2014 12:06:28 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id JisL1o00A1GhbT854j6UzL; Wed, 25 Jun 2014 19:06:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id Jj6U1o00L3ZTu2S3Tj6U6i; Wed, 25 Jun 2014 19:06:28 +0000 Message-ID: <53AB1DB4.6070901@alum.mit.edu> Date: Wed, 25 Jun 2014 15:06:28 -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: CLUE 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=1403723188; bh=NU2uoZ0eHV8LvyOEzw2kpgIs6JiwmBD26dzCCQ5y3+Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a5Ftvqf3WT01tJ014w80pEX4wBFZFS9p75oFZr1dB1l88J6d4QLEDDpWRgyEFCtZq CHGP4Flb3PmS79CdDpJyA9f+gsjTxL3C87+wpvj+6CMY/cOx8MPfi6biUUqKrv8olb 6VhDEAMkf+nSWjkpd4C3xTMPxqG5HP+/nTdIiiw6dB1v4mbDoQWODJx45t3nTClkfJ bQGZhp3VnEXVok6dfu1zqjs4PWZ5TlOQEHTt9XkK3OcsqCZ/YEtZ6oUtLCJLzKdbDI 7D7vi8g4vs/+6gzK8BoZiV98Si79ZTN0j+h1PzfmmI8ash7+FR/LTfX1x69zSuCQaT r1rfVdIlBlByg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nfz9b0Km2oAoDhcOZX0H6vXl-9E Subject: [clue] Minutes posted for June 24 Design team mtg X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 19:06:31 -0000 You can find them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140624.txt Note that we have a session planned next week to discuss Signaling open issues. Thanks, Paul From nobody Thu Jun 26 10:50:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE71B2F81 for ; Thu, 26 Jun 2014 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxmfGa9u8uET for ; Thu, 26 Jun 2014 10:49:59 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCF11B2D49 for ; Thu, 26 Jun 2014 10:41:16 -0700 (PDT) Received: from [216.82.254.19:36511] by server-6.bemta-7.messagelabs.com id 4E/A9-09214-B3B5CA35; Thu, 26 Jun 2014 17:41:15 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-11.tower-96.messagelabs.com!1403804475!15673251!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31162 invoked from network); 26 Jun 2014 17:41:15 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-11.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2014 17:41:15 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 26 Jun 2014 10:41:15 -0700 From: "Duckworth, Mark" To: Paul Coverdale , 'Christian Groves' , "clue@ietf.org" Date: Thu, 26 Jun 2014 10:41:13 -0700 Thread-Topic: [clue] How to do deal with CLUE spatial audio aspects Thread-Index: Ac+OoCX4VxDxJzuFSCGyECobmxHCCQAR7Q8gAJ95bXA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19E89@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> <53A7B48F.4030405@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BXHiaZXBzJB6GYlHypsVGD9GelU Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:50:03 -0000 This seems reasonable to me. I'll also add this to the framework if nobody= objects. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale > Sent: Wednesday, June 25, 2014 1:50 PM > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] How to do deal with CLUE spatial audio aspects >=20 > Hi Christian, >=20 > I'm assuming such a description would go in the proposed new section > 7.1.1.x. I don't know what level of detail is appropriate, but here's som= e > possible text, although we really need a picture for clarity. >=20 > At the Consumer, the sensitivity pattern attribute may be combined with t= he > point of capture and point on line of capture (which together define the > major axis of the sensitivity pattern) to define a 3-dimensional volume o= f > capture where sounds can be expected to be picked up by the microphone > providing this specific audio capture. This volume can be compared with t= he > area of capture for video media to provide a check on whether the audio > capture is indeed appropriate for the video capture that it is supposed t= o be > associated with. For example, a video area of capture that fails to inter= sect at > all with the audio volume of capture, or is at such a long radial distanc= e from > the microphone point of capture that the audio level would be very low, > would be inappropriate. >=20 >=20 > Regards, >=20 > ..Paul >=20 > >-----Original Message----- > >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > >Sent: Monday, June 23, 2014 1:01 AM > >To: clue@ietf.org > >Subject: Re: [clue] How to do deal with CLUE spatial audio aspects > > > >Hello Paul, Mark, > > > >Paul: Thanks for providing the text. For the sensitivity pattern > >attribute is there some short description giving an example how it > >could be used by the Consumer? > > > >Mark: I agree with your suggestion. I think its better to capture the > >changes that way. > > > >Regards, Christian > > > >On 21/06/2014 4:48 AM, Duckworth, Mark wrote: > >> Thanks Paul, > >> > >> I agree with your suggestion, but I would like to add a new section > >7.1.1.x for the new sensitivity pattern attribute. Then split your > >proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of > >Capture and the new section. > >> > >> I can also update the section 12 examples that mention spatial > >information for audio. > >> > >> Mark > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>> Coverdale > >>> Sent: Thursday, June 19, 2014 10:46 AM > >>> To: clue@ietf.org > >>> Subject: [clue] How to do deal with CLUE spatial audio aspects > >>> > >>> Colleagues, > >>> > >>> Following up on the action from the Design Team meeting of June 17, > >>> I propose the following text to be added at the end of section > >>> 7.1.1.3 in the Framework document. > >>> > >>> ................ > >>> Note that area of capture is not a valid concept for audio. To > >>> capture spatial information related to audio, the point of capture > >>> and point on line of capture ( as defined in sections 7.1.1.1 and > >>> 7.1.1.2) may be used, along with another element defining the > >>> nominal sensitivity pattern of the microphone (bearing in mind that > >>> the actual microphone sensitivity pattern, in situ, may be somewhat > >>> different due to local obstacles). Nominal microphone sensitivity > >>> patterns to choose from include: Omni; Bi-directional; Cardioid; > >>> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone > >>> pair, the point of capture is defined as the mid-point between the > >point of capture of the individual microphones. > >>> .................. > >>> > >>> Regards, > >>> > >>> ...Paul > >>> > >>> _______________________________________________ >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jun 26 13:22:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668D41B2DEF for ; Thu, 26 Jun 2014 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9it3rP6G9Ap for ; Thu, 26 Jun 2014 13:22:27 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.202]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F0C1B2DCC for ; Thu, 26 Jun 2014 13:22:27 -0700 (PDT) Received: from [216.82.241.100:51361] by server-10.bemta-8.messagelabs.com id 49/D8-00513-2018CA35; Thu, 26 Jun 2014 20:22:26 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-220.messagelabs.com!1403814144!15889135!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20426 invoked from network); 26 Jun 2014 20:22:26 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2014 20:22:26 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 26 Jun 2014 13:22:24 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 26 Jun 2014 13:22:23 -0700 Thread-Topic: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt Thread-Index: Ac+J+mc0fnPKlYvQQXqIpgNQTb3o1AHa/Mdg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19EF4@CRPMBOXPRD08.polycom.com> References: <539FE86F.7000902@nteczone.com> In-Reply-To: <539FE86F.7000902@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YW6eVaEq4pNMLzcGeQ0aRbn3CXs Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:22:30 -0000 Hi Christian, Thanks for the detailed review. Responses inline. I plan to submit the next framework draft revision tomorrow, as I will be o= n vacation all next week. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, June 17, 2014 3:04 AM > To: clue@ietf.org > Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >=20 > Hello, >=20 > In summary I think its fairly good although the audio issue is still a wo= rry. [Duckworth, Mark] I think we worked that out, according to recent discussio= n on the list that confirms Paul Coverdale's proposal is the right way to g= o. > My comments: >=20 > Issues > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Cl.3 Advertisement: " the formatting of the media streams it can send" > can probably be deleted as we removed the encoding information. [Duckworth, Mark] I agree > Cl.3 Capture Encoding: How critical is the use of RTP for a capture encod= ing? I > would think anything defined to carry media would be appropriate, obvious= ly > RTP is the most used example. So perhaps we can change that to: ".... to = a > Media Consumer, e.g. via RTP." [Duckworth, Mark] I thought the scope was limited to RTP. If Paul and Mary= agree that RTP should be just an example here, that is okay with me. > Cl.3 Capture Scene: Is it really a region containing one or more capture > devices? The scene may not actually contain the capture device. I would > think it would be more appropriate to say something like "a structure > representing the region captured by one or more media captures..." [Duckworth, Mark] I agree > Cl.3 General: Do we need a term to describe when multiple Capture Scenes > are used to give an overall "picture" of the endpoint, i.e. GCSE? [Duckworth, Mark] I don't think we need a new term in section 3. > Cl.3 Media Consumer/Media Provider - Should this say MCU? [Duckworth, Mark] I think MCU is a type of middle box. This is described i= n section 4. I don't think this definition needs to change. > Cl.3 Model: Is this definition needed or valid in the current CLUE framew= ork? > The use of "model" in the draft doesn't appear to reflect this definition= . [Duckworth, Mark] I suggest we remove this definition. > Cl.3 Render: A rendered video may be as a result of multiple media. I > propose "... a representation from media..." [Duckworth, Mark] I agree > Cl.3 Single Media Capture: "i.e. audio capture, video capture" don't real= ly > represent a single capture they represent a "single capture type". I thin= k it > would be more correct to say "i.e. an audio capture from a single > microphone, a video capture from a single camera." [Duckworth, Mark] ok > Cl.5 para.2: Rather than say "formatting of the media streams" it should = say > something like "media stream encodings"? [Duckworth, Mark] I agree > Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE channel= is only > established later in the call. Either we could have "SHOULD" or say somet= hing > like "MUST occur when a CLUE channel is established in the call". [Duckworth, Mark] How about replace "MUST" with "typically"? > Cl.5 para.5: Is there a double definition of "media capture"? In this par= agraph > it says that a media capture describes the content. Whereas the definitio= n in > cl.3 says " Media Capture: a source of Media, such as from one or more > Capture Devices or constructed from other Media streams." There's nothing > about description of content here. [Duckworth, Mark] how about "A Media Capture (MC), such as audio or video, = has attributes to describe the content a Provider can send." > Cl.5 para.6: " A Consumer chooses which Media Captures it wants to receiv= e > from each Capture Scene." A Consumer doesn't have to choose any MCs > from a scene. I'd suggested replace "each" with "the", i.e. > "...receive from the Capture Scenes." [Duckworth, Mark] I agree > Cl.5 para.7 : "...media attributes of the Encodings" (and following text)= . This > can be deleted as these are not contained in the Advertisement any more. [Duckworth, Mark] I agree. The next paragraph also has "maximum video codi= ng performance measured in macroblocks/second", which I think should also b= e removed. > Cl.5 fig.1 : Does this need to be updated to remove maxBandWidth or at le= ast > move it to the encoding group level? Also does the global CSE need to be > added as a box like the STS? [Duckworth, Mark] Yes, I agree > Cl.5 pg.13 para.1: "Voice Activated Stream Switching" via updated CLUE > signalling is that something we've decided for CLUE? [Duckworth, Mark] I think the refers to the case where a Consumer can send = a new configure message asking for a different video capture using an alrea= dy defined encoding from SDP, without needing another SDP O/A because nothi= ng changes at the SDP level. If the consumer makes this choice based on au= dio information, that could be "voice activated screen switching" > Cl.5 pg.13 para.2: Do we need the sentence " Obviously, this is not a > particularly sensible design choice in almost all conceivable > cases."? [Duckworth, Mark] I don't mind removing this. Does anybody else think it s= hould remain? > Cl.7.1.1.8 : There's the note regarding the different types of presentati= on. Is > there any interest for values beyond "image" and "slides"? [Duckworth, Mark] in the data model, there should be a way to extend presen= tationType with more values. I don't know how this is done in XML to be ba= ckward compatible. > Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial = relationship > between scenes. However this paragraph is a little "fuzzy" > implying there may be relationship between scenes. Whilst physically ther= e > may a relationship a consumer has no way of knowing this. The default > behaviour will not be to associate scenes. [Duckworth, Mark] I don't see anything that implies a relationship between = scenes. Which sentences specifically do you mean? > Cl.9.1 para.3 : "The parameter of an Individual Encoding represent the > maximum values", is this the case now? As the individual encoding > parameter are now defined by SDP they could mean anything, not just > maximum values. I think this paragraph needs to be updated to reflect thi= s. [Duckworth, Mark] I think this whole paragraph should be deleted. > Cl.9.2: There is no explicit mention of whether individual encodings of > multiple media types i.e. audio and video can belong to a single group. [Duckworth, Mark] The data model restricts an encoding group to a particula= r media type. > Cl.10 para.2: I don't see the "special" handling outlined in this paragra= ph. A > consumer would have a separate CLUE channel with each provider and treat > the associations differently? [Duckworth, Mark] I don't understand your point. Do you think this paragra= ph is unnecessary? =20 > Cl.10 Pg.39 para.2: ", and includes the encoding parameter values" > should be deleted. A configure doesn't respond with these values. Also in > the paragraph below the text regarding parameters should be deleted also. [Duckworth, Mark] I agree > Cl.11 Para 1: Do we need the text about new industry and future direction= s? > Can't we just mention how the framework is extensible? [Duckworth, Mark] I agree we could remove that sentence. > Cl.11 bullet 3: New codecs should be added to SDP not CLUE. We could > remove this bullet. [Duckworth, Mark] I agree > Cl.13 : How much do you have to input to get a mention? (hint) [Duckworth, Mark] I've been meaning to update this section > Editorial > =3D=3D=3D=3D=3D=3D=3D=3D=3D > General: I think the draft would read better if constructions such as "is > sending" and "is receiving" are changed to "sends" and "receives", i.e. c= l.4 > para.2 "represents the entity that sends the media". "is not supporting" = =3D> > "does not support" >=20 > General: Defined terms "Provider", "Advertisement" etc. should have there > first character capitalized. >=20 > Cl.1 Para.1 : References to CLUE drafts can be updated to RFCs. >=20 > Cl.3 AudioCapture: ". Denoted as ACn in the examples in this document." >=20 > Cl.3 Font: "In going towards back..." >=20 > Cl.4 (1): The first part of the sentence talks about the past, so I sugge= st > changing "... for example, there was no mechanism..." >=20 > Cl.4 (2): Consistency "...are multiple capturing and rendering..." or "..= .are > multiple capture and render..." >=20 > Cl.7.1.1 Para.1: "... for the benefit of the Consumer the Advertisem= ent > message" or "A Provider can use the Media Capture Attributes in an > Advertisement to describe the Capture for the benefit of the Consumer". >=20 > Cl.7.1.1.7 Reword " The Description attribute is a human-readable descrip= tion > (which could be in multiple languages) of the Capture." > Otherwise it reads that the capture could be in multiple languages not th= e > description. (Similar comment to cl.7.3.2) >=20 > Cl.8 Pg.33 Para.2 : "...are shown in Table 1" =3D> "... are shown in Tabl= e 5." >=20 > Cl.9 "...please refer to section 4" =3D> "...please refer to section 5"? >=20 > Cl.10 para.4: "As a general outline, Consumer..." >=20 > Regards, Christian >=20 >=20 > On 7/06/2014 1:35 AM, Mary Barnes wrote: > > Hi all, > > > > As discussed at the interim meeting, this is a two week pre-WGLC > > review for the framework document: > > http://www.ietf.org/id/draft-ietf-clue-framework-15.txt > > > > The objective of this pre-WGLC review is for folks to take a fresh > > look at the document and re-review the entire document. Right now, > > there are just a couple outstanding issues: > > - #35 (consistency with the data model document) > > - audio issue (that still needs to be detailed by John Leslie) > > - issues reflected by editor's notes in the document for which we will > > open new tickets > > > > This review is intended to ensure that there are no other outstanding > > issues so that once we close the above open issues the document is > > ready for WGLC. > > > > Note, reviews that provide a general summary and then separate the > > major and minor issues from the editorial nits, something like the > > following, would be quite helpful. > > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > > > Major issues: > > > > Minor Issues: > > > > Editorial nits: > > > > Please review and send any comments to the mailing list no later than > > Friday, June 20th, 2014. > > > > Thanks, > > Mary. > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 27 03:10:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D21B2F54; Fri, 27 Jun 2014 03:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpr5WVXdz5-0; Fri, 27 Jun 2014 03:10:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1378F1B2B14; Fri, 27 Jun 2014 03:10:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627101021.20966.60589.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 03:10:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KXKczqUC5RlcEixidD74ti7-yJs Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:10:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-06.txt Pages : 54 Date : 2014-06-27 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 27 03:12:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE61B2F35 for ; Fri, 27 Jun 2014 03:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.528 X-Spam-Level: *** X-Spam-Status: No, score=3.528 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MANGLED_LOOK=2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y802NsEG-zk for ; Fri, 27 Jun 2014 03:12:44 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FB61B2CF5 for ; Fri, 27 Jun 2014 03:12:44 -0700 (PDT) X-ASG-Debug-ID: 1403863960-05f27516da8adc60001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id HB08IGaTtOjRHxSv (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2014 12:12:40 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([100.102.44.14]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s5RACbCm010420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Jun 2014 12:12:39 +0200 Message-ID: <53AD4395.5080708@unina.it> Date: Fri, 27 Jun 2014 12:12:37 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "clue@ietf.org" , Christian Groves References: <53A8F05E.6080902@nteczone.com> X-ASG-Orig-Subj: Review Groves al data model 05 [Re: [clue] Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] In-Reply-To: <53A8F05E.6080902@nteczone.com> Content-Type: multipart/alternative; boundary="------------010109060301080604050504" X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1403863960 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6991 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YdlJaZ3RU3G4S_a_ngIiDlQkJnM Subject: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:12:48 -0000 This is a multi-part message in MIME format. --------------010109060301080604050504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Christian, thank you for the review. We have prepared and uploaded a new version of the draft (06) including your corrections and suggestions. Il 24/06/2014 05:28, Christian Groves ha scritto: > how to update data model in the future? What method/process do we > need? Do we need to register updated attribute values with IANA etc? 1. We have added a new section about the schema extensibility. > > Specific comments: > ================== > > - Cl.1 Do we need to provide some link to the CLUE protocol document? > i.e. the XML schema is used by the protocol messages defined in > draft-ietf-clue-protocol. 2. We have started to add some reference in the Introduction. > > - Cl.1 3rd para: The paragraph sounds like a proposal. I would propose > to reword along the lines of: "This document defines a structure for > information associated with the description of a telepresence scenario." > 3. OK. We have corrected all the similar situations across the document. > - Cl.2: I think it would be good to separate terms from the framework > vs ones introduced in this document. i.e. the introduction sounds that > the terms all come from the framework. CLUE participant however isn't > defined by the framework. I haven't checked which other terms are > different. 4. OK. We have been clearer with respect to the separation by addind the following lines in the Terminology section introduction: "This document refers to the same terminology used in , except for the 'CLUE Participant' definition (which is still under discussion)." and by modifying the definition as below: "CLUE Participant: This term is not imported from the framework terminology and should be considered temporary since it is under review. We introduced it for the sake of simplicity in order to identify a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol." > - Cl.3 1st para: Can remove "proposed", e.g. "This section contains > the CLUE data ...." 5. OK. > > - Cl.3 2nd para: "... given the Provider's offer." Does this relate to > a SIP offer or CLUE advertisement? Maybe we could more CLUE specific > language "... given the Provider's Advertisement." > 6. OK. Replaced with "given the Media Provider's ADVERTISEMENT". > - Cl.10 : This still contains the composed and switched elements (also > applies to cl.3, cl.10.8, cl.10.9). These were removed from the > framework so should be removed here. > 7. Done. > - Cl.10.2: "Each each media capture must be associated with one and > only one capture scene", how about when the media capture is used in > an MCC? May it would be better to say "Each media capture must be > defined in one and only one capture but may be referenced by other > scenes through multiple content captures" or similar. > 8. Your text is clearer. We have replaced the existing one with the following lines: " is a mandatory field containing the identifier of the capture scene the media capture is defined in. Indeed, each media capture MUST be defined within one and only one capture scene." We have not added the part about MCCs, since MCCs are media captures as well. They are defined within one and only one capture scene and carry the capture scene identifier in the like ordinary media captures. They will show a field referencing the included media captures, where the included media captures can belong to other capture scenes, but this has not so much to do with the definition of the in Sec. 10.2. > - Cl.10.4: I guess this would need to be updated to take into account > that there's no capture area information associated with audio captures? 9. Yes, but we have not added anything in that part since framework-15 has not been updated yet. We would like also to restore Botzko's (perharps with a different name) as a further feature for audio captures, since it represents exactly the concept of sensitivity pattern proposed by Coverdale to improve the audio capture description: > > - Cl.10.7: "...coming from the same room endpoint". I propose to > remove "room". > 10. OK. > - Cl.10.11: MaxCaptures needs to be updated to reflect to "<=" and "=" > constructs added to the framework. 11. Right. We have update the defition of the element as copied below: is an optional element that can be used only for multiple content captures. It provides information about the number of media captures that can be represented in the multiple content capture at a time. The type definition is provided below. When the "exactNumber" attribute is set to "1", it means the element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" of the value. > > - Cl.10.16/General: There a reference to CLUE framework for a > definition of the behaviour of an element. However there's no > references for other elements. In general should we provide a > reference to the section in the framework that describes the attribute? > 12. I don't think we should, since it is stated more than once that each element reflects concepts presented in the framework document, and then we don't need to remark it. We have removed this reference. > - General: Do we need a statement about whether the framework or the > data model takes precedence regarding the definition of attributes? 13. I'm not sure we need such a statement in the data model. However, up to now, the data model has followed the news introduced in the framework. By looking at how we conceived them, they are strictly interconnected, so updates in one should be reflected (if necessary, i.e., if new elements are defined, or the existing one are changed in their structure) in updates in the companion document (independently from the precedence rule). > - General: Do we need some text regarding how to extend the data > model? e.g. what do I need to do if I want to add another value to the > presentationType. 14. We are preparing an example in order to explain how datamodel extensions can be managed to be included in Section "XML Schema Extensions" (cfr. bullet 1) - to appear. > > - Cl.10.21: I'm OK with the proposal. 15. OK (the element is a way to reference the Person Information and Person Type data about each participant captured in the media capture). Do the others think there is still discussion needed about it? > > - Cl.11: This needs to be updated to align with the framework > regarding the new audio parameters. > 16. Yes, we are ready to do it. > - Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"? > 17. We have nothing against it. What about the others?_ _ > - Cl.15.3: Do we need the mediaType attribute if mediaType is also an > attribute of the referenced media captures? We don't have a mediaType > for STSs. > 18. I have always used such an attribute in the definitions because, even if redundant, it can be useful for simplifying parsing (e.g., for rapidly filtering stss/cses/gses on the basis of the media type). However, I have removed them also in the other data types dealing with set of captures. > - Cl.18 : Is "mediaType" required when "globalSceneEntryID" isn't > included? 19. No, but there is a correction on that part. We have removed the mediaType attribute and set 'use="required"' for the globalSceneEntryID attribute. Other "use=required" specifications have been added to ID attributes in the schema file. > > - Cl.19.1 : "Such an element currently provides at least the vcard of > the person (via the element, see Section 19.1.2) and > optionally his conference role(s)." I think that these are > independent. The person Type may be provided without the need to > provide a vCard. There's no dependency in the framework. > 20. I have corrected the introduction. The XML definition was already coherent with what stated in the framework, I have just made the "personID" attribute mandatory. > - Cl.19.1.2: This clause makes reference to ietf-ecrit-additional-data > for the Xcard XML schema. What's the purpose of this? I thought a > reference to the Xcard RFC 6351 is sufficient however the definitions > of XML schemas is still a mystery. > 21. Actually draft-ietf-ecrit-additional-data is the source of the imported XML schema corresponding to the Relax NG schema in RFC 6351. We have left the reference, for the moment. > - Cl.20: "A possible solution to model...", I think we could strike > that sentence. I think we are defining "the" method. > 22. OK. Thank you again, Roberta ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille --------------010109060301080604050504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear Christian,

thank you for the review.
We have prepared and uploaded a new version of the draft (06) including your corrections and suggestions.

Il 24/06/2014 05:28, Christian Groves ha scritto:
how to update data model in the future? What method/process do we need? Do we need to register updated attribute values with IANA etc?
1. We have added a new section about the schema extensibility.

Specific comments:
==================

- Cl.1 Do we need to provide some link to the CLUE protocol document? i.e. the XML schema is used by the protocol messages defined in draft-ietf-clue-protocol.
2. We have started to add some reference in the Introduction.

- Cl.1 3rd para: The paragraph sounds like a proposal. I would propose to reword along the lines of: "This document defines a structure for information associated with the description of a telepresence scenario."

3. OK. We have corrected all the similar situations across the document.
- Cl.2: I think it would be good to separate terms from the framework vs ones introduced in this document. i.e. the introduction sounds that the terms all come from the framework. CLUE participant however isn't defined by the framework. I haven't checked which other terms are different.

4. OK. We have  been clearer with respect to the separation by addind the following lines in the Terminology section introduction:
"This document refers to the same terminology used in <xref target="I-D.ietf-clue-framework"/>, except for the 'CLUE Participant' definition (which is still under discussion)."
and by modifying the definition as below:
"CLUE Participant: This term is not imported from the framework terminology and should be considered temporary since it is under review.
We introduced it for the sake of simplicity in order to identify a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol."

- Cl.3 1st para: Can remove "proposed", e.g. "This section contains the CLUE data ...."
5. OK.

- Cl.3 2nd para: "... given the Provider's offer." Does this relate to a SIP offer or CLUE advertisement? Maybe we could more CLUE specific language "... given the Provider's Advertisement."

6. OK. Replaced with "given the Media Provider's ADVERTISEMENT".
- Cl.10 : This still contains the composed and switched elements (also applies to cl.3, cl.10.8, cl.10.9). These were removed from the framework so should be removed here.

7. Done.
- Cl.10.2: "Each each media capture must be associated with one and only one capture scene", how about when the media capture is used in an MCC? May it would be better to say "Each media capture must be defined in one and only one capture but may be referenced by other scenes through multiple content captures" or similar.

8. Your text is clearer. We have replaced the existing one with the following lines:
"<captureSceneIDREF> is a mandatory field  containing the identifier of the capture scene  the media capture is defined in.
Indeed, each media capture MUST be defined within one and only one capture scene."
We have not added the part about MCCs, since MCCs are media captures as well. They are defined within one and only one capture scene and carry the capture scene identifier in the <captureSceneIDREF> like ordinary media captures.
They will show a <content> field referencing the included media captures, where the included media captures can belong to other capture scenes, but this has not so much to do with the definition of the <captureSceneIDREF> in Sec. 10.2.

- Cl.10.4: I guess this would need to be updated to take into account that there's no capture area information associated with audio captures?
9. Yes, but we have not added anything in that part since framework-15 has not been updated yet.
We would like also to restore Botzko's <micPattern> (perharps with a different name) as a further feature for audio captures, since it represents exactly the concept of sensitivity pattern proposed by Coverdale to improve the audio capture description:
   <!-- MIC PATTERN TYPE -->
   <xs:simpleType name="micPatternType">
    <xs:restriction base="xs:string">
     <xs:enumeration value="uni"/>
     <xs:enumeration value="shotgun"/>
     <xs:enumeration value="omni"/>
     <xs:enumeration value="figure8"/>
     <xs:enumeration value="cardioid"/>
     <xs:enumeration value="hyper-cardioid"/>
    </xs:restriction>
   </xs:simpleType>

- Cl.10.7: "...coming from the same room endpoint". I propose to remove "room".

10. OK.
- Cl.10.11: MaxCaptures needs to be updated to reflect to "<=" and "=" constructs added to the framework.
11. Right. We have update the defition of the <maxCaptures> element as copied below:

<maxCaptures> is an optional element that can be used only for multiple content captures. It provides information about the number of media captures that can be represented in the multiple content capture at a time. The type definition is provided below. 

<!-- MAX CAPTURES TYPE -->
<xs:complexType name="maxCapturesType">
  <xs:simpleContent>
    <xs:extension base="xs:unsignedInt">
      <xs:attribute name="exactNumber" type="xs:boolean" />
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

When the "exactNumber" attribute is set to "1", it means the <maxCaptures> element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" of the <maxCaptures> value.


- Cl.10.16/General: There a reference to CLUE framework for a definition of the behaviour of an element. However there's no references for other elements. In general should we provide a reference to the section in the framework that describes the attribute?

12. I don't think we should, since it is stated more than once that each element reflects concepts presented in the framework document, and then we don't need to remark it.
We have removed this reference.
- General: Do we need a statement about whether the framework or the data model takes precedence regarding the definition of attributes?
13. I'm not sure we need such a statement in the data model.
However,  up to now, the data model has followed the news introduced in the framework.
By looking at how we conceived them, they are strictly interconnected, so updates in one should be reflected (if necessary, i.e., if new elements are defined, or the existing one are changed in their structure) in updates in the companion document (independently from the precedence rule).
- General: Do we need some text regarding how to extend the data model? e.g. what do I need to do if I want to add another value to the presentationType.
14. We are preparing an example in order to explain how datamodel extensions can be managed to be included in Section "XML Schema Extensions" (cfr. bullet 1) - to appear.

- Cl.10.21: I'm OK with the proposal.
15. OK (the element <capturedPeople> is a way to reference the Person Information and Person Type data about each participant captured in the media capture). Do the others think there is still discussion needed about it?

- Cl.11: This needs to be updated to align with the framework regarding the new audio parameters.

16. Yes, we are ready to do it.
- Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"?

17. We have nothing against it. What about the others?
- Cl.15.3: Do we need the mediaType attribute if mediaType is also an attribute of the referenced media captures? We don't have a mediaType for STSs.

18. I have always used such an attribute in the definitions because, even if redundant, it can be useful for simplifying parsing (e.g., for rapidly filtering stss/cses/gses on the basis of the media type).
However, I have removed them also in the other data types dealing with set of captures.
- Cl.18 : Is "mediaType" required when "globalSceneEntryID" isn't included?
19. No, but there is a correction on that part. We have removed the mediaType attribute and set 'use="required"' for the globalSceneEntryID attribute. Other "use=required" specifications have been added to ID attributes in the schema file.

- Cl.19.1 : "Such an element currently provides at least the vcard of the person (via the <personInfo> element, see Section 19.1.2) and optionally his conference role(s)." I think that these are independent. The person Type may be provided without the need to provide a vCard. There's no dependency in the framework.

20. I have corrected the introduction. The XML definition was already coherent with what stated in the framework, I have just made the "personID" attribute mandatory.
- Cl.19.1.2: This clause makes reference to ietf-ecrit-additional-data for the Xcard XML schema. What's the purpose of this? I thought a reference to the Xcard RFC 6351 is sufficient however the definitions of XML schemas is still a mystery.

21. Actually draft-ietf-ecrit-additional-data is the  source of the imported XML schema corresponding to the Relax NG schema in RFC 6351.
We have left the reference, for the moment.
- Cl.20: "A possible solution to model...", I think we could strike that sentence. I think we are defining "the" method.

22. OK.

Thank you again,

Roberta




   ­­   --------------010109060301080604050504-- From nobody Fri Jun 27 08:51:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892D31B2E8F for ; Fri, 27 Jun 2014 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 BwjSQjSVNh09 for ; Fri, 27 Jun 2014 08:51:54 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E182D1B2C00 for ; Fri, 27 Jun 2014 08:51:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5RFppni024436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Jun 2014 10:51:52 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5RFpoSn031606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jun 2014 17:51:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 27 Jun 2014 17:51:51 +0200 From: "DRAGE, Keith (Keith)" To: CLUE Thread-Topic: Review of the taxonomy draft from AVTEXT group Thread-Index: Ac+SH7TmA7H0g8ZgRYiI/ysvNAEcDg== Date: Fri, 27 Jun 2014 15:51:50 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1F7C5C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/vtmPIaC2cqW3fOtIT-kVXzqCSgM Subject: [clue] Review of the taxonomy draft from AVTEXT group X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:51:55 -0000 There has recently been some discussion of this draft in the CLUE list and = a new version has now been issued taking into account comments that Bo refl= ected to AVTEXT. Does this mean that CLUE WG has now reviewed this document sufficiently to = enable the taxonomy document to go to WGLC within the AVTEXT WG or does the= CLUE WG expect to perform further actions, and if so, what further actions= . Keith= From nobody Fri Jun 27 13:51:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9034B1A0135 for ; Fri, 27 Jun 2014 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuRKo41-7u1a for ; Fri, 27 Jun 2014 13:51:45 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395981A0118 for ; Fri, 27 Jun 2014 13:51:45 -0700 (PDT) Received: from [216.82.254.20:10061] by server-14.bemta-7.messagelabs.com id 71/76-04141-069DDA35; Fri, 27 Jun 2014 20:51:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1403902303!14160594!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27281 invoked from network); 27 Jun 2014 20:51:44 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jun 2014 20:51:44 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 27 Jun 2014 13:51:42 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 27 Jun 2014 13:51:41 -0700 From: "Duckworth, Mark" To: Roberta Presta Date: Fri, 27 Jun 2014 13:51:39 -0700 Thread-Topic: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] Thread-Index: Ac+R8F2sKDCMVMXXQN6s+02jYNLsLgAVbOow Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19FF3@CRPMBOXPRD08.polycom.com> References: <53A8F05E.6080902@nteczone.com> <53AD4395.5080708@unina.it> In-Reply-To: <53AD4395.5080708@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19FF3CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/y5m1i3Q1xkew5WaQ4PS5okVmg98 Cc: "clue@ietf.org" Subject: Re: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:51:47 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19FF3CRPMBOXPRD08p_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0YSwNCg0KSSBhZGRlZCBqdXN0IGEgZmV3IGNvbW1lbnRzIG9mIG15IG93bi4gIEkg Y3V0IG91dCB0aGUgcmVzdCBvZiB0aGUgY29udmVyc2F0aW9uIHdoaWNoIEkgYW0gbm90IGNvbW1l bnRpbmcgb24uDQpTb3JyeSBJIGRvbuKAmXQgaGF2ZSB0aW1lIHRvIGRvIGEgbW9yZSBjb21wbGV0 ZSBwcmUtV0dMQyByZXZpZXcgYmVmb3JlIHRoZSBkZWFkbGluZSwgYnV0IEkgZG8gcGxhbiB0byBk byBpdCBzb29uIGFmdGVyLg0KDQpJcyBpdCBwb3NzaWJsZSB0byBoYXZlIGEgbWVkaWEgY2FwdHVy ZSB0eXBlIHRoYXQgaXMgbm90IHZpZGVvIG9yIGF1ZGlvIG9yIHRleHQ/ICBDb3VsZCBpdCBiZSBk b25lIHVzaW5nIGp1c3QgdGhlIG1lZGlhQ2FwdHVyZVR5cGUgZ2VuZXJpYyBlbGVtZW50Pw0KDQpJ IHRob3VnaHQgd2UgYWdyZWVkIDxjYXB0dXJlUG9pbnQ+IHNob3VsZCBiZSBvcHRpb25hbCwgYW5k IHNvbWUgdGV4dCBhbmQgdGhlIFhNTCBmb3IgaXQgbmVlZHMgdG8gYmUgdXBkYXRlZC4gIFNlZSB0 aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBoZXJlOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2NsdWUvY3VycmVudC9tc2cwMzU5NC5odG1sDQoNClRoZSB0aXRsZSBwYWdlIHNh eXMg4oCcSW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFs4oCdLCBidXQgSSB0aGluayB0aGlz IHNob3VsZCBiZSBTdGFuZGFyZHMgVHJhY2suDQoNClJlZ2FyZHMsDQpNYXJrDQoNCkZyb206IGNs dWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnRhIFBy ZXN0YQ0KU2VudDogRnJpZGF5LCBKdW5lIDI3LCAyMDE0IDY6MTMgQU0NClRvOiBjbHVlQGlldGYu b3JnOyBDaHJpc3RpYW4gR3JvdmVzDQpTdWJqZWN0OiBbY2x1ZV0gUmV2aWV3IEdyb3ZlcyBhbCBk YXRhIG1vZGVsIDA1IFtSZTogUHJlLVdHTEM6IGRyYWZ0LWlldGYtY2x1ZS1kYXRhLW1vZGVsLXNj aGVtYS0wNS50eHRdDQoNCkRlYXIgQ2hyaXN0aWFuLA0KDQp0aGFuayB5b3UgZm9yIHRoZSByZXZp ZXcuDQpXZSBoYXZlIHByZXBhcmVkIGFuZCB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBk cmFmdCAoMDYpIGluY2x1ZGluZyB5b3VyIGNvcnJlY3Rpb25zIGFuZCBzdWdnZXN0aW9ucy4NCg0K DQotIENsLjEwLjIxOiBJJ20gT0sgd2l0aCB0aGUgcHJvcG9zYWwuDQoxNS4gT0sgKHRoZSBlbGVt ZW50IDxjYXB0dXJlZFBlb3BsZT4gaXMgYSB3YXkgdG8gcmVmZXJlbmNlIHRoZSBQZXJzb24gSW5m b3JtYXRpb24gYW5kIFBlcnNvbiBUeXBlIGRhdGEgYWJvdXQgZWFjaCBwYXJ0aWNpcGFudCBjYXB0 dXJlZCBpbiB0aGUgbWVkaWEgY2FwdHVyZSkuIERvIHRoZSBvdGhlcnMgdGhpbmsgdGhlcmUgaXMg c3RpbGwgZGlzY3Vzc2lvbiBuZWVkZWQgYWJvdXQgaXQ/DQpbRHVja3dvcnRoLCBNYXJrXSBJdCBs b29rcyBnb29kIHRvIG1lLiAgVG8gUGF1bOKAmXMgcHJldmlvdXMgcXVlc3Rpb24sIHRoZSDigJxw ZXJzb25UeXBlVHlwZeKAnSBpcyBvayB3aXRoIG1lLg0KDQoNCi0gQ2wuMTQuNDogUGVyaGFwcyB3 ZSBjYW4gdXNlIHRoZSBTSSBub3RhdGlvbiBvZiAibW0iIGZvciAibWlsbGltZXRlcnMiPw0KMTcu IFdlIGhhdmUgbm90aGluZyBhZ2FpbnN0IGl0LiBXaGF0IGFib3V0IHRoZSBvdGhlcnM/DQpbRHVj a3dvcnRoLCBNYXJrXSBJ4oCZbSBpbiBmYXZvciBvZiB1c2luZyDigJxtbeKAnSBmb3IgdGhlIGVu dW1lcmF0aW9uIHZhbHVlLg0KDQotIENsLjE5LjEgOiAiU3VjaCBhbiBlbGVtZW50IGN1cnJlbnRs eSBwcm92aWRlcyBhdCBsZWFzdCB0aGUgdmNhcmQgb2YgdGhlIHBlcnNvbiAodmlhIHRoZSA8cGVy c29uSW5mbz4gZWxlbWVudCwgc2VlIFNlY3Rpb24gMTkuMS4yKSBhbmQgb3B0aW9uYWxseSBoaXMg Y29uZmVyZW5jZSByb2xlKHMpLiIgSSB0aGluayB0aGF0IHRoZXNlIGFyZSBpbmRlcGVuZGVudC4g VGhlIHBlcnNvbiBUeXBlIG1heSBiZSBwcm92aWRlZCB3aXRob3V0IHRoZSBuZWVkIHRvIHByb3Zp ZGUgYSB2Q2FyZC4gVGhlcmUncyBubyBkZXBlbmRlbmN5IGluIHRoZSBmcmFtZXdvcmsuDQoyMC4g SSBoYXZlIGNvcnJlY3RlZCB0aGUgaW50cm9kdWN0aW9uLiBUaGUgWE1MIGRlZmluaXRpb24gd2Fz IGFscmVhZHkgY29oZXJlbnQgd2l0aCB3aGF0IHN0YXRlZCBpbiB0aGUgZnJhbWV3b3JrLCBJIGhh dmUganVzdCBtYWRlIHRoZSAicGVyc29uSUQiIGF0dHJpYnV0ZSBtYW5kYXRvcnkuDQpbRHVja3dv cnRoLCBNYXJrXSBDYW4gdGhlcmUgcmVhbGx5IGJlIG1vcmUgdGhhbiBvbmUg4oCccGVyc29uSW5m b+KAnSB2Y2FyZCBpbiBhIHBlcnNvblR5cGU/DQoNCg0KDQpUaGFuayB5b3UgYWdhaW4sDQoNClJv YmVydGENCg0KDQoNCi0tLS0NCjV4MTAwMCBBSSBHSU9WQU5JIFJJQ0VSQ0FUT1JJDQpERUxMJ1VO SVZFUlNJVEEnIERJIE5BUE9MSQ0KQ29kaWNlIEZpc2NhbGU6IDAwODc2MjIwNjMzDQp3d3cudW5p bmEuaXQvVmFkZW1lY3VtNXBlcm1pbGxlPGh0dHA6Ly93d3cudW5pbmEuaXQvVmFkZW1lY3VtNXBl cm1pbGxlPg0KICDCrcKtDQo= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19FF3CRPMBOXPRD08p_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5 IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkhpIFJvYmVydGEsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFkZGVkIGp1c3QgYSBmZXcgY29tbWVu dHMgb2YgbXkgb3duLsKgIEkgY3V0IG91dCB0aGUgcmVzdCBvZiB0aGUgY29udmVyc2F0aW9uIHdo aWNoIEkgYW0gbm90IGNvbW1lbnRpbmcgb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvcnJ5IEkgZG9u4oCZdCBoYXZlIHRp bWUgdG8gZG8gYSBtb3JlIGNvbXBsZXRlIHByZS1XR0xDIHJldmlldyBiZWZvcmUgdGhlIGRlYWRs aW5lLCBidXQgSSBkbyBwbGFuIHRvIGRvIGl0IHNvb24gYWZ0ZXIuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JcyBpdCBwb3NzaWJsZSB0byBoYXZlIGEgbWVkaWEgY2FwdHVyZSB0eXBlIHRoYXQgaXMgbm90 IHZpZGVvIG9yIGF1ZGlvIG9yIHRleHQ/wqAgQ291bGQgaXQgYmUgZG9uZSB1c2luZyBqdXN0IHRo ZSBtZWRpYUNhcHR1cmVUeXBlIGdlbmVyaWMgZWxlbWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkg dGhvdWdodCB3ZSBhZ3JlZWQgJmx0O2NhcHR1cmVQb2ludCZndDsgc2hvdWxkIGJlIG9wdGlvbmFs LCBhbmQgc29tZSB0ZXh0IGFuZCB0aGUgWE1MIGZvciBpdCBuZWVkcyB0byBiZSB1cGRhdGVkLsKg IFNlZSB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBoZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJyZW50L21zZzAzNTk0Lmh0bWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlRoZSB0aXRsZSBwYWdlIHNheXMg4oCcSW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1h dGlvbmFs4oCdLCBidXQgSSB0aGluayB0aGlzIHNob3VsZCBiZSBTdGFuZGFyZHMgVHJhY2suPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NYXJrPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gY2x1ZSBbbWFpbHRvOmNs dWUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnRhIFByZXN0YTxi cj48Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDI3LCAyMDE0IDY6MTMgQU08YnI+PGI+VG86PC9i PiBjbHVlQGlldGYub3JnOyBDaHJpc3RpYW4gR3JvdmVzPGJyPjxiPlN1YmplY3Q6PC9iPiBbY2x1 ZV0gUmV2aWV3IEdyb3ZlcyBhbCBkYXRhIG1vZGVsIDA1IFtSZTogUHJlLVdHTEM6IGRyYWZ0LWll dGYtY2x1ZS1kYXRhLW1vZGVsLXNjaGVtYS0wNS50eHRdPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5EZWFyIENocmlzdGlhbiwgPGJyPjxicj50aGFuayB5b3UgZm9yIHRo ZSByZXZpZXcuPGJyPldlIGhhdmUgcHJlcGFyZWQgYW5kIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24g b2YgdGhlIGRyYWZ0ICgwNikgaW5jbHVkaW5nIHlvdXIgY29ycmVjdGlvbnMgYW5kIHN1Z2dlc3Rp b25zLjxicj48YnI+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj4t IENsLjEwLjIxOiBJJ20gT0sgd2l0aCB0aGUgcHJvcG9zYWwuIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD4xNS4gT0sgKHRoZSBlbGVtZW50ICZsdDtjYXB0dXJlZFBlb3BsZSZndDsg aXMgYSB3YXkgdG8gcmVmZXJlbmNlIHRoZSBQZXJzb24gSW5mb3JtYXRpb24gYW5kIFBlcnNvbiBU eXBlIGRhdGEgYWJvdXQgZWFjaCBwYXJ0aWNpcGFudCBjYXB0dXJlZCBpbiB0aGUgbWVkaWEgY2Fw dHVyZSkuIERvIHRoZSBvdGhlcnMgdGhpbmsgdGhlcmUgaXMgc3RpbGwgZGlzY3Vzc2lvbiBuZWVk ZWQgYWJvdXQgaXQ/PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bRHVj a3dvcnRoLCBNYXJrXSBJdCBsb29rcyBnb29kIHRvIG1lLsKgIFRvIFBhdWzigJlzIHByZXZpb3Vz IHF1ZXN0aW9uLCB0aGUg4oCccGVyc29uVHlwZVR5cGXigJ0gaXMgb2sgd2l0aCBtZS48bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4t IENsLjE0LjQ6IFBlcmhhcHMgd2UgY2FuIHVzZSB0aGUgU0kgbm90YXRpb24gb2YgJnF1b3Q7bW0m cXVvdDsgZm9yICZxdW90O21pbGxpbWV0ZXJzJnF1b3Q7PyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+MTcuIFdlIGhhdmUgbm90aGluZyBhZ2FpbnN0IGl0LiBXaGF0IGFib3V0IHRo ZSBvdGhlcnM/PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48aT48 dT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltEdWNrd29ydGgsIE1hcmtdPC9zcGFuPjwvdT48L2k+ PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IEnigJltIGluIGZhdm9yIG9mIHVzaW5n IOKAnG1t4oCdIGZvciB0aGUgZW51bWVyYXRpb24gdmFsdWUuPC9zcGFuPjwvaT48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPi0gQ2wuMTkuMSA6ICZxdW90O1N1Y2gg YW4gZWxlbWVudCBjdXJyZW50bHkgcHJvdmlkZXMgYXQgbGVhc3QgdGhlIHZjYXJkIG9mIHRoZSBw ZXJzb24gKHZpYSB0aGUgJmx0O3BlcnNvbkluZm8mZ3Q7IGVsZW1lbnQsIHNlZSBTZWN0aW9uIDE5 LjEuMikgYW5kIG9wdGlvbmFsbHkgaGlzIGNvbmZlcmVuY2Ugcm9sZShzKS4mcXVvdDsgSSB0aGlu ayB0aGF0IHRoZXNlIGFyZSBpbmRlcGVuZGVudC4gVGhlIHBlcnNvbiBUeXBlIG1heSBiZSBwcm92 aWRlZCB3aXRob3V0IHRoZSBuZWVkIHRvIHByb3ZpZGUgYSB2Q2FyZC4gVGhlcmUncyBubyBkZXBl bmRlbmN5IGluIHRoZSBmcmFtZXdvcmsuIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD4yMC4gSSBoYXZlIGNvcnJlY3RlZCB0aGUgaW50cm9kdWN0aW9uLiBUaGUgWE1MIGRlZmluaXRp b24gd2FzIGFscmVhZHkgY29oZXJlbnQgd2l0aCB3aGF0IHN0YXRlZCBpbiB0aGUgZnJhbWV3b3Jr LCBJIGhhdmUganVzdCBtYWRlIHRoZSAmcXVvdDtwZXJzb25JRCZxdW90OyBhdHRyaWJ1dGUgbWFu ZGF0b3J5LjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+W0R1Y2t3b3J0 aCwgTWFya10gQ2FuIHRoZXJlIHJlYWxseSBiZSBtb3JlIHRoYW4gb25lIOKAnHBlcnNvbkluZm/i gJ0gdmNhcmQgaW4gYSBwZXJzb25UeXBlPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4yNXB0Jz48YnI+PGJyPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn Pjxicj5UaGFuayB5b3UgYWdhaW4sPGJyPjxicj5Sb2JlcnRhPGJyPjxicj48YnI+PGJyPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPi0tLS08YnI+NXgxMDAwIEFJIEdJT1ZBTkkgUklDRVJDQVRPUkk8YnI+REVM TCdVTklWRVJTSVRBJyBESSBOQVBPTEk8YnI+Q29kaWNlIEZpc2NhbGU6IDAwODc2MjIwNjMzPGJy Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxh IGhyZWY9Imh0dHA6Ly93d3cudW5pbmEuaXQvVmFkZW1lY3VtNXBlcm1pbGxlIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+d3d3LnVuaW5hLml0L1ZhZGVtZWN1bTVwZXJtaWxsZTwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDsmbmJzcDvCrcKtJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078AD19FF3CRPMBOXPRD08p_-- From nobody Fri Jun 27 14:19:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A701A019D; Fri, 27 Jun 2014 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty20aePhiN_7; Fri, 27 Jun 2014 14:19:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFB61A0197; Fri, 27 Jun 2014 14:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627211903.10835.8560.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 14:19:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6ndG1R3ijlq32HVJhqSYtPbmcDQ Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 21:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-16.txt Pages : 77 Date : 2014-06-27 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 29 17:22:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7150B1A006E for ; Sun, 29 Jun 2014 17:22:56 -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 SCAlXPNAySGA for ; Sun, 29 Jun 2014 17:22:54 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 043C01A0065 for ; Sun, 29 Jun 2014 17:22:53 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id LQEk1o0041ei1Bg58QNtsQ; Mon, 30 Jun 2014 00:22:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id LQNs1o00d3ZTu2S3kQNtS0; Mon, 30 Jun 2014 00:22:53 +0000 Message-ID: <53B0ADDC.5060706@alum.mit.edu> Date: Sun, 29 Jun 2014 20:22:52 -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: clue@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=1404087773; bh=MgyWxE4zFYllF5xIel3HPzq6TzPHwPbSRpSeDtgpkxM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DMrL9gFT/pTl3n9N+cyF9861cmpmAR3eTs5uJudDZN/5pWDvzRUPcVUhGEhkkzVp4 x4cE6/1LlLeAQCfZryEOTXTQ8MeVHP+Yc76Bo/Eei44P3pF+AqYJdoD+RFnn67s7X6 CegITofppUyvnZHSIi54rpSzrqiQa9GJLvYWC4ftvtpMvZVB0WbhUAnfB43vaKX/P1 6r71avdP52Mltwr8xKzOwY7mbjiCqk8pzuwNoirq/t2yrBftVO+Wm120jLRQf0XhWf nn12ekHU+y5h55UfZ5wdxCexYeQ+Nxd9Jg/BKbCBh3h5Rj0wp5CyQUQnrQn6ZOekXc 2cBMLT8jbKURA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LO5Z31uObBs7_H4CnoMZinZ1jB4 Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 00:22:56 -0000 I apologize for being late with my own pre-WGLC review comments on this. I ended up spending a lot more time on it than I allotted. (And I procrastinated.) Also, I know there are some overlaps between my comments and Christians. I've left them in because it is easier than removing them and I may have some different nuances. And here I am speaking as an individual, not a chair. References: There is no separate section for References. They are found at the end of the "Changes since last version" section. I assume this is a bug. Section 1: In the following: The signaling details and data model are provided in subsequent documents. ISTM that the documents aren't "subsequent", in that there is no natural ordering relationship among them. I suggest "separate" (or "companion") documents. E.g., Companion documents describe signaling details [reference] and the data model. [reference] (These documents aren't currently in the references.) Section 3: Re Capture Device: Capture Device: A device that converts audio and video input into an electrical signal, in most cases to be fed into a media encoder. This definition only applies to audio and video. (E.g., it excludes real-time text.) The grouping taxonomy defines it as: a physical entity performing a Media Capture transformation. Re Capture Encoding: Can we relate this directly to the grouping taxonomy? The taxonomy already does so, saying it is a term to describe an Encoded Stream I'm not certain this is quite right - I think the description is of more than the Encoded stream - maybe a "Source RTP Stream". Whatever we decide, we should ensure that the fw and the taxonomy are updated to be consistent. Re Endpoint: I think we could align better with the taxonomy. (We are pretty close.) Re Front: Front: the portion of the room closest to the cameras. In going towards back you move away from the cameras. Do we need this? It is only referenced once, in the definition of spatial relationships. Also, unless all the cameras are placed on the same side of the room it is not unique. (There is a separate Front for each camera.) Re MCU: The taxonomy now has what seems to be a good definition of MCU. Can we refer to that one? We may have to specialize the definition for our purposes - requiring that it support CLUE. (That might mean we need to have a different name, such as CLUE MCU.) Re Media Capture: Our definition differs from the taxonomy in a significant way. Ours describes it as a form of "data" while the taxonomy describes it as a process. I'm not quite sure what to recommend for aligning these. I suspect one or the other needs to be renamed. Re Media Consumer: Media Consumer: an Endpoint or middle box that receives Media streams I think "Media Streams" is too general here. I suggest: Media Consumer: an Endpoint or middle box that is capable of receiving Media Encodings. Re Media Provider: Similar to above I suggest: Media Provider: an Endpoint or middle box that is capable of sending Media Encodings. Re Multiple Content Capture: This is limited to audio and video. Couldn't we potentially have an MCC for switched or mixed real-time text? How about: Multiple Content Capture: A Capture that mixes and/or switches other Captures of a single type. (E.g. all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Instead of just mentioning that MCCn may be used in examples, shouldn't we actually define MCC as an abbreviation? Re Stream: Can we relate this to the taxonomy? I think this corresponds to both a "Source RTP Stream" and a "Received RTP Stream". Re Middlebox: This term isn't defined but it is used. I think it deserves a definition. Section 4: The following: ... In a few circumstances, a CLUE Endpoint middlebox includes only Consumer or Provider functionality, such as recorder-type Consumers or webcam-type Providers. ... I *think* this should say "Endpoint *or* middlebox". Section 5: The following: This Advertisement and Configure MUST occur during call initiation but MAY also happen at any time throughout the call, whenever there is a change in what the Consumer wants to receive or (perhaps less common) the Provider can send. seems overly restrictive. This need not occur during *call* initiation. It is possible to initiate a call, but not enable clue until later. How about: This Advertisement and Configure MUST occur once use of CLUE has been enabled in a call, but MAY also happen at any time throughout the call, whenever there is a change in what the Consumer wants to receive or (perhaps less common) the Provider can send. Figure 1 doesn't include the Global Capture Scene Entry List. Section 6 says: X increases from Camera-Left to Camera-Right Y increases from front to back (Also see my comment on the definition of "Front".) Defining the coordinates relative to a camera is problematic since there can be multiple cameras. (Consider case where we have cameras facing the audience and others facing speakers in front of the audience.) I'm not sure we can say anything better than that the X,Y coordinates should be chosen to be sensible for the set of captures to be offered. Perhaps an example where all the cameras point in generally the same direction would get the point across. Section 7.1.1: Isn't mono/stereo now gone as a capture attribute? Section 7.1.1.2: Perhaps we should say that the Point on Line of Capture actually defines not just the axis, but a vector indicating the direction of capture? Section 7.1.1.3: I guess some restructuring is needed to limit area of capture to video. Section 7.1.1.5: Didn't we agree to remove this. (That it will be handled as part of an encoding.) Section 7.2.1.2: The explanation of 'index' is pretty fuzzy. ISTM that the meaning really needs to be specified separately for each token. E.g., for SoundLevel N means the N'th most recent loudest speaker. For RoundRobin it is harder to describe. Section 7.2.1.3: I have read this several times, and while I know this is about site switching I cannot figure it out from the words written here. Even the example isn't helping me (and I don't think it should take an example to make it understandable.) For instance, ISTM that the synchronization id and the policy can give conflicting criteria for what is included at each point in time. And also the max captures may define a composition policy that would violate the synchronization. Section 7.3: I have a question: Can a scene have captures that are not included in any CSE? If not, then there probably ought to be something that says that. If so, then there are other issues. If so, then presumably it should be possible to have scenes with no CSEs. (Did we have this discussion previously?) I suggest that the following: ... A Capture Scene includes one or more Capture Scene entries, with each entry including one or more Media Captures. ... be tweaked by: s/Media Captures/Media Captures of the same media type/ In the following: A provider MAY express spatial relationships between Captures that are included in the same Capture Scene. However, there is not necessarily the same spatial relationship between Media Captures that are in different Capture Scenes. In other words, Capture Scenes can use their own spatial measurement system as outlined above in section 6. saying capture scenes *can* user their own spatial measurement system suggests the contrary is a possibility - that they may share a spatial measurement system. That isn't really true. We assume that each scene is spatially unrelated to every other scene. So I suggest revising this as: A provider MAY express spatial relationships between Captures that are included in the same Capture Scene. However, there is no spatial relationship between Media Captures from different Capture Scenes. In other words, Capture Scenes each use their own spatial measurement system as outlined above in section 6. While reading this section I find Capture Scene *Entry* to be a poor name for what it represents. ISTM that each CSE selects a set of captures that, together, represent a view of the entire scene. (Some better than others.) I think a better name for this would be *Scene View*. (I realize that while only a nomenclature change, this is a fundamental element we use in talking to one another and so is mentally hard to change. But I think we at least ought to consider it as making clue more understandable to outsiders. And of course we can consider other names.) Making such a change would of course result in renaming a number of other things. I won't call those out specifically. Section 7.3.3: The following isn't quite right: ... Each item in this list is a set of one or more Capture Scene Entries of the same media type. ... I can read this and think that CSEs are actually contained in this. It is important that what is included are *references* to CSEs defined in scenes. So I suggest: ... Each item in this list is a set of references to one or more of the Capture Scene Entries of the same media type that are defined within scenes of the same advertisement. ... And, in line with my comment about the naming of CSE, I think we can find a more understandable name for this thing than Global CSE List. (IIRC the current name was my idea.) I'm thinking *Global View* would work as the name for one element of this list. And then I guess the list of them would be *Global View List*. If we did all that, then 7.3.3 would start out as: 7.3.3. Global View List An advertisement can include an optional Global View List. Each item in this list is a Global View. Each Global View is a set of one or more references to Scene Views of the same media type, defined within scenes of the same advertisement. Each Global View is a suggestion from the Provider to the Consumer for some Scene Views that provide a complete view of the simultaneous captures provided by the provider, across the multiple scenes of the advertisement. The Provider can include a Global View List to help a consumer to choose sets of captures appropriate to its capabilities or application. The choice of how to make these suggestions in the Global View List, for what represents all the scenes for which the provider can send media, is up to the provider. This is very similar to how each Scene View represents a particular scene. (But we would certainly add Global View to the definitions, and so part of the above might appear there rather than here.) Section 8: The following: ... If a Capture Scene is included in a Simultaneous Transmission Set, then all its Capture Scene Entries (of the corresponding media type) are included in the Simultaneous Transmission Set. ... implies that there is some mechanism to determine the media type of the simultaneous transmission set. Currently it is only determined by the type of its entries. But if all the entries are scenes, then that isn't good enough. I can think of a variety of fixes for this. We should discuss how to fix this. I find the following ambiguous or at least hard to understand: If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to provide all Capture Scenes simultaneously. If multiple capture Scene Entries are in a Capture Scene then the Consumer chooses at most one Capture Scene Entry per Capture Scene for each media type. Likewise, if there are no Simultaneous Transmission Sets and there is a global CSE list, then the Consumer chooses at most one set of CSEs of each media type, from the global CSE list. It switches from what the provider MUST do (be able to provide all capture scenes simultaneously), to what the consumer does, which doesn't seem to be normative. What is missing is a definition of what it means to be able to provide a capture scene. I think "be able to provide a capture scene" means: be able to simultaneously provide all of the captures in any single CSE of the scene. If that is right, then the question is how to write that as a clear normative statement. Either we can try to come up with text that says the above, or else we could say that there is a default simultaneous transmission set and come up with an algorithm to derive it from the CSEs in the advertisement. (The algorithm is straightforward, but describing it in text is not.) Here is a cut at the text: If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to simultaneously provide all the captures from any one CSE of each media type from each capture scene. Section 9.3: I have some concerns with the first paragraph: Each Media Capture MAY be associated with at least one Encoding Group, which is used to instantiate that Capture into one or more Capture Encodings. Typically MCCs are assigned an Encoding Group and thus become a Capture Encoding. The Captures (including other MCCs) referenced by the MCC do not need to be assigned to an Encoding Group. This means that all the Media Captures referenced by the MCC will appear in the Capture Encoding according to any MCC attributes. This allows an Advertiser to specify Capture attributes associated with the Media Captures without the need to provide an individual Capture Encoding for each of the inputs. The construction "MAY be associated with at least one" seems awkward, and doesn't not the key point that if a capture is to be eligible for configuration it MUST be associated with at least one. And then, "Typically MCCs are assigned an Encoding Group and thus become a Capture Encoding" implies that the assignment of the MCC to an encoding group *causes* to become a Capture Encoding, which isn't right. I think the following clarifies both of those points: Each Media Capture, including MCCs, MAY be associated with one or more Encoding Groups. To be eligible for configuration, a Media Capture MUST be associated with at least one Encoding Group, which is used to instantiate that Capture into one or more Capture Encodings. When an MCC is configured all the Media Captures referenced by the MCC will appear in the Capture Encoding according to the attributes of the chosen encoding of the MCC. This allows an Advertiser to specify encoding attributes associated with the Media Captures without the need to provide an individual Capture Encoding for each of the inputs. Section 10: Some of the text in this section is out of date with changes we have made along the way. This is most obvious in: For each Capture the Consumer wants to receive, it configures one or more of the encodings in that capture's encoding group. The Consumer does this by telling the Provider, in its Configure Message, parameters such as the resolution, frame rate, bandwidth, etc. for each Capture Encodings for its chosen Captures. ... This suggests that resolution, frame rate, bandwidth, etc. are specified as part of the Configure, which is no longer true. (I have been getting a similar feeling in earlier sections, but in each case I could read it as ok, because "parameters" could mean other things.) For the moment I'm not going to suggest a specific fix. It could be fixed "here" with some minor rewording. But if we want to fix it document wide then that should be done in a unified way. And related to that is: In order to meaningfully create and send an initial Configure, the Consumer needs to have received at least one Advertisement from the Provider. It is now also necessary to have received an offer defining encodings of the captures of interest to the consumer. I think some rewording is required. Section 12.1.1: Area of Capture needs to come out for the audio captures, replaced by point of capture and point on line of capture. More important, based on our audio discussions, does it make sense to provide separate audio captures for each camera? If not, what does make sense? Perhaps just a single mono audio, a single surround sound audio, and an audio for the presentation? There is a reference to MCC5, which is not defined. Section 12.2: This says: A sane, basic, algorithm might be for the consumer to go through each Capture Scene in turn and find the collection of Video Captures that best matches the number of screens it has ... But this doesn't say anything about CSEs - implying that ignoring them is sensible. It is *possible*, but explaining how to decide in that case is very complex. I would think for the purposes here we would want to recommend going through the CSEs looking for one that best exploits the locally available equipment. Did the above mean to say "... go through each CSE in turn ..."? Section 12.3.1: Table 14 doesn't leave the consumer with much choice. For instance there is no choice that works for a consumer that can handle only one video stream. ISTM that it would be better to merge tables 13 and 14, so that the consumer can have both one-encoding and two-encoding options. Section 12.3.3: The following appears after Table 20: Rather than considering what is displayed the CLUE concentrates more on what the MCU sends. The MCU doesn't know anything about the number of screens an endpoint has. Something is wrong with this - "the CLUE" makes no sense. Should "the" be omitted, or was "this example" intended? I also see a reference to section 7.3.2 that isn't linked (in the html) to the actual section. Perhaps it is by value rather than reference in the source??? Section 15: There is a reference to "section x", that needs to be updated to reference to proper section. THE END Thanks, Paul On 6/6/14 11:35 AM, Mary Barnes wrote: > Hi all, > > As discussed at the interim meeting, this is a two week pre-WGLC review > for the framework document: > http://www.ietf.org/id/draft-ietf-clue-framework-15.txt > > The objective of this pre-WGLC review is for folks to take a fresh look > at the document and re-review the entire document. Right now, there are > just a couple outstanding issues: > - #35 (consistency with the data model document) > - audio issue (that still needs to be detailed by John Leslie) > - issues reflected by editor's notes in the document for which we will > open new tickets > > This review is intended to ensure that there are no other outstanding > issues so that once we close the above open issues the document is ready > for WGLC. > > Note, reviews that provide a general summary and then separate the major > and minor issues from the editorial nits, something like the following, > would be quite helpful. > Summary: (e.g., Needs Work, Almost Ready, Ready, etc) > > Major issues: > > Minor Issues: > > Editorial nits: > > Please review and send any comments to the mailing list no later than > Friday, June 20th, 2014. > > Thanks, > Mary. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jun 29 19:20:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE11A00D8 for ; Sun, 29 Jun 2014 19:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 kOpFnmagim8S for ; Sun, 29 Jun 2014 19:20:31 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7491A00D5 for ; Sun, 29 Jun 2014 19:20:30 -0700 (PDT) Received: from 124-110-22-114.east.fdn.vectant.ne.jp ([124.110.22.114]:30373 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1RBq-0000px-4i; Mon, 30 Jun 2014 12:19:30 +1000 Message-ID: <53B0C967.2060003@nteczone.com> Date: Mon, 30 Jun 2014 12:20:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , Paul Coverdale , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F012102B9@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F012EF405@CRPMBOXPRD08.polycom.com> <53A7B48F.4030405@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19E89@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19E89@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GMamEV6QztD4Ppa9n612KM3uxC0 Subject: Re: [clue] How to do deal with CLUE spatial audio aspects X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 02:20:35 -0000 Hello Paul, It sounds good. Regards, Christian On 27/06/2014 3:41 AM, Duckworth, Mark wrote: > This seems reasonable to me. I'll also add this to the framework if nobody objects. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale >> Sent: Wednesday, June 25, 2014 1:50 PM >> To: 'Christian Groves'; clue@ietf.org >> Subject: Re: [clue] How to do deal with CLUE spatial audio aspects >> >> Hi Christian, >> >> I'm assuming such a description would go in the proposed new section >> 7.1.1.x. I don't know what level of detail is appropriate, but here's some >> possible text, although we really need a picture for clarity. >> >> At the Consumer, the sensitivity pattern attribute may be combined with the >> point of capture and point on line of capture (which together define the >> major axis of the sensitivity pattern) to define a 3-dimensional volume of >> capture where sounds can be expected to be picked up by the microphone >> providing this specific audio capture. This volume can be compared with the >> area of capture for video media to provide a check on whether the audio >> capture is indeed appropriate for the video capture that it is supposed to be >> associated with. For example, a video area of capture that fails to intersect at >> all with the audio volume of capture, or is at such a long radial distance from >> the microphone point of capture that the audio level would be very low, >> would be inappropriate. >> >> >> Regards, >> >> ..Paul >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: Monday, June 23, 2014 1:01 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] How to do deal with CLUE spatial audio aspects >>> >>> Hello Paul, Mark, >>> >>> Paul: Thanks for providing the text. For the sensitivity pattern >>> attribute is there some short description giving an example how it >>> could be used by the Consumer? >>> >>> Mark: I agree with your suggestion. I think its better to capture the >>> changes that way. >>> >>> Regards, Christian >>> >>> On 21/06/2014 4:48 AM, Duckworth, Mark wrote: >>>> Thanks Paul, >>>> >>>> I agree with your suggestion, but I would like to add a new section >>> 7.1.1.x for the new sensitivity pattern attribute. Then split your >>> proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of >>> Capture and the new section. >>>> I can also update the section 12 examples that mention spatial >>> information for audio. >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>> Coverdale >>>>> Sent: Thursday, June 19, 2014 10:46 AM >>>>> To: clue@ietf.org >>>>> Subject: [clue] How to do deal with CLUE spatial audio aspects >>>>> >>>>> Colleagues, >>>>> >>>>> Following up on the action from the Design Team meeting of June 17, >>>>> I propose the following text to be added at the end of section >>>>> 7.1.1.3 in the Framework document. >>>>> >>>>> ................ >>>>> Note that area of capture is not a valid concept for audio. To >>>>> capture spatial information related to audio, the point of capture >>>>> and point on line of capture ( as defined in sections 7.1.1.1 and >>>>> 7.1.1.2) may be used, along with another element defining the >>>>> nominal sensitivity pattern of the microphone (bearing in mind that >>>>> the actual microphone sensitivity pattern, in situ, may be somewhat >>>>> different due to local obstacles). Nominal microphone sensitivity >>>>> patterns to choose from include: Omni; Bi-directional; Cardioid; >>>>> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone >>>>> pair, the point of capture is defined as the mid-point between the >>> point of capture of the individual microphones. >>>>> .................. >>>>> >>>>> Regards, >>>>> >>>>> ...Paul >>>>> >>>>> _______________________________________________ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Sun Jun 29 19:49:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48931A00F6 for ; Sun, 29 Jun 2014 19:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 1z_j-XB6GSns for ; Sun, 29 Jun 2014 19:49:43 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341BA1A00F5 for ; Sun, 29 Jun 2014 19:49:43 -0700 (PDT) Received: from 124-110-22-114.east.fdn.vectant.ne.jp ([124.110.22.114]:27434 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1Re7-0004v5-8z; Mon, 30 Jun 2014 12:48:43 +1000 Message-ID: <53B0D040.30800@nteczone.com> Date: Mon, 30 Jun 2014 12:49:36 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <539FE86F.7000902@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19EF4@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19EF4@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/A77Y4kLRIoAmYfa-VCcOEaPuEtY Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 02:49:45 -0000 Hello Mark, Please see my comments below. Sorry for not being able to get back to you before the update. Regards, Christian ..snip.. >> Cl.3 General: Do we need a term to describe when multiple Capture Scenes >> are used to give an overall "picture" of the endpoint, i.e. GCSE? > [Duckworth, Mark] I don't think we need a new term in section 3. [CNG] I see Paul has a comment about GCSEs. > >> Cl.3 Media Consumer/Media Provider - Should this say MCU? > [Duckworth, Mark] I think MCU is a type of middle box. This is described in section 4. I don't think this definition needs to change. [CNG] OK. ..snip >> Cl.5 para.3: Is this really a MUST? It is conceivable that a CLUE channel is only >> established later in the call. Either we could have "SHOULD" or say something >> like "MUST occur when a CLUE channel is established in the call". > [Duckworth, Mark] How about replace "MUST" with "typically"? [CNG] Typically is good. > >> Cl.5 para.5: Is there a double definition of "media capture"? In this paragraph >> it says that a media capture describes the content. Whereas the definition in >> cl.3 says " Media Capture: a source of Media, such as from one or more >> Capture Devices or constructed from other Media streams." There's nothing >> about description of content here. > [Duckworth, Mark] how about "A Media Capture (MC), such as audio or video, has attributes to describe the content a Provider can send." [CNG] OK > > ..snip.. >> Cl.5 pg.13 para.1: "Voice Activated Stream Switching" via updated CLUE >> signalling is that something we've decided for CLUE? > [Duckworth, Mark] I think the refers to the case where a Consumer can send a new configure message asking for a different video capture using an already defined encoding from SDP, without needing another SDP O/A because nothing changes at the SDP level. If the consumer makes this choice based on audio information, that could be "voice activated screen switching" [CNG] OK, that clarifies the use. ..snip.. >> Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no spatial relationship >> between scenes. However this paragraph is a little "fuzzy" >> implying there may be relationship between scenes. Whilst physically there >> may a relationship a consumer has no way of knowing this. The default >> behaviour will not be to associate scenes. > [Duckworth, Mark] I don't see anything that implies a relationship between scenes. Which sentences specifically do you mean? [CNG] The sentence I'm referring to is "However, there is not necessarily the same spatial relationship between Media Captures that are in different Capture Scenes." "Not necessarily" to me means there may or may not be a spatial relationship between capture in different scenes. > >> Cl.9.1 para.3 : "The parameter of an Individual Encoding represent the >> maximum values", is this the case now? As the individual encoding >> parameter are now defined by SDP they could mean anything, not just >> maximum values. I think this paragraph needs to be updated to reflect this. > [Duckworth, Mark] I think this whole paragraph should be deleted. [CNG] Fine by me. > >> Cl.9.2: There is no explicit mention of whether individual encodings of >> multiple media types i.e. audio and video can belong to a single group. > [Duckworth, Mark] The data model restricts an encoding group to a particular media type. [CNG] Yes but you shouldn't have to look at the data model to find this out. I think the inclusion of a sentence to the effect that encoding groups are limited to a single media type would be beneficial. > >> Cl.10 para.2: I don't see the "special" handling outlined in this paragraph. A >> consumer would have a separate CLUE channel with each provider and treat >> the associations differently? > [Duckworth, Mark] I don't understand your point. Do you think this paragraph is unnecessary? [CNG] Yes, it doesn't seem to add alot. An endpoint or an MCU need to respond with a Configure based on the Advertisement and the MC capabilities. From nobody Sun Jun 29 20:04:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F54E1A00FA for ; Sun, 29 Jun 2014 20:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNflALL3IZvL for ; Sun, 29 Jun 2014 20:04:35 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76F61A00F9 for ; Sun, 29 Jun 2014 20:04:34 -0700 (PDT) Received: from 124-110-22-114.east.fdn.vectant.ne.jp ([124.110.22.114]:52987 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1RsU-0007CT-06; Mon, 30 Jun 2014 13:03:34 +1000 Message-ID: <53B0D3BA.4090202@nteczone.com> Date: Mon, 30 Jun 2014 13:04:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roberta Presta , "clue@ietf.org" References: <53A8F05E.6080902@nteczone.com> <53AD4395.5080708@unina.it> In-Reply-To: <53AD4395.5080708@unina.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1WeKec5eomFywo_4A9oqp3ldu1g Subject: Re: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 03:04:36 -0000 Hello Roberta, Thanks for the reply. I'm OK with the handling of most of the comments. Please see my responses to the open ones below. Regards, Christian On 27/06/2014 8:12 PM, Roberta Presta wrote: > ..snip.. >> - General: Do we need a statement about whether the framework or the >> data model takes precedence regarding the definition of attributes? > 13. I'm not sure we need such a statement in the data model. > However, up to now, the data model has followed the news introduced > in the framework. > By looking at how we conceived them, they are strictly interconnected, > so updates in one should be reflected (if necessary, i.e., if new > elements are defined, or the existing one are changed in their > structure) in updates in the companion document (independently from > the precedence rule). [CNG] I agree they are fairly well aligned. However we may find in the future that the description of something is open to interpretation. In that case does the reader follow what the framework says or what the data model says? >> _..snip.._ > __ >> - Cl.15.3: Do we need the mediaType attribute if mediaType is also an >> attribute of the referenced media captures? We don't have a mediaType >> for STSs. >> > 18. I have always used such an attribute in the definitions because, > even if redundant, it can be useful for simplifying parsing (e.g., for > rapidly filtering stss/cses/gses on the basis of the media type). > However, I have removed them also in the other data types dealing with > set of captures. [CNG] I'm OK. We should just be consistent how it is applied. > ..snip.. >> - Cl.19.1.2: This clause makes reference to >> ietf-ecrit-additional-data for the Xcard XML schema. What's the >> purpose of this? I thought a reference to the Xcard RFC 6351 is >> sufficient however the definitions of XML schemas is still a mystery. >> > 21. Actually draft-ietf-ecrit-additional-data is the source of the > imported XML schema corresponding to the Relax NG schema in RFC 6351. > We have left the reference, for the moment. [CNG] I'm not sure I follow. Why can't CLUE import the RFC6351 XML directly without the dependency on draft-ietf-ecrit-additional-data ? From nobody Sun Jun 29 20:48:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6C1A0143 for ; Sun, 29 Jun 2014 20:48: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 JY6ppTBnq_kw for ; Sun, 29 Jun 2014 20:48:26 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id AC5901A0142 for ; Sun, 29 Jun 2014 20:48:25 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id LTmH1o0020bG4ec59ToR9g; Mon, 30 Jun 2014 03:48:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id LToR1o0013ZTu2S3PToRKh; Mon, 30 Jun 2014 03:48:25 +0000 Message-ID: <53B0DE08.90808@alum.mit.edu> Date: Sun, 29 Jun 2014 23:48:24 -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: clue@ietf.org References: <539FE86F.7000902@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19EF4@CRPMBOXPRD08.polycom.com> <53B0D040.30800@nteczone.com> In-Reply-To: <53B0D040.30800@nteczone.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=1404100105; bh=spZZWIaoGSVJaXIFKCUQ53J7KrBQNqeDk5+VSKvkvUQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UEXW47OLp5QGaHwxKd+RH5r9cY1HdhK8tmwae6ilsRkNjYQDm3VoX1/Jb0lCOCdPE kCE3gdSUcC8uaQfifwVpYaCOImw6tdIV0W0HKm1zEvMc1CnAGcf1NguEHbfPFEn1BH Iyijq+KczTuhLQa8mxfiZrgIi37HuEWGRse7ZCkdBwxM6i/j9n7oCIoJGFOqxwSefa M2//7OdyGrR4846kxkpODU6yyCHGXth0RSiJ28yHnwG3dYH9Rv9OSWnvNq3iEcuPz/ 3UvyoMHLZY4F6az0yDxFo6FdFrKKXXXRda8rg7sGmUkyZeQjELIozNhBypd7ZIHzK3 rGiLCFBFYWxYw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/iGpx6hxj3J2_KrsLkZ_TSn3eeK8 Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 03:48:26 -0000 On 6/29/14 10:49 PM, Christian Groves wrote: >>> Cl.9.2: There is no explicit mention of whether individual encodings of >>> multiple media types i.e. audio and video can belong to a single group. >> [Duckworth, Mark] The data model restricts an encoding group to a >> particular media type. Section 12.1.2 shows an encoding group that has both audio and video encodings, and discusses this as an alternative to having separate encoding groups. It is clearly saying this is intended. > [CNG] Yes but you shouldn't have to look at the data model to find this > out. I think the inclusion of a sentence to the effect that encoding > groups are limited to a single media type would be beneficial. Thanks, Paul From nobody Sun Jun 29 20:56:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965421A0143 for ; Sun, 29 Jun 2014 20:56:58 -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_20=-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 EraIxJyF7t3n for ; Sun, 29 Jun 2014 20:56:58 -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 D09EB1A0142 for ; Sun, 29 Jun 2014 20:56:57 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id LTwx1o00327AodY5CTwxKS; Mon, 30 Jun 2014 03:56:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id LTwx1o0023ZTu2S3fTwxbA; Mon, 30 Jun 2014 03:56:57 +0000 Message-ID: <53B0E009.1080100@alum.mit.edu> Date: Sun, 29 Jun 2014 23:56:57 -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: CLUE 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=1404100617; bh=xjDKOJyBpdGZo4o+Ofef2DqJ2qMZJUueyIXwrVbzxMw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lr9J8I7FE2GXeZ0X0gSyYUbu0SXnVRGBItqOyVtE6B9snWTWFjLpojYji39eRhlkr jItSS2hAMuzhV1PPsq4IYCfjPjj/6AQmsGwpit4430SH5udEwCOcqZOcDgAgnQBM5Z Rg/70ifKVO137yb6mvCAMTwNyJ9APhlBb53H8TBHcMnlN1mvLRbNsTjeiowXIkGanj e+KHslVoKilDXR45K7H21l9dOC1uAqmDaNZXncBfQZSdeYnHCggtM7rpqzt5tXp5/j V8muWByQPNyXrcYKSMJBLN5pA6r7NfrvWSlGVPdjoUC8BqyA9P98+APrzl2ytlzVmI QWGBIMTly/ZuQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RKPtLfEwv1LhLh1JKXfnoP55p04 Subject: [clue] availability for design team call July 1 ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 03:56:58 -0000 Who all is able to attend the design team call this week? Mary is away, Christian has a conflict. And this is Independence Day week in the US. I can make it, but will we have enough people to get anything done? If you can make this call (topic: Signaling Open Issues) then please reply to this email. Thanks, Paul From nobody Mon Jun 30 01:44:17 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67931A01AC for ; Mon, 30 Jun 2014 01:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgkeNqU9bXCW for ; Mon, 30 Jun 2014 01:44:14 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1E21A01A7 for ; Mon, 30 Jun 2014 01:44:14 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so5617285wib.5 for ; Mon, 30 Jun 2014 01:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=gorQUkQwn9AkmUU6+y4UAhhm2HpBkkzdLWRiw8KKuGg=; b=sq6nb4JvmhFonHThRT0jxUROw2Kibq21trbWGfwMSY8xqavKxsiMmVsAEu2B/qHCjM TG19oo0PR+Kn2Hg63+mq99hWYpwjlMJxmADXa0N35bQlQ7J9mBZmzV4UxP2o/BhzIgfy NFaCZodPgICJKiwsFMb/O0QleMcubd4aEDH8DIUyLP+efPyqFXVbQDa3gG8qRlrmOC6q THdczD+SDD7ithi3AcV7AWWbWC/WwLiblTYdi4AAuFlDXuxuDpIPfJFplpmbFAeCpk5n pbPAky5WR9gxkKlJphiXNhO60sChdYtpkxIDebpK4TQ8Rwkuy42oCt3T161IxXdysC2j 3wZA== X-Received: by 10.180.24.2 with SMTP id q2mr28181282wif.22.1404117853143; Mon, 30 Jun 2014 01:44:13 -0700 (PDT) Received: from RoniE (bzq-79-179-98-253.red.bezeqint.net. [79.179.98.253]) by mx.google.com with ESMTPSA id ft2sm19873847wib.1.2014.06.30.01.44.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Jun 2014 01:44:12 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <53B0E009.1080100@alum.mit.edu> In-Reply-To: <53B0E009.1080100@alum.mit.edu> Date: Mon, 30 Jun 2014 11:43:59 +0300 Message-ID: <075701cf943f$71af7b50$550e71f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQElWXLIdddDDbGRgBSffI4iiwHfDJzdy+iA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/aqz8wVkstb8oYMPAl4MKKxHPVIc Subject: Re: [clue] availability for design team call July 1 ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 08:44:16 -0000 Hi, I can make it Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 30 June, 2014 6:57 AM > To: CLUE > Subject: [clue] availability for design team call July 1 ??? > > Who all is able to attend the design team call this week? > Mary is away, Christian has a conflict. And this is Independence Day week in > the US. > > I can make it, but will we have enough people to get anything done? > > If you can make this call (topic: Signaling Open Issues) then please reply to this > email. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 30 02:09:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DBB1A01A7 for ; Mon, 30 Jun 2014 02:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 WQVOWi-RZvmO for ; Mon, 30 Jun 2014 02:09:53 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90151A01AE for ; Mon, 30 Jun 2014 02:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=962; q=dns/txt; s=iport; t=1404119392; x=1405328992; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KrM9ebUTNh1zwu1f4d/H2YsGLofrYyVcTgwh9pXCes8=; b=cWIeVjYZit6oF1J3Nh5JutukJY0Tlg2nLoiFA8ljbWVqRHqnu6w7XoWZ 1QF0L8T6gpOif3K0kZ6TXKOy1JVhalkHSsP3KNOBoL49KQXmNQ/4BPo1B ZMmvYRAGBa2sPzhLK+s/0xfCQYurdsMcJPZEJyeUgrWIPfUTDnya2cNzx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkGAAwosVOtJssW/2dsb2JhbABag1+rcgEBAQEBAQUBbgGSBodAAYEjdYQDAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYg+DcZYEwSFZIhBEQFXBhCELQEEml6HBox3g0M8gTo X-IronPort-AV: E=Sophos;i="5.01,573,1400025600"; d="scan'208";a="96679487" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Jun 2014 09:09:50 +0000 Received: from [10.47.200.113] ([10.47.200.113]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5U99oer012910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2014 09:09:50 GMT Message-ID: <53B129ED.2020007@cisco.com> Date: Mon, 30 Jun 2014 10:12:13 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <53B0E009.1080100@alum.mit.edu> <075701cf943f$71af7b50$550e71f0$@gmail.com> In-Reply-To: <075701cf943f$71af7b50$550e71f0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bpGQfUAh54ZoQKub2ykl8nH_xRw Subject: Re: [clue] availability for design team call July 1 ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 09:09:54 -0000 I can make it too. Rob On 30/06/14 09:43, Roni Even wrote: > Hi, > I can make it > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 30 June, 2014 6:57 AM >> To: CLUE >> Subject: [clue] availability for design team call July 1 ??? >> >> Who all is able to attend the design team call this week? >> Mary is away, Christian has a conflict. And this is Independence Day week > in >> the US. >> >> I can make it, but will we have enough people to get anything done? >> >> If you can make this call (topic: Signaling Open Issues) then please reply > to this >> email. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jun 30 08:59:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D613A1A035C for ; Mon, 30 Jun 2014 08:59:25 -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 1JzvexHeZ44r for ; Mon, 30 Jun 2014 08:59:25 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id EC4181A0056 for ; Mon, 30 Jun 2014 08:59:24 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id Lf9E1o00327AodY5FfzQVi; Mon, 30 Jun 2014 15:59:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id LfzQ1o00Y3ZTu2S3ffzQKc; Mon, 30 Jun 2014 15:59:24 +0000 Message-ID: <53B1895C.7050102@alum.mit.edu> Date: Mon, 30 Jun 2014 11:59:24 -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: clue@ietf.org References: <53A8F05E.6080902@nteczone.com> <53AD4395.5080708@unina.it> <53B0D3BA.4090202@nteczone.com> In-Reply-To: <53B0D3BA.4090202@nteczone.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=1404143964; bh=q5ZrE/4wY1XxjTNlNi7SV+xgTE7L4ZONe2wLRVZs8jc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NjHBCxuEKfHDFGSuiXoc4VN1o/4whMttNvxN4WcMELkOFv9FXklRJTkC/3HrIwunX RI2MRhRK5lbWiTzMafOB3oy9SvBOEtDNU/itA4AAFgaoNkj1T2yZSgBUN6j7tkEkwU k0rnEFkkn+nof0nUUgePO4WHY3KZrWb+pMd1+oLDt4v2YGCQUV8I9RmtWBsAPoAntk zC9gee7Io1dLvWnHdf2HyYWJQfEKmSdWPe66HEVph+nlxesHBTvMwlTNnYj/KvBoCe MB9FUz7BdjHaoz5l1aqnpceZTjPxJOKEB1VciGZe6ov3sZY8pTBG5utu1iAAKp2Bzv RV3VlPTim1Wwg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/jzFauycjaX-_dM7YW5Ls7hewxKM Subject: Re: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:59:26 -0000 On 6/29/14 11:04 PM, Christian Groves wrote: >>> - General: Do we need a statement about whether the framework or the >>> data model takes precedence regarding the definition of attributes? >> 13. I'm not sure we need such a statement in the data model. >> However, up to now, the data model has followed the news introduced >> in the framework. >> By looking at how we conceived them, they are strictly interconnected, >> so updates in one should be reflected (if necessary, i.e., if new >> elements are defined, or the existing one are changed in their >> structure) in updates in the companion document (independently from >> the precedence rule). > [CNG] I agree they are fairly well aligned. However we may find in the > future that the description of something is open to interpretation. In > that case does the reader follow what the framework says or what the > data model says? How can the data model not be definitive? If the model schema disagrees with the FW, then how can you follow the fw? You are constrained by what you can say with the schema. So ISTM that we ought to at least say that if the *schema* differs from what the fw or the data model *text* say then the schema takes precedence. We then must do a careful review to ensure consistency. Thanks, Paul From nobody Mon Jun 30 09:37:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425CE1A03A8 for ; Mon, 30 Jun 2014 09:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 22gorwL68NdH for ; Mon, 30 Jun 2014 09:37:08 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062581A03C3 for ; Mon, 30 Jun 2014 09:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2573; q=dns/txt; s=iport; t=1404146228; x=1405355828; h=message-id:date:from:mime-version:to:subject; bh=pZLkFw/Wem5uhwHfVBUl8F+GLsmHKr1L2l7EgHLdXOk=; b=A9tYmOR63z3Ez7Y+Sb46tCGK/pTrM2OnRU9RZnXPVQqHRXNLPKJleFP3 VfGk/mSXrD4SJ7YXBm40xAvRYvTKT3ijQBiUlG4wAQBLhdTGmQqFAp5IH F2bIzKCKHSwb/5xyqJigShLkuXLpzxu6y7Z73Fezuj1K9qm+cXwc8eVAy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosGAP2RsVOtJssW/2dsb2JhbABar1IBAQEBAQEFAW4Bmmt1hQIgARwWGAMCAQIBWAgBAYg+nB2rYxeFZIlAhC0Fml6HBox3g0M8 X-IronPort-AV: E=Sophos; i="5.01,576,1400025600"; d="scan'208,217"; a="96916719" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Jun 2014 16:36:49 +0000 Received: from [10.47.200.113] ([10.47.200.113]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5UGanqA007196 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2014 16:36:49 GMT Message-ID: <53B192B0.6080907@cisco.com> Date: Mon, 30 Jun 2014 17:39:12 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org Content-Type: multipart/alternative; boundary="------------020109080700070702080009" X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SRxypVId277QbRryx0Lmb13ziRU Subject: [clue] Data model - encoding group mandatory for all captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:37:10 -0000 This is a multi-part message in MIME format. --------------020109080700070702080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One issue that I ran into while preparing a sample ADVERTISMENT of one of our telepresence endpoints for the wiki - is mandatory for all captures. However, what about captures that can't be directly configured, but are instead just informational for MCCs? For example, in this case I wanted to represent that the system has three cameras, but only makes a single, voice-switched stream available - you can't configure a captureEncoding of any of the cameras directly. In my example was able to work around the problem by making those captures unavailable by not including them in the list, but with the potential for captures to exist that are there purely to provide info for the contents of MCCs it seems we should have a way of expressing this properly. This isn't a simultaneity issue but one where they can't be encoded. As such, making optional would seem to be the answer here. Rob --------------020109080700070702080009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One issue that I ran into while preparing a sample ADVERTISMENT of one of our telepresence endpoints for the wiki - <encGroupIDREF> is mandatory for all captures. However, what about captures that can't be directly configured, but are instead just informational for MCCs? For example, in this case I wanted to represent that the system has three cameras, but only makes a single, voice-switched stream available - you can't configure a captureEncoding of any of the cameras directly.

In my example was able to work around the problem by making those captures unavailable by not including them in the <SimultaneousSets> list, but with the potential for captures to exist that are there purely to provide info for the contents of MCCs it seems we should have a way of expressing this properly. This isn't a simultaneity issue but one where they can't be encoded. As such, making <encGroupIDREF> optional would seem to be the answer here.

Rob --------------020109080700070702080009-- From nobody Mon Jun 30 11:43:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1595A1A040F for ; Mon, 30 Jun 2014 11:43: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 DleG4qaaCCQ3 for ; Mon, 30 Jun 2014 11:43:25 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7701A03FD for ; Mon, 30 Jun 2014 11:43:25 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id LgXk1o0041ap0As5DijQ18; Mon, 30 Jun 2014 18:43:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id LijQ1o00Q3ZTu2S3iijQeJ; Mon, 30 Jun 2014 18:43:24 +0000 Message-ID: <53B1AFCC.5020205@alum.mit.edu> Date: Mon, 30 Jun 2014 14:43:24 -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: clue@ietf.org References: <53B0E009.1080100@alum.mit.edu> In-Reply-To: <53B0E009.1080100@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=1404153804; bh=0LrDsGYuu+sNgP3ZVPkutw/bLHRtDcO8kq1NGceR8fg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pABOkixZAOHFZA3FjU0Oi1V/OPQbgxmXiB4M+Pi4OlaBUa3BaVqM04gXFGYooT3q+ bI1s1mPiCIfRqiKWv0iyqEvfG2FNOXHBy02kJPsUoKPW/GkOsZsz4cErfYfLNq3lHK 4F+uKKh36+uYW4FcOPGjugI9KSvbVHIGo6An4V4PnShGtgxLE8npX5w79pJ/kSd0/a iXMZQP5LnrBkXYCEk4ChUUtrBK5OUh3pKMKNal0SsSse+o2mOGIGRQkiEJ5BrB9r/K cCGwR01NGgjWLYHfuye/eHe3WJ3ZioFIj1+++pm9PzrsGp8ga8+9jPFGmNZWY0YM2E nvVTEGeKxeZRA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/O9q5XQfbFYRibwz-IhXtu3wqEuQ Subject: Re: [clue] availability for design team call July 1 ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:43:26 -0000 A few of us are available for the call tomorrow, so we will go ahead and have it. Please come if you can, even though I know a number of people are unavailable. Thanks, Paul On 6/29/14 11:56 PM, Paul Kyzivat wrote: > Who all is able to attend the design team call this week? > Mary is away, Christian has a conflict. And this is Independence Day > week in the US. > > I can make it, but will we have enough people to get anything done? > > If you can make this call (topic: Signaling Open Issues) then please > reply to this email. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >