From Christian.Groves@nteczone.com Mon Apr 1 18:08:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942A11E8124 for ; Mon, 1 Apr 2013 18:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7mrCdJIUGIm for ; Mon, 1 Apr 2013 18:08:36 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 169CA11E811B for ; Mon, 1 Apr 2013 18:08:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkDAHUuWlF20SD4/2dsb2JhbAANLQmDO785BAMBgRSDEwEBAQMBAQEBNRsbBAYBBQsLDgoJFggHCQMCAQIBFR8RBg0BBQIBAYgKEq1hgzGPcwSNdoE7B4NAA6sV Received: from ppp118-209-32-248.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.32.248]) by ipmail06.adl6.internode.on.net with ESMTP; 02 Apr 2013 11:38:34 +1030 Message-ID: <515A2F8F.1020507@nteczone.com> Date: Tue, 02 Apr 2013 12:08:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Pepperell References: <5153979E.1010106@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2013 01:08:38 -0000 Hello Andy, Please see my reply below [CNG]. Regards, Christian On 29/03/2013 1:26 AM, Andy Pepperell wrote: > Hi Christian, > > I'm happy to have a go at answering your question with my opinion as > to how this relates to the CLUE framework... [CNG] This is what I was after as the framework is a bit vague here. The questions aren't necessarily my opinion just what could be assumed by reading the framework. > > >From the framework it seems that it is assumed CaptureIDs are unique > in an Advertisement and the same CaptureID can be used in multiple > scenes and CSEs. A captureID may have multiple encodings. > > Yes, I think that's a good summary of the uniqueness of CaptureIDs. I > would, though, say that personally I consider the presence of a > CaptureID in more than one scene more the exception than the rule - > while it may be valid I don't think the majority of normal cases would > use this. [CNG] I also think having a CaptureID in multiple scenes is not necessarily a good thing. It does complicate things. I not sure that we actually need to allow it. If a provider really wanted a particular capture in two scenes it could use two CaptureIDs and duplicate the attributes. I would propose that we add something to the framework to indicate that a particular Capture (indicated by its identity) can on be used in one Scene description. > The "multiple encodings" aspect of media captures is designed to be > orthogonal to media captures' presence in one or more CSEs - it may be > valid to receive multiple encodings of a media capture even if it were > present in just one capture scene or capture scene entry, for > instance, and on the flip side, depending on the provider's > advertisement, it may only be possible to receive a single encodings > of a media capture which appears in multiple capture scene entries. [CNG] I agree that the encodings is designed to be orthogonal but I think that perhaps there needs to be a tie between then encoding and the CSE/CaptureID. For example: as a provider I can see the case where it offer CSE1,CaptureID1 which uses a high quality encoding or CSE2,CaptureID1,CaptureID2 which uses a lower quality encoding. Currently we have a link between the CaptureID and encoding. How does it relate a CSE to a particular encoding instance when the CaptureID is the same? > > >Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 > and Scene 2 CSE 1 how does it respond? > > To my mind, the phrasing is slightly misleading here in that it could > be said that the Consumer doesn't really want "Scene 1 CSE 1" and > "Scene 2 CSE 1" but in fact wants a single encoding or multiple > encodings of the more fundamental "VC1", which it can put to whatever > use, post decoding, that it chooses. [CNG] OK. > > >a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > > That's what I believe to be the answer to your question. As per the > above, if it has multiple "uses" for VC1, perhaps a very high quality > encoding to switch out to certain other consumers and a lower quality > version to transcode (if it's a middle box, for instance) it may > choose to use more than one of the provider's Individual Encodings for > VC1, but fundamentally this can be considered orthogonal to the choice > of which media captures are needed, or the reason, based on their CSE > membership, why those media captures are being requested. [CNG] Can it be completely orthogonal if a CSE is constructed based on some encoding considerations? > > >In response to the Configure what does the Provider do? The consumer > has indicated it wants two scenes and there's a duplicate of VC1. > Should the provider send the SDP to establish only one RTP stream for > VC1 or should it setup two RTP streams one for each scene? > > The idea behind the Encoding Group and Individual Encoding concepts > was that the provider can be fairly dumb here, and need to take no > view or action explicitly based on the "duplication" of VC1. SDP / RTP > relationships should be made according to the encoding configuration, > mostly determined by the consumer's configuration message. One RTP > stream per configured encoding would seem fairly straightforward, but > the multiplexing relationship of those streams with respect to "m > lines", SSRCs, multiplex IDs within RTP extension headers hasn't, to > my knowledge, been completely thrashed out to everyone's satisfaction > as yet (though I am forced to confess to a certain amount of ignorance > as to the latest state of this discussion). > > Regards, > > Andy > > > On Thu, Mar 28, 2013 at 1:06 AM, Christian Groves > > > wrote: > > Hello, > > >From the framework it seems that it is assumed CaptureIDs are > unique in an Advertisement and the same CaptureID can be used in > multiple scenes and CSEs. A captureID may have multiple encodings. > > I.e. > Advertisement > VC1 (capture attributes 1) > VC2 (capture attributes 2) > VC3 (capture attributes 3) > VC4 (capture attributes 4) > Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) > Scene 2 (CSE1(VC1,VC4)) > > Now if a Consumer sends a configure in response wanting Scene 1 > CSE 1 and Scene 2 CSE 1 how does it respond? > a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > b) Does it include the complete reference? i.e. > Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4)) > c) Both? > d) ? > > In response to the Configure what does the Provider do? The > consumer has indicated it wants two scenes and there's a duplicate > of VC1. Should the provider send the SDP to establish only one RTP > stream for VC1 or should it setup two RTP streams one for each scene? > > Any thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Tue Apr 2 05:35:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69621F976B for ; Tue, 2 Apr 2013 05:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=1.423, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7Y0RQwMdrfY for ; Tue, 2 Apr 2013 05:35:45 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id D127421F9765 for ; Tue, 2 Apr 2013 05:35:44 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so195624eek.22 for ; Tue, 02 Apr 2013 05:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=03FJ6Ai4eE3P41ZGkm4tPTG7aaa9SosmUnjd520bMzw=; b=xhwDvQBGA7m2GUdUMeuW/ZwZ3bCCgsrPIHrxX5kBoqJn7cUd8C+VGuYY8f775S0sJX 67dlPJGsQE41qzwuuogMI0r/vQoPj+wPqRFqjC2iIkYiKN5mj1al/4DOCwgpkt40DII6 cFqW5N3E5b2hsREDlZewRRS4MJ28t1nJrH+CIWSOCvuC90Z1k7a/9cixhh/l74XLB39c sUNVGqlquVvwApFmGC2e1+R6K3Jh39hMa/uwzoGI7oXA/8CfUVOJPObyuHLMh+F7BvOF xUVxRF9XhCSZfPTDiuUvsu+JQtJ0mhAakb+LWd8vzUTMCzcro6eSqBr/4L7BNIHJxEgf l3kg== X-Received: by 10.14.109.71 with SMTP id r47mr13304818eeg.25.1364906143920; Tue, 02 Apr 2013 05:35:43 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id f47sm2367092eep.13.2013.04.02.05.35.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 05:35:42 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <5153979E.1010106@nteczone.com> In-Reply-To: <5153979E.1010106@nteczone.com> Date: Tue, 2 Apr 2013 15:35:12 +0300 Message-ID: <06ca01ce2f9e$8a79a810$9f6cf830$@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: AQF+eiZrgRq3W36iCBgT2uojWxZc0ZliSINA Content-Language: en-us Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2013 12:35:45 -0000 Christian, >From the framework Some key points about Media Captures: . A Media Capture is of a single media type (e.g. audio or video) . A Media Capture is associated with exactly one Capture Scene . A Media Capture has exactly one set of spatial information . A Media Capture may be the source of one or more Capture Encodings Note the second bullet Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 28 March, 2013 3:07 AM To: clue@ietf.org Subject: [clue] Capture ID scope in a Configure Hello, From the framework it seems that it is assumed CaptureIDs are unique in an Advertisement and the same CaptureID can be used in multiple scenes and CSEs. A captureID may have multiple encodings. I.e. Advertisement VC1 (capture attributes 1) VC2 (capture attributes 2) VC3 (capture attributes 3) VC4 (capture attributes 4) Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) Scene 2 (CSE1(VC1,VC4)) Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and Scene 2 CSE 1 how does it respond? a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4)) c) Both? d) ? In response to the Configure what does the Provider do? The consumer has indicated it wants two scenes and there's a duplicate of VC1. Should the provider send the SDP to establish only one RTP stream for VC1 or should it setup two RTP streams one for each scene? Any thoughts? Regards, Christian _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Apr 2 20:57:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9754521F88C0 for ; Tue, 2 Apr 2013 20:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGKY4TJEAMHE for ; Tue, 2 Apr 2013 20:57:00 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5621F88BD for ; Tue, 2 Apr 2013 20:56:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAHmnW1F20a9T/2dsb2JhbAANNoM9wDWBIIMTAQEBBAEBATUbGwsMBAsOAwQBAQEJHgcPAhYfCQgGDQEFAgEBiByuL5M4BI8ZBwaDOgOrFQ Received: from ppp118-209-175-83.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.175.83]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Apr 2013 14:26:58 +1030 Message-ID: <515BA884.10107@nteczone.com> Date: Wed, 03 Apr 2013 14:56:52 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Roni Even References: <5153979E.1010106@nteczone.com> <06ca01ce2f9e$8a79a810$9f6cf830$@gmail.com> In-Reply-To: <06ca01ce2f9e$8a79a810$9f6cf830$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Apr 2013 03:57:00 -0000 Hello Roni, OK thanks I missed that bullet. I was looking at 6.2 on capture scenes. In that section its says that a media capture can be used in multiple CSEs. That's missing from the bullet list in 6.1. 6.2 missing the facts that a capture can only be used by one scene. It would be good to align these two sections. Regards, Christian On 2/04/2013 11:35 PM, Roni Even wrote: > Christian, > >From the framework > > Some key points about Media Captures: > > . A Media Capture is of a single media type (e.g. audio or video) > . A Media Capture is associated with exactly one Capture Scene > . A Media Capture has exactly one set of spatial information > . A Media Capture may be the source of one or more Capture > Encodings > > Note the second bullet > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 28 March, 2013 3:07 AM > To: clue@ietf.org > Subject: [clue] Capture ID scope in a Configure > > Hello, > > From the framework it seems that it is assumed CaptureIDs are unique in an > Advertisement and the same CaptureID can be used in multiple scenes and > CSEs. A captureID may have multiple encodings. > > I.e. > Advertisement > VC1 (capture attributes 1) > VC2 (capture attributes 2) > VC3 (capture attributes 3) > VC4 (capture attributes 4) > Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) > Scene 2 (CSE1(VC1,VC4)) > > Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and > Scene 2 CSE 1 how does it respond? > a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), > Scene2(CSE1(VC1,VC4)) > c) Both? > d) ? > > In response to the Configure what does the Provider do? The consumer has > indicated it wants two scenes and there's a duplicate of VC1. Should the > provider send the SDP to establish only one RTP stream for VC1 or should it > setup two RTP streams one for each scene? > > Any thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From roberta.presta@unina.it Wed Apr 3 10:22:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ED621F8D82 for ; Wed, 3 Apr 2013 10:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wXrlCgcAZKA for ; Wed, 3 Apr 2013 10:22:25 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBB21F8DA6 for ; Wed, 3 Apr 2013 10:22:18 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r33HMFE2009400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Apr 2013 19:22:16 +0200 Message-ID: <515C6548.1020807@unina.it> Date: Wed, 03 Apr 2013 19:22:16 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <5153979E.1010106@nteczone.com> <515A2F8F.1020507@nteczone.com> In-Reply-To: <515A2F8F.1020507@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130403-0, 03/04/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Apr 2013 17:22:31 -0000 Hi all, it seems to me that capture scenes and capture scene entries are semantical abstractions that are useful only to make a media provider able to show the organization of the available media captures to the media consumer via an advertisement message. I don't believe they should be used within a configure message. The media consumer should specify only *capture encodings*, i.e., the associations of a media capture with an individual encoding with the desired parameters. If the media consumer wants both VC1 encoded with ENC0 and VC1 encoded with ENC1, he should put in the configure message the specification of two capture encodings. VC1... ENC1... ... If he wants all the captures within a capture scene, he should specify in the configure a capture encoding for each capture of the scene, since he should be forced to associate a desired encoding to each desired capture. Do you think this interpretation is correct? Thanks, Roberta Il 02/04/2013 03:08, Christian Groves ha scritto: > > >> The "multiple encodings" aspect of media captures is designed to be >> orthogonal to media captures' presence in one or more CSEs - it may >> be valid to receive multiple encodings of a media capture even if it >> were present in just one capture scene or capture scene entry, for >> instance, and on the flip side, depending on the provider's >> advertisement, it may only be possible to receive a single encodings >> of a media capture which appears in multiple capture scene entries. > [CNG] I agree that the encodings is designed to be orthogonal but I > think that perhaps there needs to be a tie between then encoding and > the CSE/CaptureID. For example: as a provider I can see the case where > it offer CSE1,CaptureID1 which uses a high quality encoding or > CSE2,CaptureID1,CaptureID2 which uses a lower quality encoding. > Currently we have a link between the CaptureID and encoding. How does > it relate a CSE to a particular encoding instance when the CaptureID > is the same? >> >> >Now if a Consumer sends a configure in response wanting Scene 1 CSE >> 1 and Scene 2 CSE 1 how does it respond? >> >> To my mind, the phrasing is slightly misleading here in that it could >> be said that the Consumer doesn't really want "Scene 1 CSE 1" and >> "Scene 2 CSE 1" but in fact wants a single encoding or multiple >> encodings of the more fundamental "VC1", which it can put to whatever >> use, post decoding, that it chooses. > [CNG] OK. >> >> >a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 >> >> That's what I believe to be the answer to your question. As per the >> above, if it has multiple "uses" for VC1, perhaps a very high quality >> encoding to switch out to certain other consumers and a lower quality >> version to transcode (if it's a middle box, for instance) it may >> choose to use more than one of the provider's Individual Encodings >> for VC1, but fundamentally this can be considered orthogonal to the >> choice of which media captures are needed, or the reason, based on >> their CSE membership, why those media captures are being requested. > [CNG] Can it be completely orthogonal if a CSE is constructed based on > some encoding considerations? >> >> >In response to the Configure what does the Provider do? The consumer >> has indicated it wants two scenes and there's a duplicate of VC1. >> Should the provider send the SDP to establish only one RTP stream for >> VC1 or should it setup two RTP streams one for each scene? >> >> The idea behind the Encoding Group and Individual Encoding concepts >> was that the provider can be fairly dumb here, and need to take no >> view or action explicitly based on the "duplication" of VC1. SDP / >> RTP relationships should be made according to the encoding >> configuration, mostly determined by the consumer's configuration >> message. One RTP stream per configured encoding would seem fairly >> straightforward, but the multiplexing relationship of those streams >> with respect to "m lines", SSRCs, multiplex IDs within RTP extension >> headers hasn't, to my knowledge, been completely thrashed out to >> everyone's satisfaction as yet (though I am forced to confess to a >> certain amount of ignorance as to the latest state of this discussion). >> >> Regards, >> >> Andy >> >> >> On Thu, Mar 28, 2013 at 1:06 AM, Christian Groves >> > > wrote: >> >> Hello, >> >> >From the framework it seems that it is assumed CaptureIDs are >> unique in an Advertisement and the same CaptureID can be used in >> multiple scenes and CSEs. A captureID may have multiple encodings. >> >> I.e. >> Advertisement >> VC1 (capture attributes 1) >> VC2 (capture attributes 2) >> VC3 (capture attributes 3) >> VC4 (capture attributes 4) >> Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) >> Scene 2 (CSE1(VC1,VC4)) >> >> Now if a Consumer sends a configure in response wanting Scene 1 >> CSE 1 and Scene 2 CSE 1 how does it respond? >> a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 >> b) Does it include the complete reference? i.e. >> Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4)) >> c) Both? >> d) ? >> >> In response to the Configure what does the Provider do? The >> consumer has indicated it wants two scenes and there's a duplicate >> of VC1. Should the provider send the SDP to establish only one RTP >> stream for VC1 or should it setup two RTP streams one for each >> scene? >> >> Any thoughts? >> >> 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 > -- Roberta Presta, Ph.D. Student Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione (DIETI) Universita' degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 From pkyzivat@alum.mit.edu Wed Apr 3 11:46:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD57F21F8C6F for ; Wed, 3 Apr 2013 11:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00h-gG1Io21W for ; Wed, 3 Apr 2013 11:46:54 -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 EBEB521F8C5C for ; Wed, 3 Apr 2013 11:46:53 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id KTt11l0040xGWP85CWmt38; Wed, 03 Apr 2013 18:46:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id KWms1l00n3ZTu2S3YWmtvk; Wed, 03 Apr 2013 18:46:53 +0000 Message-ID: <515C78D0.7000404@alum.mit.edu> Date: Thu, 04 Apr 2013 02:45:36 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <5153979E.1010106@nteczone.com> <515A2F8F.1020507@nteczone.com> <515C6548.1020807@unina.it> In-Reply-To: <515C6548.1020807@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365014813; bh=0jYZCCNd7qHchs/poCZd/BcZ2Jjr2duUfHuHaLyZ8No=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r2q1XOigVIN22vI4VFvtT9pTGpJcFmm0g0q047uTMaFS/+UqvoeNc+qRFMdyTj/ve vBDFUpyNmJvjKBPms364M7krrC6D7tKgIRBAnKyWddJCvGPU+cwIcC7HNBSBWgkZJz v6durCAgTuqdQBUNq1hQTMZvy5jP/HtHAWzBg/hDNEEbKmkIU495RLIZlg2uQc5fhJ BMzEiKDCttILh8gM/EQeionxp1dfsjU18lOKrzkPodVlCbCMoSlfQlBYqO9wqvL0pv KkJHIjhrEo8OWjmTOcKdytafRGqxFvKpn/JAeoObL5wCz4fgKi0YtIuawrTPB0pDYn ldCditN20ULQA== Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Apr 2013 18:46:54 -0000 On 4/4/13 1:22 AM, Roberta Presta wrote: > Hi all, > > it seems to me that capture scenes and capture scene entries are > semantical abstractions that are useful only to make a media provider > able to show the organization of the available media captures to the > media consumer via an advertisement message. > I don't believe they should be used within a configure message. > The media consumer should specify only *capture encodings*, i.e., the > associations of a media capture with an individual encoding with the > desired parameters. > If the media consumer wants both VC1 encoded with ENC0 and VC1 encoded > with ENC1, he should put in the configure message the specification of > two capture encodings. > > VC1... > ENC1... > ... > If he wants all the captures within a capture scene, he should specify > in the configure a capture encoding for each capture of the scene, since > he should be forced to associate a desired encoding to each desired > capture. > Do you think this interpretation is correct? Yes, this is exactly what I am thinking! Thanks, Paul From Mark.Duckworth@polycom.com Wed Apr 3 11:49:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555F621F8B8F for ; Wed, 3 Apr 2013 11:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmlY9+dD5X4t for ; Wed, 3 Apr 2013 11:49:35 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B370121F8B08 for ; Wed, 3 Apr 2013 11:49:35 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::5efe:10.236.0.200]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 3 Apr 2013 11:49:35 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 3 Apr 2013 11:49:33 -0700 Thread-Topic: [clue] Capture ID scope in a Configure Thread-Index: Ac4wm6QRFJ47/X7gQFmMS7tu98NK/wAAE2GQ Message-ID: <9C23AB934B394845A7B228239B6EAF41EF27B7@CRPMBOXPRD01.polycom.com> References: <5153979E.1010106@nteczone.com> <515A2F8F.1020507@nteczone.com> <515C6548.1020807@unina.it> <515C78D0.7000404@alum.mit.edu> In-Reply-To: <515C78D0.7000404@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 Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Apr 2013 18:49:36 -0000 +1 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, April 03, 2013 2:46 PM > To: clue@ietf.org > Subject: Re: [clue] Capture ID scope in a Configure >=20 > On 4/4/13 1:22 AM, Roberta Presta wrote: > > Hi all, > > > > it seems to me that capture scenes and capture scene entries are > > semantical abstractions that are useful only to make a media provider > > able to show the organization of the available media captures to the > > media consumer via an advertisement message. > > I don't believe they should be used within a configure message. > > The media consumer should specify only *capture encodings*, i.e., the > > associations of a media capture with an individual encoding with the > > desired parameters. > > If the media consumer wants both VC1 encoded with ENC0 and VC1 > encoded > > with ENC1, he should put in the configure message the specification of > > two capture encodings. > > > > VC1... > > ENC1... > > ... > > If he wants all the captures within a capture scene, he should specify > > in the configure a capture encoding for each capture of the scene, > > since he should be forced to associate a desired encoding to each > > desired capture. > > Do you think this interpretation is correct? >=20 > Yes, this is exactly what I am thinking! >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Apr 3 16:52:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0E21F8FD5 for ; Wed, 3 Apr 2013 16:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xej5m1hicRzR for ; Wed, 3 Apr 2013 16:52:51 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 3298821F8F0A for ; Wed, 3 Apr 2013 16:52:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAFO/XFF20S3w/2dsb2JhbAANNoM9wGaBIoMTAQEBBAEBATUbGwoNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQGIHK0dkzEEjyAGEIMqA6sV Received: from ppp118-209-45-240.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.240]) by ipmail07.adl2.internode.on.net with ESMTP; 04 Apr 2013 10:22:45 +1030 Message-ID: <515CC0C8.4010400@nteczone.com> Date: Thu, 04 Apr 2013 10:52:40 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <5153979E.1010106@nteczone.com> <515A2F8F.1020507@nteczone.com> <515C6548.1020807@unina.it> <515C78D0.7000404@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41EF27B7@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41EF27B7@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Apr 2013 23:52:52 -0000 Yes, can we have Roberta's text (or similar) in the framework so its 100% clear? Christian On 4/04/2013 5:49 AM, Duckworth, Mark wrote: > +1 > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Wednesday, April 03, 2013 2:46 PM >> To: clue@ietf.org >> Subject: Re: [clue] Capture ID scope in a Configure >> >> On 4/4/13 1:22 AM, Roberta Presta wrote: >>> Hi all, >>> >>> it seems to me that capture scenes and capture scene entries are >>> semantical abstractions that are useful only to make a media provider >>> able to show the organization of the available media captures to the >>> media consumer via an advertisement message. >>> I don't believe they should be used within a configure message. >>> The media consumer should specify only *capture encodings*, i.e., the >>> associations of a media capture with an individual encoding with the >>> desired parameters. >>> If the media consumer wants both VC1 encoded with ENC0 and VC1 >> encoded >>> with ENC1, he should put in the configure message the specification of >>> two capture encodings. >>> >>> VC1... >>> ENC1... >>> ... >>> If he wants all the captures within a capture scene, he should specify >>> in the configure a capture encoding for each capture of the scene, >>> since he should be forced to associate a desired encoding to each >>> desired capture. >>> Do you think this interpretation is correct? >> Yes, this is exactly what I am thinking! >> >> 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 pkyzivat@alum.mit.edu Thu Apr 4 07:29:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0321F86FA for ; Thu, 4 Apr 2013 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lve1hrLa1Mf for ; Thu, 4 Apr 2013 07:29:12 -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 B84C921F892D for ; Thu, 4 Apr 2013 07:29:11 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id Ko8N1l00D0bG4ec53qVBC6; Thu, 04 Apr 2013 14:29:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id KqVA1l01U3ZTu2S3PqVAU5; Thu, 04 Apr 2013 14:29:11 +0000 Message-ID: <515D8E36.7060208@alum.mit.edu> Date: Thu, 04 Apr 2013 22:29:10 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: CLUE References: <515CDDB1.2010809@stpeter.im> In-Reply-To: <515CDDB1.2010809@stpeter.im> X-Forwarded-Message-Id: <515CDDB1.2010809@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365085751; bh=jkgd5MSUcLBt8loTi8PAXLXp6dfJipJBuIW5dwbR3lA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lhkZXzbxah1WgK8VkcuREv4rG6ul/1JtfRpgxO5PYwvUG5F5HYOVeHP4AUGCGHgl3 WzL5Q0fiNIZBKYPBvgmbdfMvtead7rO0+iJgsCfX9swy5dCrGLWJEvR7qi2ZPcLNmR 4qthyMLU4sakKW1Y/VLKOVr6cZ6zeg9m/XpBvScpZ0I7IyFxln2g/CGGkjydYoWR+Q DuWXD4QrUe+EaIRwj1qe1fr7uvNOH+kTLkSLUv8hwb4Z6ARf6STHV1rRSnauAr/MeK bYsNBUuEmjD6z7Hseu4lzLULxmmcE1Ju9H3m1gWYHx1uoF6/kc+kOwW9RAQ7ndZEgI 4Dnpl5JYQWNDQ== Subject: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2013 14:29:12 -0000 I try to avoid cross posting, but there may be clue people who don't follow the dispatch list. -------- Original Message -------- Subject: [dispatch] conference roles Date: Wed, 03 Apr 2013 19:56:01 -0600 From: Peter Saint-Andre To: DISPATCH -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 4575 (Section 5.6.3) defines the concept of a role in a conference, but does not specify or define any roles. 5.6.3. This element MAY contain a set of human-readable strings describing the roles of the user in the conference. Note that this information is applicable for human consumption only. This specification does not define the set of possible conferencing roles or the semantics associated with each. It is expected that future conferencing specifications will define these and the corresponding schema extensions, as appropriate. RFC 6501 (Section 4.6.5.2) specifies a few values for the role element, but does not actually define what those values mean. 4.6.5.2. A provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents. (As far as I know, those "future policy documents" have not been published.) More recently, draft-groves-clue-capture-attr specifies several additional roles: "manager", "chairman", "secretary", "lecturer", and "audience" (so-called person roles) as well as "speaker" and "controller" (so-called conference roles). Personally, I happen to have an interest in defining a few other roles, such as "host", "presenter", "scribe", and "panelist". Unfortunately there's quite a bit of overlap and confusion here. For instance, one could argue that "host", "manager", and "controller" (perhaps even "chairman") are the same as or very similar to "administrator" or "moderator" from RFC 6501. There might also be overlap between "lecturer", "speaker", and "presenter" (and between "speaker" and "panelist"). Furthermore, I'm concerned that various implementations will define their own roles, blithely unaware that very similar (or even identical but differently named roles) are already in use by other implementations. It strikes me that one solution here would be to establish an IANA registry for conference roles, with a registration policy (cf. RFC 5226) of at least Expert Review and perhaps Specification Required (I think RFC Required is a bit heavy). IMHO this would help to prevent continued confusion and the minting of new roles that overlap with existing roles. Thoughts? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXN2wAAoJEOoGpJErxa2p98YP/1AtEgnS9T6w9aYc4V66Z0wv AJJ0r4Xk8mKWyqYsovyyqLoXnqnFitOSBrlt1pskDw/pDhI08LZiPkN3G3sMDSdo qhCen5UcSMRaKwDCaddXiIOzMP2IOEqJFltWWj32BX/qgtYVSMac9Vgsw/HJWzUi hjLM5U84W4mLBLGC5XgT7jqwTYA3pb1tqfN0Fn1Ony/kW9Nmy0+fciQhMTLrkOi6 cwplCwdNsmZeGbp4ABlDMLA2WcilqmU7Iu61lKlNmbnizTXGeTznsst51LZvuEO3 c9z0UUQl+g88F4ZxBphdbtxzK9qRFD4l+FSRRwPxM3vggjVUSp829GCHEgdUeyel v3Mxy0aTmsziKOUJ3lTU2mi3RGu9b7lkei0t1EF8rXAz6upMCJcd+90qD29QbP3s z5V6hz7iJCe172XiElmbX29d2u3yt7SbHNX9Ime4SvHMWX9NrJyuoOiSk+7IF73k qX2QIe3JJDPX4Q0KO9Od64m95hjPgM2EiYj7gFbq9K3cAwZ0x3nExWN4+XB2WWyJ Qo4+vSk1eL04dzcy06m7cDrM9snlm4usOA8YrvabItAKryl9E8d0rqNi8Y6PB2sI IcnT73QbPJIvLzP/Z03Pn4n1uhz0K+QjIySJKW3bcs0Nj5qyjyMAQCIt+DvzP8Fq 5PghQ2Ey40XHE3Mp6V35 =i5bw -----END PGP SIGNATURE----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Thu Apr 4 07:42:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6021F93FB for ; Thu, 4 Apr 2013 07:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on7SHLPW+RXO for ; Thu, 4 Apr 2013 07:42:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AE6F121F8D2C for ; Thu, 4 Apr 2013 07:42:47 -0700 (PDT) Received: from [10.0.0.3] (unknown [24.9.168.255]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EBB4840DC2 for ; Thu, 4 Apr 2013 08:52:34 -0600 (MDT) Message-ID: <515D9165.7@stpeter.im> Date: Thu, 04 Apr 2013 08:42:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <515CDDB1.2010809@stpeter.im> In-Reply-To: <515CDDB1.2010809@stpeter.im> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <515CDDB1.2010809@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2013 14:42:48 -0000 FYI. -------- Original Message -------- Subject: [dispatch] conference roles Date: Wed, 03 Apr 2013 19:56:01 -0600 From: Peter Saint-Andre To: DISPATCH RFC 4575 (Section 5.6.3) defines the concept of a role in a conference, but does not specify or define any roles. 5.6.3. This element MAY contain a set of human-readable strings describing the roles of the user in the conference. Note that this information is applicable for human consumption only. This specification does not define the set of possible conferencing roles or the semantics associated with each. It is expected that future conferencing specifications will define these and the corresponding schema extensions, as appropriate. RFC 6501 (Section 4.6.5.2) specifies a few values for the role element, but does not actually define what those values mean. 4.6.5.2. A provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents. (As far as I know, those "future policy documents" have not been published.) More recently, draft-groves-clue-capture-attr specifies several additional roles: "manager", "chairman", "secretary", "lecturer", and "audience" (so-called person roles) as well as "speaker" and "controller" (so-called conference roles). Personally, I happen to have an interest in defining a few other roles, such as "host", "presenter", "scribe", and "panelist". Unfortunately there's quite a bit of overlap and confusion here. For instance, one could argue that "host", "manager", and "controller" (perhaps even "chairman") are the same as or very similar to "administrator" or "moderator" from RFC 6501. There might also be overlap between "lecturer", "speaker", and "presenter" (and between "speaker" and "panelist"). Furthermore, I'm concerned that various implementations will define their own roles, blithely unaware that very similar (or even identical but differently named roles) are already in use by other implementations. It strikes me that one solution here would be to establish an IANA registry for conference roles, with a registration policy (cf. RFC 5226) of at least Expert Review and perhaps Specification Required (I think RFC Required is a bit heavy). IMHO this would help to prevent continued confusion and the minting of new roles that overlap with existing roles. Thoughts? Peter _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Thu Apr 4 07:44:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD92121F942C for ; Thu, 4 Apr 2013 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN6hpfvWKIZH for ; Thu, 4 Apr 2013 07:44:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9142A21F9425 for ; Thu, 4 Apr 2013 07:44:11 -0700 (PDT) Received: from [10.0.0.3] (unknown [24.9.168.255]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 88F4240DC2 for ; Thu, 4 Apr 2013 08:53:58 -0600 (MDT) Message-ID: <515D91B8.9050002@stpeter.im> Date: Thu, 04 Apr 2013 08:44:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> In-Reply-To: <515D9165.7@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2013 14:44:13 -0000 Sorry, I missed the fact that Paul already forwarded this! On 4/4/13 8:42 AM, Peter Saint-Andre wrote: > FYI. > > > -------- Original Message -------- > Subject: [dispatch] conference roles > Date: Wed, 03 Apr 2013 19:56:01 -0600 > From: Peter Saint-Andre > To: DISPATCH > > RFC 4575 (Section 5.6.3) defines the concept of a role in a > conference, but does not specify or define any roles. > > 5.6.3. > > This element MAY contain a set of human-readable strings describing > the roles of the user in the conference. Note that this information > is applicable for human consumption only. This specification does > not define the set of possible conferencing roles or the semantics > associated with each. It is expected that future conferencing > specifications will define these and the corresponding schema > extensions, as appropriate. > > RFC 6501 (Section 4.6.5.2) specifies a few values for the role > element, but does not actually define what those values mean. > > 4.6.5.2. > > A provides the context for the set of conference operations > that a participant can perform. This element can contain one or more > of the following values: "administrator", "moderator", "user", > "participant", "observer", and "none". A role of "none" indicates > that any role is assigned. The semantic definition is out of > the scope of this document and is subject to future policy documents. > This element can be extended with new roles in future documents. > > (As far as I know, those "future policy documents" have not been > published.) > > More recently, draft-groves-clue-capture-attr specifies several > additional roles: "manager", "chairman", "secretary", "lecturer", and > "audience" (so-called person roles) as well as "speaker" and > "controller" (so-called conference roles). Personally, I happen to > have an interest in defining a few other roles, such as "host", > "presenter", "scribe", and "panelist". > > Unfortunately there's quite a bit of overlap and confusion here. For > instance, one could argue that "host", "manager", and "controller" > (perhaps even "chairman") are the same as or very similar to > "administrator" or "moderator" from RFC 6501. There might also be > overlap between "lecturer", "speaker", and "presenter" (and between > "speaker" and "panelist"). > > Furthermore, I'm concerned that various implementations will define > their own roles, blithely unaware that very similar (or even identical > but differently named roles) are already in use by other implementations. > > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. > > Thoughts? > > Peter > From mary.ietf.barnes@gmail.com Thu Apr 4 08:29:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A930321F902A for ; Thu, 4 Apr 2013 08:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyhuZXdaXtia for ; Thu, 4 Apr 2013 08:29:39 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 203B221F84A6 for ; Thu, 4 Apr 2013 08:29:39 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hg5so2660711qab.4 for ; Thu, 04 Apr 2013 08:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=PugDtR6OYMhZymFjAhCl0hipOUdXpJHXa4ZyP5KuVf4=; b=O2f9mVi8qvqRiBdJiwptOXu+tBtse6GEz6P8EVM1YDD0Wuw6MZHHA8nO0guwgbdLqa LbYMtOqvvv60z3NwzEaC9RkwZ+DjA45FweAzI4p0p73Jmssr+u1acC56YXYvyHHD4z09 71nRsjJqVGoixB429GygK5dgTz+HZ6u1agFxvXmJYFkDWjE3KsHkXmh2bYBIwRqnsZBc VO4cw5t+R9i2z3AmFW7gGydkgtr//JZdhPNR0hcIXDCPMVei3Fv4+CqehYIud4jR7viY X4lZC6EslGZLFLhghQUeR3U5bRDw09Plm7WMctNp5ePWBZgI2EYV/C3HmIf0iTdL25wL 6nPg== MIME-Version: 1.0 X-Received: by 10.49.116.235 with SMTP id jz11mr5917722qeb.39.1365089378564; Thu, 04 Apr 2013 08:29:38 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Thu, 4 Apr 2013 08:29:38 -0700 (PDT) Date: Thu, 4 Apr 2013 10:29:38 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Cc: Jonathan Lennox Subject: [clue] WG charter item for RTP grouping taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2013 15:29:39 -0000 Hi all, As discussed in the last AVTEXT/MMUSIC session at IETF-86, it has been decided to progress this work in the AVTEXT WG. This is important for CLUE so I highly recommend folks follow and contribute to this work on the AVTEXT WG mailing list (it's not a very busy list). This is the current working (individual) draft: http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-00 Regards, Mary. From spromano@unina.it Fri Apr 5 15:39:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245F521F98BD for ; Fri, 5 Apr 2013 15:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPx4mx2pv6ZU for ; Fri, 5 Apr 2013 15:39:24 -0700 (PDT) Received: from relay1.tre.it (mail.tre.it [62.13.171.46]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2D21F98A5 for ; Fri, 5 Apr 2013 15:39:22 -0700 (PDT) Received: from [192.168.1.104] ([10.88.68.46]) by relay1.tre.it with ESMTP id r35MdJEW008794-r35MdJEX008794; Sat, 6 Apr 2013 00:39:20 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_13FD6C6E-34DD-4719-AF81-930BE15282FA" From: Simon Pietro Romano In-Reply-To: <515D9165.7@stpeter.im> Date: Sat, 6 Apr 2013 00:39:19 +0200 Message-Id: <79CA1F04-BC72-4939-BAF9-1DC9E3149E59@unina.it> References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2013 22:39:25 -0000 --Apple-Mail=_13FD6C6E-34DD-4719-AF81-930BE15282FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Peter, thank you for raising such an interesting discussion. This reminds me of = a specific thread dedicated to policies and roles inside XCON, back in = 2007. I expressed my personal view on this subject in a (long) e-mail = (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html) you = might want to have a look at. As you mention in your e-mail "future = policy documents" have not been published. Cheers, Simon Il giorno 04/apr/2013, alle ore 16:42, Peter Saint-Andre ha scritto: > FYI. >=20 >=20 > -------- Original Message -------- > Subject: [dispatch] conference roles > Date: Wed, 03 Apr 2013 19:56:01 -0600 > From: Peter Saint-Andre > To: DISPATCH >=20 > RFC 4575 (Section 5.6.3) defines the concept of a role in a > conference, but does not specify or define any roles. >=20 > 5.6.3. >=20 > This element MAY contain a set of human-readable strings describing > the roles of the user in the conference. Note that this information > is applicable for human consumption only. This specification does > not define the set of possible conferencing roles or the semantics > associated with each. It is expected that future conferencing > specifications will define these and the corresponding schema > extensions, as appropriate. >=20 > RFC 6501 (Section 4.6.5.2) specifies a few values for the role > element, but does not actually define what those values mean. >=20 > 4.6.5.2. >=20 > A provides the context for the set of conference operations > that a participant can perform. This element can contain one or = more > of the following values: "administrator", "moderator", "user", > "participant", "observer", and "none". A role of "none" indicates > that any role is assigned. The semantic definition is out = of > the scope of this document and is subject to future policy = documents. > This element can be extended with new roles in future documents. >=20 > (As far as I know, those "future policy documents" have not been > published.) >=20 > More recently, draft-groves-clue-capture-attr specifies several > additional roles: "manager", "chairman", "secretary", "lecturer", and > "audience" (so-called person roles) as well as "speaker" and > "controller" (so-called conference roles). Personally, I happen to > have an interest in defining a few other roles, such as "host", > "presenter", "scribe", and "panelist". >=20 > Unfortunately there's quite a bit of overlap and confusion here. For > instance, one could argue that "host", "manager", and "controller" > (perhaps even "chairman") are the same as or very similar to > "administrator" or "moderator" from RFC 6501. There might also be > overlap between "lecturer", "speaker", and "presenter" (and between > "speaker" and "panelist"). >=20 > Furthermore, I'm concerned that various implementations will define > their own roles, blithely unaware that very similar (or even identical > but differently named roles) are already in use by other = implementations. >=20 > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. >=20 > Thoughts? >=20 > Peter >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_13FD6C6E-34DD-4719-AF81-930BE15282FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Peter,

thank you for raising such an interesting = discussion. This reminds me of a specific thread dedicated to policies = and roles inside XCON, back in 2007. I expressed my personal view on = this subject in a (long) e-mail (h= ttp://www.ietf.org/mail-archive/web/xcon/current/msg01919.html) y= ou might want to have a look at. As you mention in your e-mail "future = policy documents" have not been = published.

Cheers,

Simon=


Il giorno 04/apr/2013, alle ore = 16:42, Peter Saint-Andre ha scritto:

FYI.


-------- Original Message = --------
Subject: [dispatch] conference roles
Date: Wed, 03 Apr = 2013 19:56:01 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: = DISPATCH <dispatch@ietf.org>

RFC = 4575 (Section 5.6.3) defines the concept of a role in a
conference, = but does not specify or define any roles.

5.6.3. = <roles>

  This element MAY contain a set of = human-readable strings describing
  the roles of the user = in the conference.  Note that this information
  is = applicable for human consumption only.  This specification does
=   not define the set of possible conferencing roles or the = semantics
  associated with each.  It is expected = that future conferencing
  specifications will define = these and the corresponding schema
  extensions, as = appropriate.

RFC 6501 (Section 4.6.5.2) specifies a few values = for the role
element, but does not actually define what those values = mean.

4.6.5.2. <roles>

  A <role> = provides the context for the set of conference operations
=   that a participant can perform.  This element can = contain one or more
  of the following values: = "administrator", "moderator", "user",
  "participant", = "observer", and "none".  A role of "none" indicates
=   that any role is assigned.  The <roles> semantic = definition is out of
  the scope of this document and is = subject to future policy documents.
  This element can be = extended with new roles in future documents.

(As far as I know, = those "future policy documents" have not been
published.)

More = recently, draft-groves-clue-capture-attr specifies several
additional = roles: "manager", "chairman", "secretary", "lecturer", and
"audience" = (so-called person roles) as well as "speaker" and
"controller" = (so-called conference roles). Personally, I happen to
have an = interest in defining a few other roles, such as "host",
"presenter", = "scribe", and "panelist".

Unfortunately there's quite a bit of = overlap and confusion here. For
instance, one could argue that = "host", "manager", and "controller"
(perhaps even "chairman") are the = same as or very similar to
"administrator" or "moderator" from RFC = 6501. There might also be
overlap between "lecturer", "speaker", and = "presenter" (and between
"speaker" and = "panelist").

Furthermore, I'm concerned that various = implementations will define
their own roles, blithely unaware that = very similar (or even identical
but differently named roles) are = already in use by other implementations.

It strikes me that one = solution here would be to establish an IANA
registry for conference = roles, with a registration policy (cf. RFC
5226) of at least Expert = Review and perhaps Specification Required (I
think RFC Required is a = bit heavy). IMHO this would help to prevent
continued confusion and = the minting of new roles that overlap with
existing = roles.

Thoughts?

Peter

______________________________= _________________
dispatch mailing list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch


_______________________________= ________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_13FD6C6E-34DD-4719-AF81-930BE15282FA-- From internet-drafts@ietf.org Sat Apr 6 01:06:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF56021F8D33; Sat, 6 Apr 2013 01:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cRUcNMYYGDZ; Sat, 6 Apr 2013 01:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAD221F8D05; Sat, 6 Apr 2013 01:06:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130406080656.19654.80890.idtracker@ietfa.amsl.com> Date: Sat, 06 Apr 2013 01:06:56 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2013 08:06:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Filename : draft-ietf-clue-telepresence-use-cases-05.txt Pages : 17 Date : 2013-04-06 Abstract: Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Christian.Groves@nteczone.com Sun Apr 7 22:40:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4025021F91B0 for ; Sun, 7 Apr 2013 22:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6roLICIOuJJx for ; Sun, 7 Apr 2013 22:40:15 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEDF21F91BC for ; Sun, 7 Apr 2013 22:40:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAChXYlF20S1b/2dsb2JhbAANRIM8wSWBG4MTAQEBBAEBATUbFQMDCg0ECxEDAQIBCRYPCQMCAQIBFSgIEwYCAQEXiAWqB5JTBI8YEgaDOwOrHw Received: from ppp118-209-45-91.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.91]) by ipmail07.adl2.internode.on.net with ESMTP; 08 Apr 2013 15:10:13 +0930 Message-ID: <5162583A.1010807@nteczone.com> Date: Mon, 08 Apr 2013 15:40:10 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> In-Reply-To: <515D9165.7@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2013 05:40:16 -0000 Hello Peter, I had envisaged that from the CLUE perspective that an IANA registry would be establish for Role (and some of the attributes). I'm not sure that it is possible to harmonise RFC4575, RFC6501 and CLUE as I think they have different semantics. RFC4575 seems just to have a free text field that's human readable. The goal of the CLUE "role" attribute is to have a set of tags which are human readable and able to used in an automatic way. RFC6501 talks about "conference operations that a participant can perform" I think this is semantically different to what is being proposed in CLUE which is more about the person/s in a capture (i.e. those depicted in the RTP stream). If it helps lessen the confusion we could change the name of the CLUE parameter from "role" to "Character", "Captured Persons" or "Person represented by media", etc.? With the semantic that the media contains a person who is acting in that character/role. I think part of the challenge will be to define the values. A person can have multiple roles/characters, e.g. a chairman who is acting as a scribe. Some have a similar function but have a different connotation e.g. presenter versus lecturer. I think to move forward we need to address these sorts of things. The previous RFCs seem to have largely ignored the problem in the final text. I'm not implying that it wasn't considered in their development. Regards, Christian On 5/04/2013 1:42 AM, Peter Saint-Andre wrote: > FYI. > > > -------- Original Message -------- > Subject: [dispatch] conference roles > Date: Wed, 03 Apr 2013 19:56:01 -0600 > From: Peter Saint-Andre > To: DISPATCH > > RFC 4575 (Section 5.6.3) defines the concept of a role in a > conference, but does not specify or define any roles. > > 5.6.3. > > This element MAY contain a set of human-readable strings describing > the roles of the user in the conference. Note that this information > is applicable for human consumption only. This specification does > not define the set of possible conferencing roles or the semantics > associated with each. It is expected that future conferencing > specifications will define these and the corresponding schema > extensions, as appropriate. > > RFC 6501 (Section 4.6.5.2) specifies a few values for the role > element, but does not actually define what those values mean. > > 4.6.5.2. > > A provides the context for the set of conference operations > that a participant can perform. This element can contain one or more > of the following values: "administrator", "moderator", "user", > "participant", "observer", and "none". A role of "none" indicates > that any role is assigned. The semantic definition is out of > the scope of this document and is subject to future policy documents. > This element can be extended with new roles in future documents. > > (As far as I know, those "future policy documents" have not been > published.) > > More recently, draft-groves-clue-capture-attr specifies several > additional roles: "manager", "chairman", "secretary", "lecturer", and > "audience" (so-called person roles) as well as "speaker" and > "controller" (so-called conference roles). Personally, I happen to > have an interest in defining a few other roles, such as "host", > "presenter", "scribe", and "panelist". > > Unfortunately there's quite a bit of overlap and confusion here. For > instance, one could argue that "host", "manager", and "controller" > (perhaps even "chairman") are the same as or very similar to > "administrator" or "moderator" from RFC 6501. There might also be > overlap between "lecturer", "speaker", and "presenter" (and between > "speaker" and "panelist"). > > Furthermore, I'm concerned that various implementations will define > their own roles, blithely unaware that very similar (or even identical > but differently named roles) are already in use by other implementations. > > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. > > Thoughts? > > Peter > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Apr 8 18:39:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A39C21F8E7B for ; Mon, 8 Apr 2013 18:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XJTNBMqPgu1 for ; Mon, 8 Apr 2013 18:39:51 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 9415021F8DD6 for ; Mon, 8 Apr 2013 18:39:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBACNwY1F20TFL/2dsb2JhbAANRIM8wTuBIoMTAQEBBAEBATUbFQMDCwwECxEDAQEBAQkeBw8CFh8JCAYNAQUCAQERBogFqgyDMZAgBI8YCwcGgzsDqx8 Received: from ppp118-209-49-75.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.49.75]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Apr 2013 11:09:48 +0930 Message-ID: <51637163.20405@nteczone.com> Date: Tue, 09 Apr 2013 11:39:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Hammer References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <00C069FD01E0324C9FFCADF539701DB33274178C@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB33274178C@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2013 01:39:52 -0000 Hello Mike, The intention is that role would be for both automated operation and possible human consumption. The idea is that an endpoint may have policy to select captures based on this sort of information. For example: I may have a 3 screen system but be in conference with three other endpoints. One of which may be where the Chief executive is sitting. If I have a policy of always seeing the Chief Executive then my endpoint would be able to automatically choose the capture with the Chief executive. The endpoint may also add an icon etc to the video display indicating it is related to the Chief executive this would be for human consumption. Regards, Christian On 8/04/2013 11:19 PM, Michael Hammer wrote: > Could someone clarify whether these "roles" have any technical implication > (affects automated system operation) or are they just for display for human > consumption? > > If the latter, I would question a need for an IANA registry. > (Note, you will also have to internationalize them as well and you won't > please all cultures.) > If someone wants to declare themselves Chief Executive and Bottle Washer, > who cares? > > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Monday, April 08, 2013 1:40 AM > To: clue@ietf.org > Subject: Re: [clue] Fwd: [dispatch] conference roles > > Hello Peter, > > I had envisaged that from the CLUE perspective that an IANA registry would > be establish for Role (and some of the attributes). I'm not sure that it is > possible to harmonise RFC4575, RFC6501 and CLUE as I think they have > different semantics. > > RFC4575 seems just to have a free text field that's human readable. The goal > of the CLUE "role" attribute is to have a set of tags which are human > readable and able to used in an automatic way. > > RFC6501 talks about "conference operations that a participant can perform" I > think this is semantically different to what is being proposed in CLUE which > is more about the person/s in a capture (i.e. > those depicted in the RTP stream). > > If it helps lessen the confusion we could change the name of the CLUE > parameter from "role" to "Character", "Captured Persons" or "Person > represented by media", etc.? With the semantic that the media contains a > person who is acting in that character/role. > > > I think part of the challenge will be to define the values. A person can > have multiple roles/characters, e.g. a chairman who is acting as a scribe. > Some have a similar function but have a different connotation e.g. presenter > versus lecturer. I think to move forward we need to address these sorts of > things. The previous RFCs seem to have largely ignored the problem in the > final text. I'm not implying that it wasn't considered in their development. > > Regards, Christian > > On 5/04/2013 1:42 AM, Peter Saint-Andre wrote: >> FYI. >> >> >> -------- Original Message -------- >> Subject: [dispatch] conference roles >> Date: Wed, 03 Apr 2013 19:56:01 -0600 >> From: Peter Saint-Andre >> To: DISPATCH >> >> RFC 4575 (Section 5.6.3) defines the concept of a role in a >> conference, but does not specify or define any roles. >> >> 5.6.3. >> >> This element MAY contain a set of human-readable strings describing >> the roles of the user in the conference. Note that this information >> is applicable for human consumption only. This specification does >> not define the set of possible conferencing roles or the semantics >> associated with each. It is expected that future conferencing >> specifications will define these and the corresponding schema >> extensions, as appropriate. >> >> RFC 6501 (Section 4.6.5.2) specifies a few values for the role >> element, but does not actually define what those values mean. >> >> 4.6.5.2. >> >> A provides the context for the set of conference operations >> that a participant can perform. This element can contain one or more >> of the following values: "administrator", "moderator", "user", >> "participant", "observer", and "none". A role of "none" indicates >> that any role is assigned. The semantic definition is out of >> the scope of this document and is subject to future policy documents. >> This element can be extended with new roles in future documents. >> >> (As far as I know, those "future policy documents" have not been >> published.) >> >> More recently, draft-groves-clue-capture-attr specifies several >> additional roles: "manager", "chairman", "secretary", "lecturer", and >> "audience" (so-called person roles) as well as "speaker" and >> "controller" (so-called conference roles). Personally, I happen to >> have an interest in defining a few other roles, such as "host", >> "presenter", "scribe", and "panelist". >> >> Unfortunately there's quite a bit of overlap and confusion here. For >> instance, one could argue that "host", "manager", and "controller" >> (perhaps even "chairman") are the same as or very similar to >> "administrator" or "moderator" from RFC 6501. There might also be >> overlap between "lecturer", "speaker", and "presenter" (and between >> "speaker" and "panelist"). >> >> Furthermore, I'm concerned that various implementations will define >> their own roles, blithely unaware that very similar (or even identical >> but differently named roles) are already in use by other implementations. >> >> It strikes me that one solution here would be to establish an IANA >> registry for conference roles, with a registration policy (cf. RFC >> 5226) of at least Expert Review and perhaps Specification Required (I >> think RFC Required is a bit heavy). IMHO this would help to prevent >> continued confusion and the minting of new roles that overlap with >> existing roles. >> >> Thoughts? >> >> Peter >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> 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 Christian.Groves@nteczone.com Tue Apr 9 17:03:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0145021F9813 for ; Tue, 9 Apr 2013 17:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjlgEN2d2jas for ; Tue, 9 Apr 2013 17:03:21 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BD21F9806 for ; Tue, 9 Apr 2013 17:03:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAHCrZFF20U+X/2dsb2JhbAANRIM8wTeBK4MTAQEBBAEBATUbFQMDCgEMBAsRAwEBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQERBogFqy+TVASPCQsHBoM7A5Mvl3Y Received: from ppp118-209-79-151.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.79.151]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Apr 2013 09:33:16 +0930 Message-ID: <5164AC43.2040006@nteczone.com> Date: Wed, 10 Apr 2013 10:03:15 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Hammer References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <00C069FD01E0324C9FFCADF539701DB33274178C@EX2K10MB1.corp.yaanatech.com> <51637163.20405@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3327439CC@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3327439CC@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: [dispatch] conference roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2013 00:03:23 -0000 Hello Mike, I think we are looking from different perspectives. I think what you are suggesting is that the provider is suggesting a priority for the display. My thought is that its the consumer who determines who to display. The CEO might have an ego that he wants to be displayed, but he may also be a terrible bore and I may want to see the scribe to see how much they're taking in... There was also a proposal for a priority attribute which could handle the guess of the Advertiser suggesting importance of captures. With regards to the display text we could have a "display text" attribute for something like a person's name. I guess any offensive text can be handled by the conference participants :-). I don't know that this lessens the issues associated with a registry. Regards, Christian On 9/04/2013 11:01 PM, Michael Hammer wrote: > Christian, > > Thanks for explanation. I think it is possible that there could be > situations where even though there is one or more CEOs present, another > person, say President of US is on, or some other sense of priority, where > CEO may not want to be in spotlight, but, say let the CFO be leading. That > suggests to me that the title and the priority order are really two separate > things. > > It might be better to split this into two indicators, one that is strictly > for display, the provides whatever title or label you want to have, no > rules, no registry. The other is an indicator of precedence that could > align with who is CEO, or could line up in some other way. I believe that > would give you the flexibility to do your auto-ordering, while at the same > time avoid the headaches of keeping an internationalized registry and > worrying whether someone wants to call themselves the Prophet or something > that others might find offensive. > > Mike > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, April 08, 2013 9:40 PM > To: Michael Hammer > Cc: clue@ietf.org > Subject: Re: [clue] Fwd: [dispatch] conference roles > > Hello Mike, > > The intention is that role would be for both automated operation and > possible human consumption. The idea is that an endpoint may have policy to > select captures based on this sort of information. For example: I may have a > 3 screen system but be in conference with three other endpoints. > One of which may be where the Chief executive is sitting. If I have a policy > of always seeing the Chief Executive then my endpoint would be able to > automatically choose the capture with the Chief executive. The endpoint may > also add an icon etc to the video display indicating it is related to the > Chief executive this would be for human consumption. > > Regards, Christian > > On 8/04/2013 11:19 PM, Michael Hammer wrote: >> Could someone clarify whether these "roles" have any technical >> implication (affects automated system operation) or are they just for >> display for human consumption? >> >> If the latter, I would question a need for an IANA registry. >> (Note, you will also have to internationalize them as well and you >> won't please all cultures.) If someone wants to declare themselves >> Chief Executive and Bottle Washer, who cares? >> >> Mike >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Christian Groves >> Sent: Monday, April 08, 2013 1:40 AM >> To: clue@ietf.org >> Subject: Re: [clue] Fwd: [dispatch] conference roles >> >> Hello Peter, >> >> I had envisaged that from the CLUE perspective that an IANA registry >> would be establish for Role (and some of the attributes). I'm not sure >> that it is possible to harmonise RFC4575, RFC6501 and CLUE as I think >> they have different semantics. >> >> RFC4575 seems just to have a free text field that's human readable. >> The goal of the CLUE "role" attribute is to have a set of tags which >> are human readable and able to used in an automatic way. >> >> RFC6501 talks about "conference operations that a participant can >> perform" I think this is semantically different to what is being >> proposed in CLUE which is more about the person/s in a capture (i.e. >> those depicted in the RTP stream). >> >> If it helps lessen the confusion we could change the name of the CLUE >> parameter from "role" to "Character", "Captured Persons" or "Person >> represented by media", etc.? With the semantic that the media contains >> a person who is acting in that character/role. >> >> >> I think part of the challenge will be to define the values. A person >> can have multiple roles/characters, e.g. a chairman who is acting as a > scribe. >> Some have a similar function but have a different connotation e.g. >> presenter versus lecturer. I think to move forward we need to address >> these sorts of things. The previous RFCs seem to have largely ignored >> the problem in the final text. I'm not implying that it wasn't considered > in their development. >> Regards, Christian >> >> On 5/04/2013 1:42 AM, Peter Saint-Andre wrote: >>> FYI. >>> >>> >>> -------- Original Message -------- >>> Subject: [dispatch] conference roles >>> Date: Wed, 03 Apr 2013 19:56:01 -0600 >>> From: Peter Saint-Andre >>> To: DISPATCH >>> >>> RFC 4575 (Section 5.6.3) defines the concept of a role in a >>> conference, but does not specify or define any roles. >>> >>> 5.6.3. >>> >>> This element MAY contain a set of human-readable strings describing >>> the roles of the user in the conference. Note that this information >>> is applicable for human consumption only. This specification does >>> not define the set of possible conferencing roles or the semantics >>> associated with each. It is expected that future conferencing >>> specifications will define these and the corresponding schema >>> extensions, as appropriate. >>> >>> RFC 6501 (Section 4.6.5.2) specifies a few values for the role >>> element, but does not actually define what those values mean. >>> >>> 4.6.5.2. >>> >>> A provides the context for the set of conference operations >>> that a participant can perform. This element can contain one or > more >>> of the following values: "administrator", "moderator", "user", >>> "participant", "observer", and "none". A role of "none" indicates >>> that any role is assigned. The semantic definition is out > of >>> the scope of this document and is subject to future policy > documents. >>> This element can be extended with new roles in future documents. >>> >>> (As far as I know, those "future policy documents" have not been >>> published.) >>> >>> More recently, draft-groves-clue-capture-attr specifies several >>> additional roles: "manager", "chairman", "secretary", "lecturer", and >>> "audience" (so-called person roles) as well as "speaker" and >>> "controller" (so-called conference roles). Personally, I happen to >>> have an interest in defining a few other roles, such as "host", >>> "presenter", "scribe", and "panelist". >>> >>> Unfortunately there's quite a bit of overlap and confusion here. For >>> instance, one could argue that "host", "manager", and "controller" >>> (perhaps even "chairman") are the same as or very similar to >>> "administrator" or "moderator" from RFC 6501. There might also be >>> overlap between "lecturer", "speaker", and "presenter" (and between >>> "speaker" and "panelist"). >>> >>> Furthermore, I'm concerned that various implementations will define >>> their own roles, blithely unaware that very similar (or even >>> identical but differently named roles) are already in use by other > implementations. >>> It strikes me that one solution here would be to establish an IANA >>> registry for conference roles, with a registration policy (cf. RFC >>> 5226) of at least Expert Review and perhaps Specification Required (I >>> think RFC Required is a bit heavy). IMHO this would help to prevent >>> continued confusion and the minting of new roles that overlap with >>> existing roles. >>> >>> Thoughts? >>> >>> Peter >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> _______________________________________________ >>> 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 Christian.Groves@nteczone.com Wed Apr 10 04:12:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC25421F8AB0 for ; Wed, 10 Apr 2013 04:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yO-7-3KGJCV for ; Wed, 10 Apr 2013 04:12:10 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 07CD021F8B08 for ; Wed, 10 Apr 2013 04:12:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCADxIZVF20U+X/2dsb2JhbAANQ8RbBASBKINSGyU9FhgDAgECAUsNCAEBsnCTPpJcA6sl Received: from ppp118-209-79-151.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.79.151]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Apr 2013 20:42:08 +0930 Message-ID: <51654906.2040000@nteczone.com> Date: Wed, 10 Apr 2013 21:12:06 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2013 11:12:10 -0000 X-List-Received-Date: Wed, 10 Apr 2013 11:12:10 -0000 Hello There seems to be some agreement that the Configure returns selected captures along with the chosen encoding. CSEs are not valid in the Configure. The framework in section 6.2.2 Capture Scene Entries says: "The consumer, when it requests media captures from this Capture Scene Entry, should also include this attribute but with only the single value (from among the values indicated by the provider) indicating the Consumer's choice for which policy it wants the provider to use." I'm not sure how CSE attributes work with the above agreement? Regards, Christian From mary.ietf.barnes@gmail.com Tue Apr 16 10:26:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2021F90A1 for ; Tue, 16 Apr 2013 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.04 X-Spam-Level: X-Spam-Status: No, score=-100.04 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OQVVCw4h0Ux for ; Tue, 16 Apr 2013 10:26:32 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5351D21F8FC0 for ; Tue, 16 Apr 2013 10:26:32 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b10so413137qen.14 for ; Tue, 16 Apr 2013 10:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vSJ7o+DRfHyOa92ml6ChUZMOdkOs/0Tw/NWNyB3eyU8=; b=CNf+LBScGDm6TiOC2i2MlpQgI3Ijdf2UBCY+a2VJApbbPT7lO70MqHcCjGVUcRVZxc hoHD/+WTWic4oYhUCjFtiBG8LFUQA6SApWNPJo539o5qbRIi9viClycXkuYK/FJXOraF i+9vAX9InWsebYStMC58lRlb3KaPsYcuh4vBG0Cwr8nDeTOyg5lqz4XNJ5OupAEKp3yC /WQQff4jHAnf6Z9ZqzE43/WecpsU5DpIQBNLwOZqTXc7bdo0rsDNA+hBghCM5EZ/w/Ul +nSJ1d+kDKqrtYGX+BC/zdne5+60aW157KzMVeKAH/GSFg+KJZNnN7RvDjDrwmIiFshX M2eA== MIME-Version: 1.0 X-Received: by 10.224.53.11 with SMTP id k11mr3838923qag.3.1366133191645; Tue, 16 Apr 2013 10:26:31 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Tue, 16 Apr 2013 10:26:31 -0700 (PDT) Date: Tue, 16 Apr 2013 12:26:31 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/mixed; boundary=20cf306f73d89ac4fe04da7daba4 Subject: [clue] Draft CLUE meeting summary X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2013 17:26:35 -0000 --20cf306f73d89ac4fe04da7daba4 Content-Type: text/plain; charset=ISO-8859-1 --20cf306f73d89ac4fe04da7daba4 Content-Type: text/plain; charset=MACINTOSH; name="minutes-86-clue.txt" Content-Disposition: attachment; filename="minutes-86-clue.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hflcfdzt0 TWludXRlcyBmb3IgQ0xVRSBXRyBAIElFVEYgODYKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KCkRhdGUocyk6ICBNb25kYXksIE1hciAxMSwgMjAxMywgOTowMC0x MTozMCAgCiAgICAgICAgICBUaHVyc2RheSwgTWFyIDE0LCAyMDEzLCAxMzowMC0xNTowMCAoQ2Fy aWJiZWFuIElJKQpMb2NhdGlvbjogT3JsYW5kbywgRkwsIFVTQQpDaGFpcnM6CU1hcnkgQmFybmVz LCBQYXVsIEt5eml2YXQKCk5vdGUgVGFrZXJzOgkKLSBTZXNzaW9uIDE6ICAgQm8gQnVybWFubiwg Um9iIEhhbnNlbiwgQW5kcmV3IEh1dHRvbgotIFNlc3Npb24gMjogICBNYWdudXMgV2VzdGVybHVu ZCwgSmVhbiBNYWhvbmV5CgpNZWV0ZWNobyByZWNvcmRpbmc6IAotIFNlc3Npb24gMTogCmh0dHA6 Ly9pZXRmODYuY29uZi5tZWV0ZWNoby5jb20vaW5kZXgucGhwL1JlY29yZGVkX1Nlc3Npb25zI0lF VEY4Nl9DTFVFCgotIFNlc3Npb24gMjogCmh0dHA6Ly9pZXRmODYuY29uZi5tZWV0ZWNoby5jb20v aW5kZXgucGhwL1JlY29yZGVkX1Nlc3Npb25zI0NMVUVfSUkKClN1bW1hcnkKPT09PT09PQoKRGlz Y3Vzc2lvbiBTdW1tYXJ5L0NvbmNsdXNpb25zOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQotIEZyYW1ld29yazogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvc2xp ZGVzL3NsaWRlcy04Ni1jbHVlLTIucGRmCi0tIE5lZWQgdG8gY2xhcmlmeSB0aGF0IHlvdSBjYW4n dCBoYXZlIHRoZSBzYW1lIHRoaW5nIGluIHNpbXVsdGFuZW91cyB0cmFuc21pc3Npb24gc2V0cyAo U1RTKS4KLS0gTWFyayB0byBwcm9wb3NlIHRleHQgb24gdGhlIG1haWxpbmcgbGlzdCBmb3IgYnVs bGV0IDIgKGNoYXJ0IDQgb2YgZnJhbWV3b3JrIHByZXNlbnRhdGlvbiAtIGV4cHJlc3Npb24gb2Yg U1RTIGluIHRlcm1zIG9mIENhcHR1cmUgU2V0cywgQ2FwdHVyZSBTZXQgRW50cmllcywgYW5kIE1l ZGlhIGNhcHR1cmVzKQotLSBSZW1vdmUgdm9sdW1lL2FyZWEgb2Ygc2NlbmUgdW5sZXNzIHNvbWVv bmUgaWRlbnRpZmllcyBhIGNvbXBlbGxpbmcgcmVhc29uIHdoeSB3ZSBuZWVkIGl0LiAgCi0tIEFn cmVlbWVudCB0byBhZGQgcHJvcG9zYWxzIGZyb20gZ3JvdmVzLWNsdWUtY2FwdHVyZS1hdHRyIHRv IHRoZSBmcmFtZXdvcmsgKGFuZCByZW1vdmUgY3VycmVudCBjb250ZW50IGF0dHJpYnV0ZSkuICAK LSBEYXRhIG1vZGVsOiAKLSBTaWduYWxpbmc6ICAKLSBDTFVFICYgU0RQOiAgICAKCkFjdGlvbiBJ dGVtczoKLS0tLS0tLS0tLS0tLQotIFRlYW0gdG8gY29udGludWUgd29ya2luZyBvdXQgUlRQIFRh eG9ub215IGZvciBtdWx0aS1zdHJlYW0gY29uc2lkZXJpbmcgUlRDV0VCLCBBVlQgYW5kIE1NVVNJ QyB3b3JrIGl0ZW1zLiAoSm9uYXRoYW4sIFJvbmksIEp1c3RpbiwgQ29saW4sIE1hZ251cywgQm8u Li4gKSAgCgotIERvY3VtZW50czogCi0tIFJlcXVpcmVtZW50czogVXBkYXRlcyByZXF1aXJlZCBm b3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgKE1hcnkpCi0tIFVzZSBDYXNlczogIE5lZWRzIGEg cmVmcmVzaCAoUm9uaSkgYW5kIFJldmlldyAoV0cpCi0tIEZyYW1ld29yazoKLS0tIENvbXBsZXRl IHJlZmFjdG9yIG9mIEZyYW1ld29yayBkb2N1bWVudCAoU3RlcGhhbiAtIHdpdGggQW5keSBhbmQg TWFyaykKLS0tIFVwZGF0ZXMgcmVmbGVjdGluZyBjb25jbHVzaW9ucyBmcm9tIGRpc2N1c3Npb24g YXQgdGhlIG1lZXRpbmcgYW5kIHBvc3QtbWVldGluZyBtYWlsaW5nIGxpc3QgKGFzIGlkZW50aWZp ZWQgYWJvdmUpLiAoTWFyaywgQW5keSkgW05vdGU6IGNoYWlycyBuZWVkIHRvIGNsb3NlIHJlbGV2 YW50IHRpY2tldHMuXQoKLS0gQ0xVRSAmIFNEUCBzaWduYWxpbmcgZG9jdW1lbnQ6ICAKLS0tIFJv YiBIYW5zZW4gLSBpbmNvcnBvcmF0ZSAocmV2aXNlZCkgbWF0ZXJpYWwgZnJvbSBkcmFmdCBpbnRv IGRyYWZ0LWt5eml2YXQtY2x1ZS1zaWduYWxpbmcuCgoKLS0gRGF0YSBtb2RlbDogUm9iZXJ0YSwg U2ltb24uICBTdWJtaXQgZHJhZnQtcHJlc3RhLWNsdWUtZGF0YS1tb2RlbC1zY2hlbWEtMDMuICBV cGRhdGUgLTA0IGluY29ycG9yYXRpbmcgdGV4dHVhbCBkZXNjcmlwdGlvbnMgZnJvbSBkcmFmdC1y b21hbm93LWNsdWUtZGF0YS1tb2RlbCArIHJlbGV2YW50IG1hdGVyaWFsIGZyb20gRlcuICBbV2Ug Y2FuIHRoZW4gZG8gYSBjYWxsIGZvciBhY2NlcHRhbmNlIGFzIGEgV0cgZG9jdW1lbnQgb24gdGhl IC0wNS5dCgoKRGV0YWlsZWQgbWludXRlcwo9PT09PT09PT09PT09PT09PQoKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KQm8gQnVybWFubiwgRGV0YWlsZWQg bm90ZXMgZm9yIE1vbmRheSwgTWFyY2ggMTEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09CiAKRnJhbWV3b3JrCk1hcmsgRHVja3dvcnRoCk1hcnk6IERvbid0 IG5lZWQgZXhwbGljaXQgcmVmZXJlbmNlIGluIEZyYW1ld29yayB0byBTRFAgYW5kIHNpZ25hbGlu ZyBzb2x1dGlvbjsgdGhhdCBpcyBpbiB0aGUgc2lnbmFsaW5nIGRvY3VtZW50Ck1hcms6IE1vcmUg Y2xlYXIgdGhhdCBDTFVFIGlzIGNvbmZvcm1pbmcgdG8gU0RQCk1hcnk6IHllcwpSb25pOiBkbyBT aW11bHRhbmVvdXMgVHJhbnNtaXNzaW9uIFNldHMgKFNUUykgcmVhbGx5IGNvbnRhaW4gY2FwdHVy ZSBzZXRzPwpNYXJrOiBzaG91bGQgYmUgY2FwdHVyZSBzY2VuZXMsIGNhcHR1cmUgc2NlbmUgZW50 cmllcywgYW5kIG1lZGlhIGNhcHR1cmVzLiBXb3VsZCBoYXZlIHRvIGRlZmluZSB3aGF0IHRoaXMg aXMKU3RlcGhhbjogVGhpcyBpcyB0d28gdHJlZXMgY29taW5nIGZyb20gdHdvIGRpZmZlcmVudCBz aWRlcy4gQ2FwdHVyZSBTY2VuZSBFbnRyaWVzIChDU0UpIGFyZSBnZW9tZXRyaWMuIFNUUyBhcmUg aW4gYW5vdGhlciBkaW1lbnNpb24KUGF1bDogZnJvbSB0aGUgYmVnaW5uaW5nIFNUUyBpcyBhIHNl dCBvZiBjYXB0dXJlcywgdG8gYWxsb3cgQ1NFIGluIHRoZXJlIGlzIGEgc3ludGFjdGljIHRoaW5n LCBpdCBkb2VzIG5vdCBjaGFuZ2UgYW55dGhpbmcsIGl0IGlzIGp1c3QgbGlzdGluZyB0aGVtIGFs bApSb25pOiBpZiBhIHNpbmdsZSBjYW1lcmEgY2FuIGJlIHpvb21lZCBpbiBhbiB6b29tZWQgb3V0 IGFzIHR3byBkaWZmZXJlbnQgQ1NFLCB0aGV5IGNhbiBub3QgYm90aCBiZSBpbiB0aGUgc2FtZSBT VFMKUm9iIEg6IGlmIHlvdSBjYW4gc2VuZCB0aGUgZW50aXJlIGNhcHR1cmUgc2NlbmUgeW91IGNh biBwdXQgaXQgdGhlcmUsIG90aGVyd2lzZSBub3QKUm9uaTogbm90IHByYWN0aWNhbCB0byBoYXZl IHRoZSBTVFMgc2hvcnRoYW5kIGJ1dCBpbiBtb3N0IGNhc2VzIGl0IHdpbGwgbm90IGJlIHJlbGV2 YW50Ck1hcms6IGEgc2luZ2xlIHByb3ZpZGVyIGNhbiBoYXZlIGRpZmZlcmVudCBzZXRzIGFuZCBz b21lIGhhdmUgbm90LCBzbyB0aGUgcHJvdmlkZXIgZGVjaWRlcwpNYXJ5OiBhcmUgd2UgcmVhZHkg dG8gY2xvc2UgdGhpcyBkaXNjdXNzaW9uPwpSb25pOiBub3QgcHJhY3RpY2FsCkNocmlzdGVyOiBv ay4gV2UgbmVlZCB0byBtYWtlIGl0IHZlcnkgY2xlYXIgd2hhdCB0aGluZ3MgdGhhdCBvdmVybGFw LiBNdXN0IGJlIGNsZWFyIHRoYXQgdGhlIGRlc2NyaXB0aW9ucyBvZiBtdWx0aXBsZSBDU0UgYW5k IFNUUyBhcmUgc3ludGFjdGljYWxseSBvdmVybGFwcGluZwpNYXJrOiB5ZXMuIENvbmNsdXNpb24s IEZyYW1ld29yayAoRlcpIGVkaXRvcnMgcHJvdmlkZSB0ZXh0IGZvciBhbmQgcHV0IGl0IHRvIHRo ZSBtYWlsaW5nIGxpc3QuCkNocmlzdGVyOiBzaG91bGQgYWxsb3cgZm9yIGhhdmluZyBtdWx0aXBs ZSBtZWRpYSB0eXBlcyBpbiBhIENTRSwgaG93IGRvIHlvdSBrbm93IHdoaWNoIGNhbiBiZSBjb21i aW5lZD8gU2hvdWxkIGJlIGFsbG93ZWQKU3RldmU6IHlvdSdyZSBhbHNvIGNvbnN0cmFpbmVkIGlu IHdoYXQgeW91IGNhbiByZW5kZXIuIFlvdSB3b3VsZCBhbnl3YXkgd2FudCB0byBzb21laG93IHNl cGFyYXRlIHRoZW0uCkNocmlzdGVyOiBob3cgZG8geW91IGNvbWJpbmUgd2hpY2ggYXVkaW8gQ1NF IHRoYXQgY2FuIGdvIHdpdGggd2hpY2ggdmlkZW8gQ1NFPwpSb25pOiB3aWxsIGJlIGNvbXBsaWNh dGVkIHRvIGtub3cgaG93IHRvIG1peCBhdWRpby1vbmx5LCB2aWRlby1vbmx5IGFuZCBhdWRpby12 aWRlbwpQYXVsOiBpZiB5b3UgaGF2ZSBzd2l0Y2hlZCB2aWRlbywgc2hvdWxkIHlvdSBmb3IgZXhh bXBsZSBhbHNvIHVzZSBzd2l0Y2hlZCBhdWRpbz8gV2UgbmVlZCBtb3JlIGRpc2N1c3Npb24gaW4g dGhlIGZyYW1ld29yayBhYm91dCBzd2l0Y2hpbmcuIElmIHlvdSBwaWNrIGF1ZGlvIGFuZCB2aWRl byBzZXBhcmF0ZWx5LCBjYW4gdGhleSBiZSBjb21iaW5lZCBhcmJpdHJhcmlseT8gTWF5YmUgeW91 IGNhbiBkbyBzb21ldGhpbmcgd2l0aCBzcGF0aWFsbHkgcmVsYXRlZCBjYXB0dXJlcz8KTWFyazog aWYgdGhleSBhcmUgZnJvbSB0aGUgc2FtZSBzY2VuZSwgdGhleSBhcmUgc3BhdGlhbGx5IHJlbGF0 ZWQKUGF1bDogaWYgeW91IGhhdmUgMyB2aWRlbyBhbmQgNSBhdWRpbywgd2hpY2ggb25lcyBzaG91 bGQgeW91IGNob29zZS4gSWYgeW91IGNob29zZSAxIHZpZGVvLCB3aGljaCBhdWRpbyBzaG91bGQg eW91IGNob29zZT8KTWFyazogcmVseSBvbiB0aGUgcHJvdmlkZXIuCkpvbmF0aGFuOiBDU0UgaXMg InRoaXMgaXMgdGhlIHdob2xlIHRoaW5nIi4gSSBkb24ndCBrbm93IHdoYXQgeW91J2QgZG8gYW5k IHdoYXQgaXQgbWVhbnMgaWYgeW91IGRvbid0IHdhbnQgaXQgYWxsIGFuZCBpZiBpdCBpcyBuZWNl c3NhcnkgdG8gZXhwcmVzcyB0aGlzLgpQYXVsOiBzaG91bGQgd2UgZXhwcmVzcyB0aGUgZnVsbCBj cm9zcyBwcm9kdWN0LiBJIHRoaW5rIG1vcmUgZGlzY3Vzc2lvbiBhYm91dCBzd2l0Y2hpbmcgd291 bGQgaGVscC4KTWFyazogYXJlIHRoZXJlIHN3aXRjaGluZyB1c2UgY2FzZXMgdGhhdCB3ZSBkaWQg bm90IGV4cHJlc3M/Ck1hcnk6IGlmIHdlIG5lZWQgY2xhcmlmaWNhdGlvbiBpbiB0aGUgRlcgYW5k IHdlIGRvbid0IGhhdmUgYSB1c2UgY2FzZSwgd2UgbmVlZCB0byBsb29rIGF0IHRoYXQKUm9uaTog c28gZmFyIHdlIG9ubHkgaGFkIGEgc2luZ2xlIGF1ZGlvIENTRS4gSSB0aGluayB0aGF0IFBhdWwg aXMgc2F5aW5nIGlzIHdoZW4geW91IGhhdmUgbXVsdGlwbGUgdmlkZW8gYW5kIG11bHRpcGxlIGF1 ZGlvIGl0IGlzIG5vdCBjbGVhciB3aGF0IHRvIGNob29zZQpSb2I6IHRoZXJlIG1heSBiZSBhdWRp by92aWRlbyBjb21iaW5hdGlvbnMgdGhhdCBkb24ndCBtYWtlIHNlbnNlClN0ZXZlOiB3ZSBhc3N1 bWUgYWxsIGNvbWJpbmF0aW9ucyB0aGF0IGFyZSBsaXN0ZWQgZG8gbWFrZSBzZW5zZQpNYXJrOiBh Z3JlZS4gSXQgd2FzIGltcGxpY2l0IGluIHRoZSBmcmFtZXdvcmsgdGhhdCBldmVyeXRoaW5nIHRo YXQgdGhlIHByb3ZpZGVyIGFubm91bmNlZCBkbyBtYWtlIHNlbnNlLiBBcmUgd2UgcXVlc3Rpb25p bmcgaWYgb3VyIGN1cnJlbnQgbWV0aG9kIGRvZXNuJ3QgbWFrZSBzZW5zZT8KTWFyeToKUm9uaTog dGhlcmUncyBhIGRpZmZlcmVudCBiZXR3ZWVuIHZhbGlkIGFuZCBwcmVmZXJyZWQKQ2hyaXN0ZXI6 IHNob3VsZCBiZSBwb3NzaWJsZSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgYXVkaW8gc2hvdWxkIGdv IHdpdGggdGhpcyB2aWRlby4gSSB0aG91Z2h0IHRoZSBlYXNpZXN0IHdhcyB0byBwdXQgdGhlbSBp biB0aGUgc2FtZSBDU0UsIGJ1dCB0aGVyZSBtYXkgYmUgYmV0dGVyIHdheXMsIGZvciBleGFtcGxl IGlmIHdlIHdhbnQgdG8gc2VwYXJhdGUgdGhlbS4gRm9yIGV4YW1wbGUgYSB3aG9sZSByb29tIHdp dGggYSB3aG9sZSByb29tIGF1ZGlvCk1hcnk6IGRvZXMgbm90IHRoaXMgZGVwZW5kIG9uIHRoZSB1 c2UgY2FzZT8KU3RldmU6IG5vdCBzbyBzdXJlIHRoYXQgeW91IHdhbnQgYSBzaW5nbGUgbWljIGlm IHlvdSBoYXZlIGEgc2luZ2xlIHZpZGVvLiBUaGVyZSBtYXkgYmUgdXNlIGZvciAzRCBhdWRpbyBm b3IgYSBzaW5nbGUgdmlkZW8uCk1hcnk6IGFjdGlvbiBpdGVtIG9uIENocmlzdGVyLCBkbyB3ZSBv ciBkbyB3ZSBub3QgaGF2ZSBhIG5lZWQgdG8gbGluayBtZWRpYSB0b2dldGhlci4KTWFyazogd2Ug ZG9uJ3QgaGF2ZSBhIHJlc29sdXRpb24gYWJvdXQgZGlmZmVyZW50IG1lZGlhIGZvciB0aGUgU1RT CkpvbmF0aGFuOiBkb2VzIG5vdCBtYWtlIHNlbnNlIHNpbmNlIFNUUyBpcyBhYm91dCBlbmNvZGlu ZyBtZWRpYQpNYXJrOiB3ZSBkb24ndCB3YW50IHRvIGNvbWJpbmUgbWVkaWEgaW4gdGhlIHNhbWUg c2V0Ck1hcms6IGtlZXAgdGhlIGFyZWEgb2Ygc2NlbmUgYXMgYW4gYXJlYSBub3QgYSB2b2x1bWUK UGF1bDogYXJlYSBvZiBzY2VuZSBkb2VzIG5vdCBtYWtlIHNlbnNlIGluIGFsbCBjYXNlczsgeW91 IG5lZWQgdGhlIDNyZCBkaW1lbnNpb24gdG8gdW5kZXJzdGFuZCB3aGF0IHlvdSd2ZSBnb3QuIFdo aWxlIHRoZXkgYXJlIHBsYW5hciB0aGV5IGFyZSBpbiAzIGRpbWVuc2lvbnMuCkNocmlzdGVyOiBh Z3JlZS4gSWYgeW91IG9ubHkgcHJvdmlkZSBhIGNlcnRhaW4gYXJlYSB5b3Ugc2hvdWxkIGV4cHJl c3MgdGhhdCBhcyBhIENTRS4gSWYgeW91IGFubm91bmNlIGEgQ1NFIHRoZW4geW91IHNob3VsZCBi ZSBhYmxlIHRvIHByb3ZpZGUgZXZlcnl0aGluZyBpbiBpdC4gSWYgeW91IGV4dGVuZCB0aGUgYXJl YSB5b3UgYWxzbyBuZWVkIHRvIHVwZGF0ZSBvciBhZGQgYW5vdGhlciBDU0UuIFF1ZXN0aW9uIHRo ZSB1c2Ugb2YgYXJlYSBvZiBzY2VuZS4KTWFyazogYXJlIHlvdSBzYXlpbmcgdGhlcmUgaXMgbm8g dmFsdWUgaW4gaGF2aW5nIHRoZSBsYXJnZXIgYXJlYSBvZiBzY2VuZSB0aGFuIHdoYXQgaXMgZXhw cmVzc2VkIGJ5IGluZGl2aWR1YWwgQ1NFPwpDaHJpc3RlcjogdGhpbmsgc28uCk1hcnk6IGlzIG5v dCB0aGlzIGNvbm5lY3RlZCB0byBhIHNwZWNpZmljIHVzZSBjYXNlPwpDaHJpc3RlcjogSSBkb24n dCBrbm93IHRoZSBzcGVjaWZpYyB1c2UgY2FzZSBidXQKUm9iIGg6IEkgY2FuIHNlZSB1c2UgZm9y IENTRSwgYnV0IHVuY2VydGFpbiB3aGF0IHlvdSBjYW4gZG8gd2l0aCBhcmVhIG9mIHNjZW5lIG9y IHZvbHVtZSBvZiBzY2VuZS4gWW91IGNhbiBkZXJpdmUgaXQgZnJvbSBpbmRpdmlkdWFsIENTRS4K U3RlcGhhbjogdGhlcmUgbXVzdCBoYXZlIGJlZW4gYSByZWFzb24gd2h5IGFyZWEgb2Ygc2NlbmUg ZW5kZWQgdXAgaW4gdGhlIEZXLiBJdCBpcyBlYXN5IHRvIGp1bXAgdG8gY29uY2x1c2lvbiB3aXRo b3V0IGJlaW5nIGFibGUgdG8gcmVtZW1iZXIgd2h5IGl0IHdhcyBwdXQgdGhlcmUgaW4gdGhlIGZp cnN0IHBsYWNlLgpNYXJrOiB0aGUgZ3JvdXAgZG9lcyBub3Qgc2VlbSB0byBiZSBhYmxlIHRvIHVu ZGVyc3RhbmQgd2h5IGFyZWEgb2Ygc2NlbmUgaXMgdGhlcmUKTWFyeTogYWN0aW9uIE1hcms6IGdv IGJhY2sgYW5kIGZpbmQgdGhlIHJlYXNvbiBmb3IgcHV0dGluZyBpbiBhcmVhIG9mIHNjZW5lCk1h cms6IHNob3VsZCBzY2VuZSBzd2l0Y2ggcG9saWN5IGJlIG9uIGNhcHR1cmUgc2V0IHJhdGhlciB0 aGFuIG9uIENTRT8KSm9uYXRoYW46IHJlYXNvbmFibGUgdGhhdCBwcm92aWRlciBwcm92aWRlcyBk aWZmZXJlbnQgQ1NFIHdpdGggZGlmZmVyZW50IHN3aXRjaCBwb2xpY2llcy4gQSBzaW5nbGUgc2Nl bmUgY2FuIGNvbnRhaW4gc29tZSBlbnRyaWVzIHRoYXQgYXJlIHN3aXRjaGVkIGFuZCBzb21lIHRo YXQgYXJlIG5vdC4gS2VlcCBhcyBpcy4KTWFyazogYWNjZXB0IGNoYW5nZXMgZnJvbSBkcmFmdC1n cm92ZXMtY2x1ZS1jYXB0dXJlLWF0dHIgaW4gRlcgKGFuZCBkYXRhIG1vZGVsKT8KQ2hyaXN0ZXI6 IG9rIHdpdGggdGhlIGRyYWZ0LiBJcyBhY3RpdmUgc3BlYWtlciBhIHJvbGUgb3IgYSBzd2l0Y2hp bmcgcG9saWN5PyBBIG1vc3QgYWN0aXZlLCBzZWNvbmQgbW9zdCBhY3RpdmUgZXRjLCBhcmUgdGhl eSBzZXBhcmF0ZSByb2xlcyBvciBzd2l0Y2hpbmcgcG9saWNpZXM/Ck1hcnk6IHNlZW1zIHRvIGJl IGNvbnNlbnN1cyB0aGF0IHRoaXMgbmVlZHMgdG8gYmUgYWRkZWQgdG8gdGhlIGZyYW1ld29yawpN YXJrOiByZW1vdmUgY29udGVudCBhdHRyaWJ1dGUsIHdoaWNoIGlzIHRvbyBsaW1pdGVkIGFuZCBj b25mdXNpbmcKQ2hyaXN0ZXI6IHJlbWVtYmVyIHRoYXQgY29udGVudCBhbmQgcm9sZSBjYW4gYmUg dHdvIGRpZmZlcmVudCB0aGluZ3MKTWFyazogcmUtZmFjdG9yaW5nIGZyYW1ld29yawpTdGVwaGFu OiBoYXZpbmcgeG1sLWlzaCwgYWxzbyBpbiBleGFtcGxlcywgd2l0aG91dCB0aGUgc2NoZW1hIGlz IGNvbmZ1c2luZyBub3QgcmVhbGx5IHVzZWZ1bC4gUHJvcG9zZSBleGFtcGxlIGRvY3VtZW50Ck1h cms6IGFncmVlIHRoYXQgc3ludGF4LW9yaWVudGVkIHN0dWZmIHNob3VsZCBub3QgaW4gYmUgdGhl IEZXLiBTaG91bGQgdGhlcmUgYmUgYSBtb3JlIGhpZ2ggbGV2ZWwgZGlzY3Vzc2lvbiBvciB3b3Vs ZCBpdCBiZSBzdWZmaWNpZW50IHdpdGggdGhlIGV4YW1wbGVzPwpNYXJ5OiB0aGUgRlcgc2hvdWxk IGRlc2NyaWJlIHdoYXQgZnVuY3Rpb25hbGl0aWVzIGl0IHByb3ZpZGVzLCBkb2VzIG5vdCBkZXNj cmliZSBzeW50YXguClBhdWw6IHJlZ2FyZGluZyBzd2l0Y2hpbmcsIGl0IHN0YXJ0cyB0byBpbXBh Y3QgaG93IHBlb3BsZSB1bmRlcnN0YW5kIGNsdWUuCk1hcnk6IFJUQ1dFQiBkaXNjdXNzZXMgc29s dXRpb24gc3BhY2UgYW5kIHRoYXQgc2hvdWxkIG5vdCBiZSBpbiB0aGUgRlcsIGJ1dCBpbiBhIHNv bHV0aW9uIGRvY3VtZW50ClN0ZXZlOiB0aGUgcHJvcG9zYWwgbWFkZSBieSBtYXJrIGluIHRoZSBw cmVzZW50YXRpb24gaXMgYWJvdXQgcmlnaHQuIENvbmNlcHRzIG5lZWQgdG8gZ28gZG93biB0byB0 aGUgbGV2ZWwgd2hlcmUgeW91IGNhbiBzZWUgdGhlIHVzZSBvZiB0aGVtLCBhbmQgYmUgYSBkaXNj dXNzaW9uIGluIHRleHQuCk1hcms6IGNvbmNlcHRzIHNob3VsZCBiZSBpbiB0aGUgZnJhbWV3b3Jr LiBDb3VsZCB0YWtlIGFub3RoZXIgbG9vayBhdCB0aGF0IGFuZCBpZiBjb25jZXB0cyBjb3VsZCBi ZSBwdXQgYmFjayBpbiB0aGUgRlcgYXMgbG9uZyBhcyB0aGV5IGNhbiBiZSBwdXQgaW4gdGV4dC4K TWFyazogdXBkYXRlIGV4YW1wbGVzLiBFbmNvdXJhZ2UgcGVvcGxlIHdpdGggc3BlY2lmaWMgaW50 ZXJlc3RzIHRvIGNvbnRyaWJ1dGUgd2l0aCBleGFtcGxlcy4gRWRpdG9ycyBzaG91bGQgaGVscCBm aXR0aW5nIHRoZW0gdG8gdGhlIGZyYW1ld29yay4KCkRhdGEgbW9kZWwKU2ltb24gUGlldHJvIFJv bWFubwpVcGRhdGVzIHJlbGF0ZWQgdG8gLTAyCktlaXRoOiBXaGF0IGFib3V0IHVwZGF0ZXMgdG8g InZpcnR1YWwiIC0wMywgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0PwpTaW1vbjogLTAzIGFuZCAtMDIK Um9iOiBwcmlvcml0eSB3b3VsZCBhbHNvLCBhZGRpdGlvbmFsbHksIGJlIHVzZWZ1bCBvbiBjYXB0 dXJlIHNjZW5lIGxldmVsClBhdWw6IHNob3VsZCBhbHNvIGJlIGFibGUgdG8gcHJpb3JpdGl6ZSBj YXB0dXJlcyBhY3Jvc3MgZGlmZmVyZW50IHNjZW5lcwpSb2JlcnQgc3BhcmtzOiBhcmUgdGhvc2Ug cmVsYXRpdmUgdG8gYWxsIGNhcHR1cmUgaW4gYWxsIHNjZW5lcz8KRGFuaWVsIFBldHJpZTogc2Nv cGUgb2YgcHJpb3JpdHk/ClBhdWw6IGNyb3NzIGV2ZXJ5dGhpbmcgaW4gdGhlIGFkdmVydGlzZW1l bnQuIEFkdmVydGlzZXIgc2V0cyBwcmlvcml0aWVzLgpNYXJrOiB3YXMgdGhlIGludGVudCB0byBk ZWNpZGUgdG8gc2VsZWN0IGFsbCBmcm9tIG9uZSBzY2VuZSBvciBvbmUgZW50cnkgZnJvbSBlYWNo IHNjZW5lPwpSb25pOiBvbiBtZWRpYSBjYXB0dXJlIGxldmVsLCB3aGljaCBtYXkgYmUgaW4gZGlm ZmVyZW50IHNjZW5lcwpQYXVsOiBDU0Ugd29yayB3aXRoaW4gYSBzY2VuZSwgYnV0IHdoZW4gcHJp b3JpdHkgbmVlZGVkIHdoZW4geW91IGNhbm5vdCBkbyBldmVyeXRoaW5nIGZyb20gYWxsIHNjZW5l cyBhbmQgdGhlbiB0aGV5IG5lZWQgdG8gYmUgY3Jvc3Mgc2NlbmUKQ2hyaXN0ZXI6IGdvb2QgYXR0 cmlidXRlLiBXZSBuZWVkIHRvIHRoaW5rIGlmIGl0IGlzIHBhcnQgb2YgdGhlIGRhdGEgbW9kZWwg b3IgaWYgaXQgaXMgcGFydCBvZiB0aGUgU0RQLgpTaW1vbjogbWFwcGluZyBmcm9tIGRhdGEgbW9k ZWwgdG8gU0RQIGlzIGEgc2VwYXJhdGUgaXNzdWUgYW5kIGEgbWF0dGVyIG9mIGRpc2N1c3Npb24u ClN0ZXBoYW46IHRoaXMgb3ZlcmFsbCBkaXNjdXNzaW9uIGJlbG9uZ3MgaW4gdGhlIEZXLgpNYXJ5 OiBkYXRhIG1vZGVsIGlzIHRoZSBpbnN0YW5jZSBvZiB0aGUgc2lnbmFsaW5nIG1vZGVsLiBOb3Qg eWV0IGluIHRoZSBmcmFtZXdvcmsgYW5kIG5lZWQgdG8gYmUgaW50cm9kdWNlZCB0aGVyZS4KU3Rl cGhhbjogSXMgZGF0YSBtb2RlbCBvbmx5IHhtbCBzdHVmZiBvciBpcyBpdCBldmVyeXRoaW5nPwpN YXJ5OiBldmVyeXRoaW5nClN0ZXBoYW46IGFyZSB3ZSBkZWZpbmluZyBuZXcgU0RQIGF0dHJpYnV0 ZXM/Ck1hcnk6IG5vdCBkZWNpZGVkLiBUaGlzIGlzIGFuIGFic3RyYWN0aW9uClJvbmk6IGlzIGlu IG9uIG1lZGlhIGNhcHR1cmUgbGV2ZWwgb3IgZGlmZmVyZW50IGVuY29kaW5nPyBJdCBzaG91bGQg YmUgcGVyIG1lZGlhIGNhcHR1cmUsIHdoaWNoIGlzIGNsdWUgc3BlY2lmaWMsIG5vdCBhbiBTRFAg dGVybS4KUm9iIGg6IHdlIG5lZWQgdG8gZGVmaW5lIHdoYXQgInJlbGF0ZWQgdG8iIG1lYW5zIGFu ZCB3ZSBuZWVkIHRvIGJlIG11Y2ggbW9yZSBzcGVjaWZpYy4KQ2hyaXN0ZXI6IHNvbWUgcmVsYXRl ZCBzdHJlYW1zIGNhbm5vdCBiZSBwcmVzZW50ZWQgYXQgb25jZSBhbmQgc2hvdWxkIGJlIGluIGRp ZmZlcmVudCBjc2UsIGZvciBleGFtcGxlIEVuZ2xpc2ggYW5kIEl0YWxpYW4gYXVkaW8sIGRvIHlv dSByZWFsbHkgbmVlZCB0aGlzIHJlbGF0ZWRUbyBpbiB0aGlzIGNhc2U/ClNpbW9uOiB0aGlzIGlz IGFuIElEUkVGIGFuZCB3ZSB0aGluayBpdCB3YXMgYmV0dGVyIHRoYW4gInN1cHBsZW1lbnRhcnkg aW5mb3JtYXRpb24iLCBidXQgbWF5YmUgdGhhdCBpcyBhbHNvIG5vdCBnb29kIGVub3VnaApTaW1v bjogPGR5bmFtaWM+CkNocmlzdGVyOiBuZWVkIHRvIGNoYW5nZSBzY2VuZSBpbmZvcm1hdGlvbiB0 b28sIHRoZW4uClNpbW9uOiB5ZXMuIE11c3QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSB1cGRhdGVz IGZvciB0aGF0Ck1hcms6IG1ha2VzIG1vcmUgc2Vuc2UgdG8gaW5jbHVkZSBpbiBzcGF0aWFsIGlu Zm9ybWF0aW9uIHBhcnQgb2YgdGhlIHNjZW5lClJvbmk6IGNvbWVzIGZyb20gdGVsZS1tZWRpY2Fs IHVzZSBjYXNlIHdoZXJlIHNvbWVvbmUgaGFzIGEgY2FtZXJhIHRoYXQgaXMgbW92aW5nIGFyb3Vu ZC4gU3BhdGlhbCBpbmZvcm1hdGlvbiBpcyBvcHRpb25hbCBhbmQgc3VjaCBjYW1lcmEgbmVlZCBu b3QgYmUgcHJvdmlkaW5nIHNwYXRpYWwgaW5mb3JtYXRpb24KU2ltb246IHNwYXRpYWwgaW5mb3Jt YXRpb24gY2FuIGJlIGEgc25hcHNob3QKUm9iZXJ0OiB5b3UgY2FuIGJlIGVudGVyaW5nIGluIGEg cGxhY2Ugb2YgbXVjaCBodXJ0IGlmIHlvdSBhbm5vdW5jZSBkeW5hbWljIHNwYXRpYWwgaW5mb3Jt YXRpb24uIFJlYWQgdGhlIHBvbGljeSBwYXJ0IG9mIHRoZSBnZW9wcml2IGRvY3VtZW50ClJvbmk6 IGp1c3QgaW5kaWNhdGUgdGhhdCB0aGlzIGRvZXMgbm90IGhhdmUgYSBmaXhlZCBwb2ludCBvZiBj YXB0dXJlClNpbW9uOiBzaW11bHRhbmVvdXNTZXQKUGF1bDogY2FwdHVyZSBzY2VuZSBhbmQgc2Nl bmUgZW50cnkgaXMgdGhlcmUgYnV0IG5vdCBzaW5nbGUgY2FwdHVyZQpNYXJrOiBhZ3JlZSB3aXRo IFBhdWwgYW5kIHRoaW5rIHRoYXQgd2FzIHdoYXQgd2Ugd2VyZSBzYXlpbmcgaW4gdGhlIEZXIGRp c2N1c3Npb24KU2ltb246IGNhcHR1cmVFbmNvZGluZy4gSXMgQ2hyaXN0ZXIgT0sgd2l0aCB0aGlz LCBzaW5jZSBoZSBoYXMgY29tbWVudGVkIG9uIGl0IG9uIHRoZSBsaXN0PwpDaHJpc3RlcjogeWVz Ck1hcnk6IHdpbGwgcG9zdCAtMDMgc29tZSB0aW1lIHRvZGF5IGFuZCB3ZSBjYW4gZGlzY3VzcyB0 aGlzIG1vcmUKClNpZ25hbGluZyBPdmVydmlldy9Jc3N1ZXMKUGF1bDogdmVyc2lvbmluZwpDaGFy bGVzIEU6IGFzIGluZm9ybWF0aW9uLCBpbiBCRkNQLCB0aGUgcHJvcG9zYWwgaXMgdG8gaGF2ZSB2 ZXJzaW9uIGluIFNEUCB3aGVuIHlvdSBuZWdvdGlhdGUgdGhlIHVzZSBvZiBCRkNQClBhdWw6IEFD SyBtZWNoYW5pc20gKHNldmVyYWwgdW5hbnN3ZXJlZCBxdWVzdGlvbnMpCkNoYXJsZXM6IG9uIHRo ZSBsaXN0IHRoZXJlIHdhcyBkaXNjdXNzaW9uIGFib3V0IGEgbm8tb3AgcGlnZ3liYWNrZWQgYWNr OyB0byBtZSB0aGlzIGxvb2tzIGxpa2UgYW4gZXhwbGljaXQgQUNLLiBDbGFyaWZpY2F0aW9uPwpQ YXVsOiB0aGF0IHdhcyBjb25jZWl2ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgYW5kIGl0IGlzIGxv b2tpbmcgbGVzcyBhdHRyYWN0aXZlIG5vdy4gUmV2aWV3IHdoYXQncyBpbiB0aGUgZHJhZnQgYW5k IHByb3ZpZGUgYWRkaXRpb25zLCByZXN0cnVjdHVyaW5nIGFuZCBhbHRlcm5hdGl2ZXMuIE5lZWQg dm9sdW50ZWVycyB0byBkbyB3b3JrLgpDaHJpc3RlcjogTmVlZCB0byBkZWNpZGUgYW5kIGNsYXJp ZnkgaWYgd2UgZG8gU0RQIG9yIENMVUUgZmlyc3QuCk1hcnk6IHRoaW5rIHdlIGFncmVlZCB0aGF0 IHlvdSBoYXZlIHRvIGRvIFNEUCBmaXJzdC4KUGF1bDogTm8sIHRoZXkgYXJlIGRlLWNvdXBsZWQ7 IHlvdSBjYW4gZG8gdGhlbSBpbiBhbnkgb3JkZXIuIFVzZSBjYXNlcyBvZiB0aGlzIGRvY3VtZW50 IGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlIG90aGVyIGRvY3VtZW50cwpDaHJpc3RlcjogTGVnYWN5 IGlzIGp1c3QgYSBwbGFjZWhvbGRlciB0b2RheS4gSSBoYWQgYW4gaWRlYSBvbmNlIHRoYXQgd2Fz IHByZXNlbnRlZCBvbiB0aGUgbGlzdCB3aGF0IGNhbiBiZSBkb25lOyBpdCB3b3VsZCBiZSBlYXNp ZXIgZm9yIHRoZSBvbmVzIGltcGxlbWVudGluZyBwcm92aXNpb25hbCBzdXBwb3J0IGZvciBDTFVF IGludGVyd29ya2luZyBpZiB0aGV5IGtub3cgc29tZXdoYXQgd2hhdCB0byBkZXNpZ24gZm9yLgoK U2lnbmFsaW5nIENMVUUgU0RQClJvYiBIYW5zZW4KUm9iOiBDTFVFIGFuZCBTRFAgY2hhbm5lbHMg YXJlIGRlZmluZWQgdG8gYmUgaW5kZXBlbmRlbnQgYW5kIHRoZSBmYXIgZW5kIG11c3Qgb25seSBh Y3Qgb24gdGhlIGludGVyc2VjdGlvbiBvZiBjaGFubmVsIGluZm9ybWF0aW9uLgpDaGFybGVzOiBZ b3VyIHByb3Bvc2FsIHNldHMgdGhlIG1heGltdW1zIGluIHRoZSBTRFAgYW5kIENMVUU7IGlmIHRo YXQgaXMga25vd24gaXQgaXMgZWFzaWVyIHRvIGJlIGNvbWZvcnRhYmxlIHdpdGggdGhpcy4KUm9i OiBTRFAgc2V0cyB0aGUgZW52ZWxvcGUKQ2hyaXN0ZXI6IEl0IGNyZWF0ZXMgcHJvYmxlbXMgaWYg YSBtaWRkbGVib3ggY2hhbmdlcyBTRFAgaW4gYSB3YXkgdGhhdCBtYWtlcyBTRFAgbm90IGJlIGFs aWduZWQgd2l0aCBDTFVFClJvYjogWWVzLCB5b3UgY2FuIGNyZWF0ZSBzdWItb3B0aW1hbCBwZXJm b3JtYW5jZS4KUm9iZXJ0IFM6IFlvdSBjb3VsZCBnZXQgYSB1c2VmdWwgZGlzY3Vzc2lvbiBpZiB5 b3UgY29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgdGhlIFNEUCBkb2VzIG5vdCBhcnJpdmUgYXQgYWxs LgpSb2I6IE1lZGlhIG5lZ290aWF0aW9uIGluIFNEUApDaHJpc3RlcjogSW4gZmlyc3QgU0RQLCBm b3IgbGVnYWN5IGludGVyb3BlcmFiaWxpdHksIHNvbWUgcGFydHMgb2YgU0RQIGFyZSBzdGlsbCBp bnRlcmVzdGluZyBhbmQgY2FuIGJlIGluY2x1ZGVkIHRoZXJlIHdoZW4geW91IHN0aWxsIG5vdCBr bm93IGlmIHJlbW90ZSBpcyBDTFVFIG9yIG5vdC4KUm9iOiBBZ3JlZS4KPzogyldlIGhhdmUgYW4g b2ZmZXIvYW5zd2VyIGFuZCB3aGF0IHlvdSdyZSBvZmZlcmluZyBtYXkgYmUgcmVzdHJpY3RlZCBi eSB0aGUgYW5zd2VyCk1hcnk6IEFyZSB3ZSBPSyB3aXRoIHRoaXM/CkpvbmF0aGFuOiBPSyB0byBl eHBsb3JlLgpNYXJ5OiBUaGlzIGhhcyBkZXBlbmRlbmNpZXMgdG8gb3RoZXIgdXBjb21pbmcgZ3Jv dXAgbWVldGluZ3MsIGxpa2UgTU1VU0lDIGFuZCBSVENXRUIsIHdoaWNoIGNhbiBiZSB0YWtlbiBp bnRvIGFjY291bnQgYXQgb3VyIG5leHQgQ0xVRSBzbG90IG9uIFRodXJzZGF5Cgo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUm9iIEhh bnNlbidzIE5vdGVzIGZvciBNb25kYXkgTWFyY2ggMTF0aAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09CgoKUmV2aWV3IG9mIHRoZSBtYWluIGRvY3VtZW50cw0KIC0gcmVx dWlyZW1lbnRzIGRvY3VtZW50IGhhcyBiZWVuIHVwZGF0ZWQgdG8ga2VlcCBpdCBhbGl2ZQ0KIC0g dXNlIGNhc2UgZG9jdW1lbnQgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBrZWVwIGFsaXZlIChSb25p KQ0KIC0gSUFOQSBzZWN1cml0eSBkZXRhaWxzIG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gbWFqb3Ig ZG9jdW1lbnRzDQogLSBmcmFtZXdvcmsgZG9jdW1lbnQgaGFzIGJlZW4gcmV2aXNlZA0KIC0gcnRw LW1hcHBpbmcNCg0KDQpNYXJrIER1Y2t3b3J0aCBnYXZlIGEgcHJlc2VudGF0aW9uIG9uIHRoZSBm cmFtZXdvcmsgZG9jdW1lbnQNCg0KVGhlIGRvY3VtZW50IGhhcyBiZWVuIHJlY2VudGx5IHJldmlz ZWQuIEEgYmFzaWMgY2FsbCBmbG93IHNlcXVlbmNlIGRpYWdyYW0gd2FzIGFkZGVkLCBjb25zdW1l ciBjYXBhYmlsaXR5IG1lc3NhZ2UgaGFzIGJlZW4gcmVtb3ZlZCwgc2ltdWx0YW5lb3VzIHNldHMg aGF2ZSBiZWVuIG1hZGUgb3B0aW9uYWwsIG1hbnkgcmV2aXNpb25zIHdlcmUgbWFkZS4gVGhlcmUg aXMgYSBjb250aW51aW5nIHByb3Bvc2FsIHRoYXQgc29tZSBvZiB0aGUgZGV0YWlscyB3aWxsIGJl IG1vdmVkIHRvIGFub3RoZXIgZG9jdW1lbnQuDQoNClRoZXJlIHdhcyBhIHJlc3RhdGVtZW50IG9m IHRoZSBmYWN0IHRoYXQgQ0xVRSB3aWxsIG5vdCBkbyBhbnl0aGluZyBvbiB0aGUgbWVkaWEgcGxh bmUgdGhhdCBpcyBjb250cmFyeSB0byBTRFAgTy9BLCBhbmQgTWFyayBwcm9wb3NlZCB0aGF0IHRo aXMgaXMgbWFkZSBleHBsaWNpdCBpbiB0aGUgZnJhbWV3b3JrLg0KDQpUaGVyZSB3YXMgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRoZSBmcmFtZXdvcmsgc2hvdWxkIGF0dGVtcHQgdG8gDQoNClRo ZXJlIGhhcyBiZWVuIGNvbnNpZGVyYWJsZSBkaXNjdXNzaW9uIG9mIHNpbXVsdGFuZW91cyBzZXRz IG9uIHRoZSBtYWlsaW5nIGxpc3QuIFdoaWxlIGluaXRpYWxseSB0aGUgU1RTcyB3ZXJlIGRlc2ln bmVkIHRvIGV4cHJlc3MgcGh5c2ljYWwgY29uc3RyYWludHMgdGhlcmUgYXJlIG90aGVyIHVzZSBj YXNlcyB3aGVyZSB0aGV5IHdpbGwgYmUgdXNlZnVsLCBmb3IgdGhhdCBUaGUgcHJvcG9zYWwgd2Fz IHRvIGFsbG93IGV4cHJlc3NpbmcgdGhlc2Ugc2V0cyBpbiB0ZXJtcyBvZiBjYXB0dXJlIHNjZW5l cywgY2FwdHVyZSBzY2VuZSBlbnRyaWVzIGFuZCBtZWRpYSBjYXB0dXJlcy4gSXQgaXMgdG8gYmUg a2VwdCBhcyBhIHNpbXBsZSBsaXN0IG9mIGVudHJpZXMuIHJhdGhlciB0aGFuIGluY2x1ZGluZyBs b2dpY2FsIG9wdGVyYXRvcnMuIFRoZXJlIHdhcyBkZWJhdGUgYWJvdXQgdGhlIHZhbHVlIG9mIGFs bG93aW5nIGNhcHR1cmUgc2NlbmVzIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBTVFMsIGFzIGl0IGlz IGxvZ2ljYWxseSB0aGUgc2FtZSBhcyB3cml0aW5nIHRoZSBpbmRpdmlkdWFsIGNhcHR1cmVzLiBJ biB0aGUgZW5kIHRoZXJlIHdhcyBubyBhY3R1YWwgb2JqZWN0aW9uIHRvIHRoZSBpbmNsdXNpb24g b2YgY2FwdHVyZSBzY2VuZSBzIGluIHRoZSBTVFMsIHRob3VnaCB0aGVyZSB3YXMgYSBxdWVzdGlv biB0byBpdHMgdXNlZnVsbmVzcy4gTWFyayBwcm9wb3NlZCB0aGF0IHRoZSBkb2N1bWVudCBhdXRo b3JzIHB1dCB0b2dldGhlciBzb21lIHRleHQgZm9yIGV2ZXJ5b25lIHRvIHJldmlldy4NCg0KVGhl cmUgaGFzIGFsc28gYmVlbiBkaXNjdXNzaW9uIG9mIHdoZXRoZXIgY2FwdHVyZSBzY2VuZSBlbnRp cmVzIGFuZCBTVFNzIGluY2x1ZGUgbWVkaWEgb2YgbXVsdGlwbGUgdHlwZXM7IGF0IHByZXNlbnQg b25seSBvbmUgdHlwZSBpcyBwZXJtaXR0ZWQuIFBhdWwgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZWNv bWVzIG1vcmUgcHJvYmxlbWF0aWMgd2l0aCBzd2l0Y2hpbmcgd2hlbiB0aGVyZSBpcyBhIHNlbGVj dGlvbiBvZiBhIHBhcnRpYWwgc2NlbmUuIFRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gdGhhdCB0aGlz IHdhc24ndCBwYXJ0aWN1bGFybHkgdmFsaWQsIGFuZCB3ZSBoYXZlIG5vIHVzZSBjYXNlcyBmb3Ig cGFydGlhbCBzZWxlY3Rpb24gb2YgY2FwdHVyZSBzY2VuZXMuIFBhdWwncyBzcGVjaWZpYyBjb25j ZXJuIHdpdGggY2FwdHVyZSBzY2VuZSBlbnRpcmVzIHdhcyB0aGF0IGluY2x1ZGluZyBtdWx0aXBs ZSBtZWRpYSB0eXBlcyBjb3VsZCBsZWFkIHRvIGFuIE0qTiBzZXQgb2YgZW50cmllcy4gVGhlIHNw ZWNpZmljIHF1ZXN0aW9uIGlzIHdoZXRoZXIgYWxsIGNvbWJpbmF0aW9ucyBvZiBhdWRpbyBjYXB0 dXJlIHNjZW5lIGVudHJpZXMgYW5kIHZpZGVvIGNhcHR1cmUgc2NlbmUgZW50cmllcyBhcmUgdmFs aWQgLSBpZiBzbyB0aGVyZSBpcyBubyBuZWVkIHRvIGNvbWJpbmUgdGhlIHR3by4gTWFyayBzYWlk IHRoYXQgdGhpcyBhc3N1bXB0aW9uIGlzIGN1cnJlbnRseSBpbXBsaWNpdCBpbiB0aGUgZnJhbWV3 b3JrLiBSb25pIGFuZCBDaHJpc3RlciBmZWx0IGV2ZW4gaWYgYWxsIGNvbWJpbmF0aW9ucyB3ZXJl IHZhbGlkIHRoZXJlIG1heSBiZSAqcHJlZmVycmVkKiBjb21iaW5hdGlvbnMgb2YgYXVkaW8gYW5k IHZpZGVvLCB0aG91Z2ggc29sdmluZyB0aGlzIHByb2JsZW0gbWF5IG5vdCBpbnZvbHZlIHRoZSBD U0VzLiBDaHJpc3RlciB2b2x1bnRlZXJlZCB0byBsb29rIHRocm91Z2ggdGhlIHVzZSBjYXNlcyBh bmQgc2VlIGlmIHRoZXJlIHdhcyBhIG5lZWQgdG8gbGluayBkaWZmZXJlbnQgbWVkaWEgdHlwZXMu IE5vIG9uZSBjb3VsZCB0aGluayBvZiBhIHJlYXNvbiB0byBoYXZlIG11bHRpcGxlIG1lZGlhIHR5 cGVzIGluIGFuIFNUUy4NCg0KQSBjYXB0dXJlIHNjZW5lIGNhbiBpbmNsdWRlIGNhcHR1cmVzIHdp dGggZGlmZmVyZW50IHBsYW5lcyBvZiBpbnRlcmVzdCwgYnV0IHRoZSBjYXB0dXJlIHNjZW5lIG9u bHkgaGFzIGEgc2luZ2xlIGFyZWEgb2Ygc2NlbmUgYW5kIGhlbmNlIGNhbiBvbmx5IGV4cHJlc3Mg YSBzaW5nbGUgcGxhbmUuIFRoZXJlIHdhcyBhIHByb3Bvc2FsIHRoYXQgdGhpcyBiZSBtYWRlIGEg dm9sdW1lLiBUaGVyZSB3YXMgc29tZSBkZWJhdGUgYWJvdXQgd2hhdCB0aGUgcG9pbnQgb2Ygd2hh dCB0aGUgY2FwdHVyZSBzY2VuZSBhcmVhL3ZvbHVtZSBldmVuIHdhcy4gTWFyayBtZW50aW9uZWQg dGhhdCBhcmVhIG9mIHNjZW5lIHdhcyBub3QgaW4gdGhlIG9yaWdpbmFsIGZyYW1ld29yaywgc28g aXQgbXVzdCBoYXZlIGJlZW4gc3BlY2lmaWNhbGx5IGFkZGVkIGZvciBhIHJlYXNvbi4gU3RlcGhh biBzdWdnZXN0ZWQgd2UgY2hlY2sgYmFjayBhbmQgc2VlIGlmIHdlIGNhbiBmaW5kIHdoeSBpdCB3 YXMgb3JpZ2luYWxseSBpbmNsdWRlZC4NCg0KQ3VycmVudGx5IHN3aXRjaGluZyBwb2xpY2llcyBh cmUgZGVmaW5lZCBvbiB0aGUgY2FwdHVyZSBzY2VuZSBlbnRyeSAtIE1hcmsgcHJvcG9zZWQgaXQg YmUgb24gdGhlIGNhcHR1cmUgc2NlbmUgaXRzZWxmLiBKb25hdGhvbiBwcm92aWRlZCBzb21lIHJl YXNvbnMgd2h5IGl0IG5lZWRzIHRvIHN0YXkgb24gdGhlIENTRS4NCg0KZHJhZnQtZ3JvdmVzLWNs dWUtY2FwdHVyZS1hdHRyLTAxJ3MgcHJvcG9zZWQgY2hhbmdlcyB0byB0aGUgZnJhbWV3b3JrL2Rh dGEgbW9kZWwgaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGFuZCB0aGUgY29uY2VwdHMg YXJlIGdlbmVyYWxseSBhcHByb3ZlZCwgdGhvdWdoIHRoZXJlIHdpbGwgbmVlZCB0byBiZSBzcGVj aWZpYyB0ZXh0IGFuZCBzb21lIGRpc2N1c3Npb24gb2Ygd2hldGhlciB0aGV5IHNob3VsZCBiZSBp biB0aGUgZnJhbWV3b3JrIG9yIGRhdGEgbW9kZWwuZ2VuZXJhbGx5IGFwcHJvdmVkIG9mLg0KDQpU aGVyZSBpcyBhIHByb3Bvc2FsIHRoYXQgdGhlIGZyYW1ld29yayBtb3ZlcyBzb21lIGRldGFpbCB0 byB0aGUgZGF0YSBtb2RlbCwgYnV0IHRoZXJlIGlzIGRlYmF0ZSBhYm91dCB3aGVyZSB0aGUgbGlu ZSBzaG91bGQgYmUgZHJhd24uIEdlbmVyYWwgZmVlbGluZyBpcyB0aGF0IHRoZSBzcGVjaWZpYyBz eW50YXggc2hvdWxkIG5vdCBiZSBpbiB0aGUgZnJhbWV3b3JrLCBidXQgaXMgc2hvdWxkIGV4cGxh aW4gY29uY2VwdHMuIFN0ZXBoYW4gZmVsdCB0aGF0IGlmIHRoZSBkb2N1bWVudCBpbmNsdWRlcyBY TUwgdGhlbiBpdCBhbHNvIG5lZWRzIHRvIGluY2x1ZGUgdGhlIHNjaGVtYSBzbyB0aGF0IHRoZSBY TUwgY2FuIGJlIHVuZGVyc3Rvb2QgYW5kIHRoZW4gd2UgYXJlIGJhY2sgdG8gdGhlIHNhbWUgcHJv YmxlbS4NCg0KRmluYWxseSwgTWFyayBzdWdnZXN0ZWQgdGhhdCBtYW55IG9mIHRoZSBleGlzdGlu ZyBleGFtcGxlcyBhcmUgb3V0ZGF0ZWQgYW5kIGNvdWxkIGRvIHdpdGggYmVpbmcgdXBkYXRlZCBm b3Igb3RoZXIgY2hhbmdlcyBhbmQgY29uc2lzdGVuY3kgd2l0aCB0aGUgZGF0YSBtb2RlbCB0ZXJt aW5vbG9neS4gV2UgY291bGQgYWxzbyB1c2UgbmV3IGV4YW1wbGVzLg0KDQoNClNpbW9uIGdhdmUg YSBwcmVzZW50YXRpb24gb24gdGhlIGRhdGEgbW9kZWwgc2NoZW1hDQoNClRoZXJlIGlzIGFuIHVu b2ZmaWNpYWwgdmVyc2lvbiAtMDMgdmVyc2lvbiB0aGF0IFNpbW9uIHdpbGwgdXBsb2FkIGJ5IHRo ZSBlbmQgb2YgdGhlIGRheSBub3cgdGhhdCB0aGUgdG9vbHMgaXMgb3BlbiBhZ2Fpbi4NCg0KVGhl cmUgaXMgYSA8bGFuZz4gYXR0cmlidXRlIGJhc2VkIG9uIHRoZSBncm92ZXMgZHJhZnQgYWRkZWQg dG8gdGhlIG1vZGVsIGFzIGl0IGhhZCBzdXBwb3J0IG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNClRo ZXJlIHdhcyBhbHNvIGEgc3VnZ2VzdGlvbiB0byBhZGQgYSA8cHJpb3JpdHk+IGF0dHJpYnV0ZSB0 byBjYXB0dXJlcy4gVGhlcmUgd2FzIGRlYmF0ZSBhYm91dCB0aGUgc2NvcGUgb2YgdGhlIHByaW9y aXR5LCBhbmQgd2hldGhlciBjYXB0dXJlIHNjZW5lcyBzaG91bGQgaGF2ZSBhIHByaW9yaXR5LiBH ZW5lcmFsIGZlZWxpbmcgd2FzIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBwcmlvcml0aWVzIHNob3Vs ZCBiZSBhZHZlcnRpc21lbnQtd2lkZSwgaW4gd2hpY2ggY2FzZSBoYXZlIHRoZSBjYXB0dXJlIHNj ZW5lIGlzIGxlc3Mgdml0YWwuIFRoZSBpbmZvcm1hdGlvbiB3aWxsIGFsc28gbmVlZCB0byBiZSBp biB0aGUgZnJhbWV3b3JrLg0KDQpTcGVwaGFuIHdhbnRlZCBhIGNsYXJpZmljYXRpb24gb2YgdGhl IGRhdGEtbW9kZWwvZnJhbWV3b3JrIHNwbGl0LiBNYXJ5IHN0YXRlZCB0aGF0IHRoaXMgaGFkIGJl ZW4gcHJldmlvdXNseSBkaXNjdXNzZWQgYW5kIHRoYXQgdGhlIGRhdGEgbW9kZWwgaW5jbHVkZWQg YW4gaW5zdGFuY2UgZGVmaW5pdGlvbiBvZiB0aGUgQ0xVRSBpbmZvcm1hdGlvbiwgbm90IGp1c3Qg dGhlIHN5bnRheC4NCg0KQW5vdGhlciBwcm9wb3NlZCBlbGVtZW50IHdhcyA8cmVsYXRlZFRvPiwg YWxsb3dpbmcgY2FwdHVyZXMgdG8gYmUgbGlua2VkIHRvZ2V0aGVyLiBUaGlzIGlzIGludGVuZGVk IHRvIGxpbmssIGZvciBpbnN0YW5jZSwgYW4gaXRhbGlhbiBhdWRpbyBjYXB0dXJlIHRvIHRoZSBl bmdsaXNoIGVxdWl2YWxlbnQuIFRoZXJlIHdhcyBhZ3JlZW1lbnQgdGhhdCB0aGlzIG5lZWRlZCBh IHRpZ2h0ZXIgZGVmaW5pdGlvbiB0byBzYXkgd2hhdCAncmVsYXRlZCcgYWN0dWFsbHkgbWVhbnMu IFRoZXJlIHdhcyBhbHNvIGFncmVlbWVudCB0aGF0IHRoaXMgc2hvdWxkIGJlIHVzYWJsZSBiZXR3 ZWVuIG1lZGlhIHR5cGVzLg0KDQpBbm90aGVyIHByb3Bvc2FsIHdhcyA8ZHluYW1pYz4sIGluZGlj YXRlcyB0aGF0IGEgcGFydGljdWxhciBzdGF0aWMgY2FwdHVyZSBkZXZpY2UgbWF5IG1vdmUgZHVy aW5nIHRoZSBjb3Vyc2Ugb2YgdGhlIGNhbGwuIEEgZGViYXRlIHdhcyByYWlzZWQgYWJvdXQgaG93 IHRoaXMgaW50ZXJhY3RlZCB3aXRoIHNwYWNpYWwgaW5mb3JtYXRpb24sIGFuZCBnZW5lcmFsIGZl ZWxpbmcgd2FzIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0byBrZWVwIGl0IGdlbmVyYWwgYW5kIG5v dCB0cnkgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgZ2V0dGluZyB0aGUgZXhhY3QgY29vcmRpbmF0 ZXMgb2YgYSBtb3ZpbmcgY2FtZXJhIGF0IGV2ZXJ5IHBvaW50IChlZywgaWYgPGR5YW5taWM+IGlz IHRydWUgdGhlbiB0aGUgc3BhdGlhbCBpbmZvcm1hdGlvbiBzaG91bGQgZWl0aGVyIGJlIG5vdCBp bmNsdWRlZCwgb3IgYXNzdW1lZCB0byBiZSBpbmFjY3VyYXRlKS4NCg0KQW5vdGhlciBwcm9wb3Nh bCB3YXMgdG8gcHJvdmlkZSBvcHRpb25hbCBodW1hbi1yZWFkYWJsZSB0ZXh0dWFsIGluZm9ybWF0 aW9uIHdpdGggPGRlc2NyaXB0aW9uPi4NCg0KQW5vdGhlciBwcm9wb3NhbCB3YXMgdGhlIDxlbWJl ZGRlZFRleHQ+IGxhbmcgYXR0cmlidXRlIHRvIHRlbGwgdGhlbSB0aGVyZSB3YXMgZW1iZWRkZWQg dGV4dCBpbiB0aGUgdmlkZW8gb2YgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlLg0KDQpTaW11bHRhbmVv dXMgc2V0IHdhcyBhbHNvIGJyb3VnaHQgdXAgYWdhaW4gYXMgcGFydCBvZiB0aGUgZGF0YSBtb2Rl bCBkaXNjdXNzaW9uLCB3aXRoIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIGNhcHR1cmUgc2NlbmVz IHNob3VsZCBiZSBpbmNsdWRlZC4gVGhlIHByb3Bvc2FsIGRpZCBub3QgaW5jbHVkZSBjYXB0dXJl cyAob25seSBjYXB0dXJlIHNjZW5lcyBhbmQgY2FwdHVyZSBzY2VuZSBlbnRyaWVzKSAtIGl0IHdh cyBjbGFyaWZpZWQgdGhhdCBjYXB0dXJlcyB3ZXJlIHRoZSBmdW5kYW1lbnRhbCBzZWN0aW9uIGFu ZCBuZWVkZWQgaW5jbHVkaW5nLg0KDQpGaW5hbGx5LCB0aGUgZGF0YSBtb2RlbCBwcm9wb3NlZCBh ZGRpbmcgPGNhcHR1cmVFbmNvZGluZz4sIHRob3VnaCBvYnZpb3VzbHkgdGhlcmUgaXMgdGhlIHF1 ZXN0aW9uIG9mIGhvdyB0aGlzIGlzIHRvIGJlIGRvbmUgaW4gU0RQLg0KDQoNClBhdWwgS3l6aXZh dCBnYXZlIGEgcHJlc2VudGF0aW9uIG9uIGhpcyB0ZW1wbGF0ZSBzaWduYWxsaW5nIGRvY3VtZW50 DQoNClBhdWwgY3JlYXRlZCB0aGUgZG9jdW1lbnQgdG8gZ2V0IGRpc2N1c3Npb24gZ29pbmcsIGFz IHNpZ25hbGxpbmcgaXMgYSBiaWcgdG9waWMgd2l0aCBsb3RzIG9mIGludGVyY29ubmVjdGluZyBz ZWN0aW9ucy4NCg0KQ3VycmVudGx5IHRoZXJlIGhhcyBiZWVuIGxpbWl0ZWQgZGlzY3Vzc2lvbiwg YnV0IGJ5IGJyZWFraW5nIHRoZSBwcm9ibGVtIHVwIGludG8gbWFueSBzZWN0aW9ucyBpdCB3aWxs IGhvcGVmdWxseSBtYWtlIHRoZW0gbW9yZSBhdHRhY2thYmxlLg0KDQpUaGUgaW5pdGlhbCBxdWVz dGlvbiB3YXMgb24gdmVyc2lvbiwgaG93IHRvIGRlYWwgd2l0aCBpdC4gQ2hhcmxlcyByYWlzZWQg QkZDUCBhcyBhbiBleGFtcGxlIG9mIHNvbWV0aGluZyBzaW1pbGFyIHRoYXQgaGFzIHJ1biBpbnRv IGlzc3VlcywgYW5kIHN1Z2dlc3RlZCB0aGF0IHRoZSBTRFAgbmVnb3RpYXRpb24gb2YgdGhlIENM VUUgY2hhbm5lbCB3YXMgYSBnb29kIHNwb3QgdG8gZGVjbGFyZSB2ZXJzaW9ucy4gT3B0aW9ucyBh bmQgZXh0ZW5zaW9ucyBhcmUgYW5vdGhlciBpc3N1ZSAtIGlnbm9yZSB3aGF0IHlvdSBkb24ndCB1 bmRlcnN0YW5kIHZlcnN1cyBleHBsaWNpdCBuZWdvdGlhdGlvbiBvZiBvcHRpb25zLiBOZXh0IHdh cyBkZWZpbmluZyBtZXNzYWdlcyBhcyB0aGUgZGF0YSBtb2RlbCBkb2VzIG5vdCBkZWZpbmUgdGhl IGFjdHVhbCBtZXNzYWdlcywgaG93IHdlIGRlYWwgd2l0aCBlcnJvcnMsIGFuZCBob3cgdGhlIG1l c3NhZ2VzIGFyZSBmaXR0ZWQgaW50byBTQ1RQLg0KDQpBbm90aGVyIGlzc3VlIGlzIEFDSyAtIHRo ZXJlIGFyZSBhbGwgc29ydHMgb2YgcXVlc3Rpb25zIGhlcmUsIHN1Y2ggYXMgd2hldGhlciBhIGNv bmZpZ3VyZSBtZXNzYWdlIGlzIGFuIGltcGxpY2l0IGFjayBvciB0aGVyZSBzaG91bGQgYmUgYW4g ZXhwbGljaXQgYWNrLiBDaGFubmVsIG1hbmFnZW1lbnQgaXMgYW5vdGhlciBzdWNoIGlzc3VlLCB3 aXRoIGhvdyB3ZSBkZWFsIHdpdGggY2hhbm5lbCBlcnJvcnMgYW5kIGhvdyB0aGUgY2hhbm5lbCBp cyBlc3RhYmxpc2hlZC4NCg0KVGhlbiB0aGVyZSBtb3N0IGNvbXBsaWNhdGVkIGFuZCBjb250cm92 ZXJzaWFsIHNlY3Rpb24gYWJvdXQgdGhlIGNvb3JkaW5hdGlvbiBvZiBDTFVFIGFuZCBTRFAgYW5k IGhvdyB0aGUgZGF0YSBpcyBzcGxpdC4gZHJhZnQtaGFuc2VuLWNsdWUtc2RwLWludGVyYWN0aW9u LTAxIGFkZHJlc3NlcyBvbmUgc2VjdGlvbiBvZiB0aGlzIGluIGRldGFpbHMuDQoNClRoZSB1c2Ug Y2FzZXMgaW4gdGhlIGRvYyBhcmUgbm90IGN1cnJlbnRseSBhbGlnbmVkIHdpdGggb3RoZXIgY29u dGVudHMgLSB0aGV5IHdpbGwgbmVlZCB0byBiZSB1cGRhdGVkIGFzIGRlY2lzaW9ucyBhcmUgbWFk ZS4NCg0KTGVnYWN5IGlzc3VlcyBhbmQgQ0xVRSBhbmQgUlRDd2ViIGludGVyYWN0aW9uIHdpbGwg bmVlZCB0byBiZSBkaXNjdXNzZWQsIGJ1dCB0aGVyZSBpcyBjdXJyZW50bHkgbm8gZGV0YWlsIGlu IHRoZSBkcmFmdC4NCg0KUGF1bCBjbGFyaWZpZWQgdGhhdCB0aGUgWE1MIG9mIHRoZSBkcmFmdCB3 YXMgYXZhaWxhYmxlIGFuZCBwZW9wbGUgY291bGQgYWRkIHRleHQgZGlyZWN0bHkgdG8gdGhlIGRy YWZ0IC0gYWx0ZXJuYXRpdmVseSB0aGF0IGhlIHdhcyB3aWxsaW5nIHRvIGFkZCB0ZXh0IGZyb20g dGhlIG1haWxpbmcgbGlzdCB0byB0aGUgZG9jdW1lbnQgaGltc2VsZiBpZiBpdCB3YXMgc21hbGwg YW5kIHdlbGwgZGVmaW5lZC4NCg0KDQpSb2IgSGFuc2VuIGdhdmUgYSBwcmVzZW50YXRpb24gb24g Q0xVRS9TRFAgaW50ZXJhY3Rpb24NCg0KTm8gbm90ZXMgYXJlIGF2YWlsYWJsZSBoZXJlIGFzIHRo ZSBub3RlIHRha2VyIHdhcyBnaXZpbmcgdGhlIHByZXNlbnRhdGlvbi4gUGxlYXNlIHJlZmVyIHRv IHRoZSBhbHRlcm5hdGUgbm90ZXMuDQoNCg0KTWVldGluZyBmaW5pc2hlZCAxMTozMQoKCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KQW5kcmV3IEh1dHRvbidzIE5vdGVz IGZvciBNb25kYXkgTWFyY2ggMTF0aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09CjEuMS4xCUZXOiBSZXdvcmsgJiBwbGFucy8gT3BlbiBJc3N1ZXMg0CBNYXJrIER1Y2t3 b3J0aA1kcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrLTA5DWRyYWZ0LWdyb3Zlcy1jbHVlLWNhcHR1 cmUtYXR0ci0wMQ1odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L3NsaWRlcy9zbGlk ZXMtODYtY2x1ZS0yLnBwdHgNLQlDbHVlIGlzIG5vdCBhZHZvY2F0aW5nIGRvaW5nIGFueXRoaW5n IGNvbnRyYXJ5IHRvIFNEUC4g0CBNYXJ5IGNvbW1lbnRlZCB0aGF0IHRoaXMgZG9lcyBub3QgbmVl ZCB0byBiZSBpbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGJ1dCBjb3VsZCBiZSBpbiB0aGUgc2ln bmFsaW5nIGRyYWZ0Lg0tCVJvbmkg0CBCb3RoZXJlZCBieSB0aGUgc3RhdGVtZW50IG9uIHRoZSBT aW11bHRhbmVvdXMgVHJhbnNtaXNzaW9uIFNldHMgc2xpZGUgcmVnYXJkaW5nINJhbGxvdyBleHBy ZXNzaW5nIFNUUyBpbiB0ZXJtcyBvZiBDYXB0dXJlIFNldHPTLiANbwlTdGVwaGFuIFYsIFBhdWwg SywgYW5kIFJvbiBhbHNvIGNvbW1lbnRlZCBvbiB0aGlzLiANbwlEb27VdCBmdWxseSB1bmRlcnN0 YW5kIGlzc3VlIGJ1dCByZWxhdGVzIHRvIHdoYXQgc2ltdWx0YW5lb3VzIGNhcHR1cmUgc2NlbmVz IGNhbiBiZSB1c2VkLg1vCVJvbmkgc3RhdGVkIGhlIGlzIG9rIHdpdGggdGhpcyBiZWVuIHdyaXR0 ZW4gaW4gdGhlIHNwZWMgYnV0IGl0IGlzIG5vdCBwcmFjdGljYWwuDS0JQWxsIE1lZGlhIFR5cGVz IGluIENTRSBhbmQgU1RTLg1vCUNocmlzdGVyINAgTm8gcmVhc29uIHRvIG5vdCBhbGxvdyBkaWZm ZXJlbnQgbWVkaWEgdHlwZXMgZm9yIGNhcHR1cmUgc2NlbmUgZW50cmllcy4NbwlTdGV2ZSBCb3R6 a28g0CANbwlDaHJpc3RlciDQIE5lZWQgdG8gdGhpbmsgbW9yZSBhYm91dCB0aGlzICoqKioqDW8J UGF1bCBLINAgTmVlZCBtb3JlIGNsYXJpZmljYXRpb24gaW4gdGhlIGZyYW1ld29yayBhYm91dCBz d2l0Y2hpbmcuICBQcm9ibGVtIHdpdGggcmVnYXJkIHRvIHdoYXQgYXVkaW8gJiB2aWRlbyBjYXB0 dXJlcyB0byBzZWxlY3QuDW8JSi5MZW5ub3gg0CBJZiB5b3UgZG9u1XQgdGFrZSB0aGUgd2hvbGUg Y2FwdHVyZSBzY2VuZSB0aGVuIGl0IGlzIG5vdCBzcGVjaWZpZWQgd2hhdCB5b3UgZ2V0Pz8/INAg RGlkIEkgZ2V0IHRoaXMgcmlnaHQuDW8JLS0tLS0tDW8JTWFyeSBhc2tlZCBpZiB3ZSBuZWVkIG1v cmUgaW5mb3JtYXRpb24gaW4gdGhlIGZyYW1ld29yayDQIA1vCUNocmlzdGVyINAgRG8gd2UgbmVl ZCBtb3JlIGNhcGFiaWxpdGllcyB0byBpbmRpY2F0ZSB3aGF0IGlzIHByZWZlcnJlZCBpbiB0ZXJt cyBvZiB3aGF0IGF1ZGlvIGdvZXMgd2l0aCB3aGF0IHZpZGVvLiDQIFNlZW1zIGhlIHRoaW5rcyB3 ZSBkby4NbwlTLkJvdHprbyDQIFRoZXJlIGFyZSBwb3NzaWJpbGl0aWVzIGFyb3VuZCB0aGlzLg1v CUFDVElPTiDQIE5lZWQgdG8gcmV2aXNpdCB0aGUgdXNlIGNhc2VzIHRvIHVuZGVyc3RhbmQgd2hh dCBpcyBuZWVkZWQgd2l0aCByZWdhcmRpbmcgdG8gZXhwcmVzc2luZyBwcmVmZXJlbmNlcy4NLQlB dHRyaWJ1dGUgSXNzdWVzLg1vCUFyZWEgb2YgU2NlbmUgUHJvcG9zYWwuDaUJQ2hyaXN0ZXIg0CBJ ZiBhIENTRSBpcyBhZHZlcnRpc2VkIHlvdSBuZWVkIHRvIGJlIGFibGUgdG8gcHJvdmlkZSBldmVy eXRoaW5nIHdpdGhpbiBpdC4gSWYgYWRkaXRpb25hbCB0aGluZ3MgYXJlIGFkZGVkIChuZXcgY2Ft ZXJhKSB0aGVuIGEgbmV3IENTRSBuZWVkcyB0byBiZSBwcm92aWRlZC4gIERvZXMgbm90IHRoaW5r IHdlIG5lZWQgdGhpcyBidXQgbmVlZCBpbnB1dCBmcm9tIG90aGVycyB3aG8gaGF2ZSB1c2UgY2Fz ZXMuDaUJU3RlcGhhbi5WINAgQmVmb3JlIHdlIHRocm93IHRoaXMgb3V0IHdlIG5lZWQgdG8gcmV2 aWV3IHdoeSBpcyB3YXMgYWRkZWQuDaUJQUNUSU9OINAgTmVlZCB0byByZXZpZXcgd2h5IHRoaXMg d2FzIGFkZGVkIGFuZCB3aGV0aGVyIGl0IGlzIHN0aWxsIHJlbGV2YW50Lg1vCVNjZW5lIHN3aXRj aCBQb2xpY3kuDaUJLS0NbwlEcmFmdC1ncm92ZXMtY2x1ZS1jYXB0dXJlLWF0dHINpQktDS0JUmVm YWN0b3Jpbmcg0CB3aGVyZSB0byBkcmF3IHRoZSBsaW5lDW8J0CBObyBtYWpvciBpc3N1ZXMgcmFp c2VkLg0tCQ0NMS4xLjIJRGF0YSBNb2RlbC4gU2ltb24gUGlldHJvIFJvbWFubw1kcmFmdC1wcmVz dGEtY2x1ZS1kYXRhLW1vZGVsLXNjaGVtYS0wMiANaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy84Ni9zbGlkZXMvc2xpZGVzLTg2LWNsdWUtMC5wZGYNLQlOZXcgTWVkaWEgQ2FwdHVyZSBh dHRyaWJ1dGU6IFByaW9yaXR5LgkNbwlSb2IgSGFuc2VuIC0gUHJpb3JpdHkgd291bGQgYmUgdXNl ZnVsIHRvIGhhdmUgYXMgYW4gb3B0aW9uYWwgcGFyYW1ldGVyIGluIGNhcHR1cmUgc2NlbmUuDW8J Q2hyaXN0ZXIg0CBRdWVzdGlvbiB3aGV0aGVyIHRoaXMgbmVlZHMgdG8gYmUgaW4gdGhlIGRhdGEg bW9kZWwgb3Igd2hldGhlciBpdCBzaG91bGQgYmUgaW4gU0RQIG5lZWRzIHRvIGJlIGRpc2N1c3Nl ZC4NbwlTdGVwaGFuIFYuINAgVGhpcyBzaG91bGQgYmUgaW4gdGhlIGZyYW1ld29yay4NbwlTdGVw aGFuIFYgIC0gSW4gY2x1ZSBhcmUgd2UgZGVmaW5pbmcgbmV3IFNEUCBhdHRyaWJ1dGVzLg2lCU1h cnkg0CBOb3QgZGVjaWRlZCB5ZXQuDW8JUm9uaSDQIE5lZWQgdG8gbG9vayBhdCB3aGV0aGVyIHRo ZSBhdHRyaWJ1dGUgaXMgcGVyIG1lZGlhIGNhcHR1cmUgb3Igc29tZXRoaW5nIGVsc2UuDS0JTmV3 IE1lZGlhIENhcHR1cmUgYXR0cmlidXRlINAgRHluYW1pYy4NbwlDaHJpc3RlciDQIEV2ZW4gd2l0 aCB0aGlzIHN0aWxsIG5lZWQgdG8gdXBkYXRlIHRoZSBvZmZlciB3aGVuIHNvbWV0aGluZyBjaGFu Z2VzLg1vCU1hcmsgRC4g0CBNb3JlIHNlbnNlIGZvciB0aGlzIHRvIGJlIGluY29ycG9yYXRlZCBp biB0byB0aGUgc3BlY2lhbCBpbmZvcm1hdGlvbiBlbGVtZW50Lg1vCVJvbmkg0CBUaGUgcG9pbnQg b2YgY2FwdHVyZSBpcyBtb3ZpbmcgYWxsIHRoZSB0aW1lIHdoaWNoIGlzIHRoZSBwcm9ibGVtLg1v CVJvYmVydCBTINAgVGhpcyBpcyB3YW5kZXJpbmcgaW4gdG8gYSB2ZXJ5IGNvbXBsaWNhdGVkIHBy b2JsZW0g0CByZWFkIGdlb3ByaXYgaW5mb3JtYXRpb24uDS0JU2ltdWx0YW5lb3VzIFNldHMNDTEu MS4zCUNsdWUgJiBTRFAgU2lnbmFsbGluZy4g0CBQYXVsIEt5eml2YXQgYW5kIFJvbiBIYW5zZW4N ZHJhZnQta3l6aXZhdC1jbHVlLXNpZ25hbGluZy0wMg1kcmFmdC1oYW5zZW4tY2x1ZS1zZHAtaW50 ZXJhY3Rpb24tMDENLQlodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L3NsaWRlcy9z bGlkZXMtODYtY2x1ZS0xLnBwdHggLSBQYXVsDW8JT3BlbiBJc3N1ZXMg0CBBIHdob2xlIGxvdCBv ZiBzdHVmZiBzdGlsbCBhIGxvdCBvZiB3b3JrIHRvIGRvLg1vCVZlcnNpb25pbmcuDaUJQ2hhcmxl cyDQIEFncmVlIG5lZWQgdG8gZG8gc29tZXRoaW5nIGFuZCBwb3NzaWJseSBmb2xsb3cgc2FtZSB0 cmFjayBhcyBCRkNQQmlzLg1vCVRoZXJlIGhhcyBub3QgYmVlbiBhIGxvdCBvZiByZXZpZXcgb2Yg dGhpcyBzbyBmYXIgYW5kIFBhdWwgaXMgbG9va2luZyBmb3Igb3RoZXIgcGVvcGxlIHRvIHByb3Bv c2UgdGhpbmdzIGFuZCBmb3Igdm9sdW50ZWVycyB0byB3b3JrIG9uIGRyYWZ0cy4NbwlDaHJpc3Rl ciDQIEluIHdoYXQgb3JkZXIgc2hvdWxkIHdlIGRvIHRoaW5ncyDQIENMVUUgb3IgU0RQIGZpcnN0 LCB0aGlzIG5lZWRzIHRvIGJlIGNsYXJpZmllZC4NLQkNLQlodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzg2L3NsaWRlcy9zbGlkZXMtODYtY2x1ZS0zLnBkZiAtIFJvYg1vCVN1Z2dlc3Rp b246IENoYW5uZWxzIEluZGVwZW5kZW50Lg2lCU1JU1NFRCBTT01FIFNUVUZGIChDb21tZW50IGZy b20gQ2hyaXN0ZXIpLg2lCVJvYmVydCBTcGFya3Mg0CBBIGxvdCBvZiBwZW9wbGUgc2VlbSB3b3Jy aWVkIGFib3V0IHdoYXQgbWlnaHQgYmUgaGFwcGVuaW5nIGhlcmUgZG8gd2UgaGF2ZSBtb3JlIGNv bmNyZXRlIGV4YW1wbGVzPw2lCVJvYiDQIE9rIEkgd2lsbCBhZGQgc29tZSBleGFtcGxlcyBpbiB0 aGUgZHJhZnQuDW8JTWVkaWEgTmVnb3RpYXRpb24gaW4gU0RQLg2lCU1hcnkgYXNrcyBpZiBwZW9w bGUgYXJlIGhhcHB5IHRvIGdvIGFoZWFkIGFuZCBleHBsb3JlIHRoaXMgcG9zc2liaWxpdHkuDaUJ QnJpYW4gUm9zZW4g0CBUaGlzIGRvZXMgbm90IHRvIHdvcmsgd2l0aGluIHRoZSBjb25zdHJhaW50 cyBvZiBvZmZlci9hbnN3ZXIuDaUJQ2hyaXN0ZXIg0CBOZWVkIHRvIG1hcCBjYXB0dXJlcyB0byBT RFAuDS0JDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpNYWdudXMgV2VzdGVybHVuZCdzIE5vdGVzIGZvciBUaHVyc2RheSBNYXJjaCAxNHRoCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpSZXF1aXJlbWVu dHMgQWdlbmRhIEl0ZW0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NUm9iIEhhbnNlbjogU3Vt bWFyeSBTbGlkZTogSXRlbXMgYXJlIHRoaW5ncyB3ZSBjYXJlIG9mLiBCdXQgb3JkZXJpbmcgbWF5 IGJlIHdyb25nLiANDVJvbmkgZXZlbjogRG9u1XQgY2FyZSBzbyBtdWNoIGFib3V0IGF1ZGlvIHZp ZGVvIG11bHRpcGxleGluZywgYnV0IHdpdGhpbiBhIG1lZGlhIHR5cGUuIFRoZSBsYXN0IGFyZSBX ZWJSVEMgc3BlY2lmaWMsIGJ1dCBDTFVFIGhhcyBzaW1pbGFyIHRvIGFkZHJlc3MgbWVkaWEgZW5j b2RpbmdzLiANTGVubm94IGFncmVlZCBvbiB0aGUgbmVlZCBmb3IgcmVmZXJlbmNpbmcsIGJ1dCB3 aXRoIGRpZmZlcmVudCBuYW1lcy4gDUxlbm5veDogT24gbXVsdGlwbGUgb2ZmZXJzIGFuZCBhbnN3 ZXJzLCBtYXkgbmVlZCBjb29yZGluYXRpb24gb2YgdGhlIENMVUUgY2hhbm5lbCBhbHNvLiBJbXBv cnRhbnQgdG8gZW5zdXJlIHRoYXQgdGhlIGFkZGl0aW9uYWwgTy9BIGV4Y2hhbmdlIGNhbiBiZSB1 c2VkIGZvciBzZXJ2ZXJhbCBwdXJwb3Nlcy4NUm9uaTogV2Ugd2lsbCBoYXZlIGFkZGl0aW9uYWwg Ty9BLiBTdGFydCB3aXRoIGJhc2ljIGNhc2Ugb25lIEF1ZGlvIGFuZCBWaWRlbyBhbmQgYSBDTFVF IGNoYW5uZWwsIHRoZW4gbW92ZSB0byBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLiBUaGlzIGlzIGlu IFBhdWzVcyBkb2N1bWVudC4NQm90emtvOiBDTFVFIG5lZWRzIHRvIGludGVyb3BlcmF0ZSB3aXRo IGxlZ2FjeSBTSVAsIHRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgZXhpc3QgZm9yIFdlYlJUQy4N IA1EZXNpZ24gVGVhbSBSZWFkb3V0OiBldmFsdWF0aW5nIFByb3Bvc2FscwotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDUNMVUUgLyBTRFAgZGl2aXNpb24NUm9uaTog UGxhbiBaLCBJIGRpZG7VdCBhZ3JlZSBvbiB0aGUgc2Vjb25kIGJ1bGxldCAoU2VwYXJhdGUgbS1s aW5lIHBlciBzZW5kL3JlY2VpdmUgc3RyZWFtKS4gTWF4LVNTUkMgY2FwYWJsZSBvZiBleHByZXNz aW5nIGJvdGggc2VuZC9yZWNlaXZlIGNhcGFiaWxpdGllcy4gUm9iLCB0aGlzIGRvZXNu1XQgd29y ayBpZiB5b3UgaGF2ZSBkaWZmZXJlbnQgc3RyZWFtcyB3aXRoIGRpZmZlcmVudCBzZXRzIG9mIGVu Y29kaW5ncy4gDUNocmlzdGVyLCB0aGlzIHdhcyBkaXNjdXNzZWQgYWZ0ZXIgSSBsZWZ0LiBEb27V dCBsaWtlIGRpZmZlcmVudCBzZW5kIGFuZCByZWNlaXZlIG0tbGluZXMuDUxlbm5veDogUHJvcG9z ZWQgaWYgbW11c2ljIGNyYXNoZXMgYW5kIGJ1cm4gYW5kIHdoYXQgZG9lcyBDTFVFLiANUm9uaTog QSBwbGFuIGZvciBiZWluZyBhYmxlIHRvIHN0YXJ0IHdyaXRpbmcgU0RQIGFuZCBub3QgYmUgZGVw ZW5kbmVudCBvbiBNTVVTSUMgZGlzY3Vzc2lvbi4gIE5vIG11bHRpcGxleGluZywgbm8gYnVuZGxl LiBJZiB3ZSBldmVudHVhbGx5IHdpbGwgYWRkIG11bHRpcGxleGluZywgZXRjLCB0aGVuIHRoaXMg YXBwZWFycyBvay4gDVJvYjogWWVzLCBpdNVzIGEgc3RhcnRpbmcgcGxhY2UsIGJ1dCBhbHNvIGZv ciB0aGUgZGlzYWdncmVnYXRlZCBjYXNlLiANQ2hyaXN0ZXIgSDogKFNsaWRlIGZpc3QgTy9BIGV4 YW1wbGUpIFdoYXQgaXMgaW1wb3J0YW50IHRvIGFsc28gc2hvdyB0aGUgbS1saW5lIGZvciB0aGUg Q0xVRSBjaGFubmVsLiBOb3QgaW5jbHVkZWQsIGZvY3VzZWQgb24gd2hhdCB3ZSBkaWRu1XQgaGF2 ZSBhZ3JlZW1lbnQgb24uIA0gU2xpZGUgKDJuZCBPL0E6IE9mZmVyKQ1DYW7VdCB1c2UgbWF4LWZz LCBtYXgtbWJzIGluIHRoaXMgc2V0dGluZy4gDU1pc3NlZCB0aGluZw1Sb25pOiBUaGlzIHdpbGwg YmUgaW4gdGhlIGNhbGwgZmxvdy4gTWFrZSBjbGVhciBpZiB0aGlzIGlzIGluIHBhcmFsbGVsIHdp dGggdGhlIENMVUUgYWR2ZXJ0aXNlbWVudC4gDUluIGZpcnN0IHlvdSBhcmUgd2lsbGluZyB0byBz ZW5kIG9uZSB2aWRlbyBhbmQgb25lIGF1ZGlvLiBXb3VsZCBiZSBnb29kIGlmIHRoYXQgaW5pdGlh bCBzdHJlYW1zIGJlaW5nIHNlbnQsIHdoYXQgaXMgYWN0dWFsbHkgc2VudCwgc28gdGhhdCB5b3Ug ZG9u1XQgbmVlZCBzd2l0Y2ggdW5uZWNlc3NhcnkuIA1Sb2IsIGRlc2lyYWJsZSBidXQgbm90IHJl cXVpcmVkLiANUXVlc3Rpb24gb2YgaG93IG1hcHBpbmcgd291bGQgYmUgZG9uZS4NQ2hyaXN0ZXI6 IEluIHRoaXMgY2FzZSB5b3UgY2FuIGhhdmUgYm90aCBjYXB0dXJlIHNjZW5lcy4gTm8gZGlyZWN0 IGxpbmsgYmV0d2VlbiBjYXB0dWVyZSBhbmQgYSBsb3Qgb2Ygc2hvcnRoYW5kLiANTGVubm94OiBS ZWNlaXZlciBjb3VsZCBwcm92aWRlIGFsbCBmb3VyIGNhcHR1cmVzLCBhcyBsb25nIGFzIHRoZSBz d2l0Y2hlZCBjYXB0dXJlIGlzIGluZGljYXRlZCB0byB3aGljaCBzdHJlYW0uIERvbtV0IHdvcmsg d2l0aCBwbGFuIFouIFJvYjoNTWFyazogQSBjbHVlIGZyYW1ld29yayBlbmNvZGluZyBpcyByZXBy ZXNlbnRlZCBpbiBhbiBTRFAgbT0gbGluZSwgdGhhdCBzaW5nbGUgZW5jb2RpbmcgY291bGQgYmUg Z3JvdXBlZCB0b2dldGhlciB3aXRoIHRoZSBvdGhlcnMgdG8gY3JlYXRlIG9uZSBlbmNvZGluZyBs aW5lLiBDYW4gb25lIHVzZSBsYWJlbCwgYW5zd2VyIG5vLiANVGhlIHNpbXVsdGFuZW91cyBzZXRz LCBpbmRpY2F0ZXMgdGhhdCBhbGwgY2FuIGJlIHNlbnQgYXQgdGhlIHNhbWUuIFRoZSByZWNlaXZl ciBjYW7VdCBhc3NpZ24gIGFsbCB0aHJlZSB0byBlbmNvZGluZ3MsIGFzIHRoZXJlIGlzIG9ubHkg dGhyZWUuIFRoYXQgaXMgY29ycmVjdC4NUm9uaSwgMm5kIE8vQSBvZmZlciBzbGlkZS4gSWYgb25l IHVzZWQgbWF4LXNzcmMgdGhlbiBhIHNpbmdsZSBtPSBsaW5lIGNvdWxkIHdvcmssIHdpdGggdGhl IGV4Y2VwdGlvbiB0aGF0IG9uZSBjYW7VdCBhc3NpZ25lIGxhYmVsLiBSb2IsIGJ1dCB0aGVuIHRo ZSBhbnN3ZXIgY2Fu1XQgYmUgcHJvdmlkZWQgd2hlbiBkaWZmZXJlbnQgcmVjZWl2ZXIgY29uZmln dXJhdGlvbnMgYXJlIHB1dCBpbnRvIGFuc3dlci4gDVBhdWwgS2l6d2F0OiAgUHV0IG11bHRpcGxl IGxhYmVsIG9uIHRoZSBzYW1lIG09IGxpbmUuICBYOiBJZiBvbmUgdXNlcyBhPXNzcmMgdGhlbiB3 ZSBjb3VsZCBwdXQgaW50byBtdWx0aXBsZSBhPWxhYmVscyBpbiBhIHNpbmdsZSBtPS4gUGF1bDog TGFjayBvZiBhbnN3ZXIgZG9lc27VdCAgbWFrZSBpdCBjbGVhciB0aGUgbGltaXRhdGlvbnMuIFJv YiwgdGhpcyBpcyB3aHkgdGhleSBhcmUgc3BsaXQgaW50byBkaWZmZXJlbnQgbT0gbGluZXMgdG8g YWxsb3cgYW5zd2VyIHRvIG1ha2UgZW5jb2Rpbmcgc3BlY2lmaWMgY2hhbmdlcy4gDVBhdWw6IDNS RCBBbnN3ZXIgaXMgcmVzdWx0IG9mIHRoZSAybmQgYW5zd2VyIGFuZCBwb3NzaWJseSBhIENMVUUg YWR2ZXJ0aXNlbWVudC4gU29tZW9uZSBuZWVkcyB0byBwdXQgaW4gaW5mb3JtYXRpb24gZm9yIHRo ZSBvdGhlciBndXkuIFJvYiwgc2Vjb25kIGd1eSBwdXRzIGluIG9mZmVyLCBmb3Igd2hpY2ggdGhp cyBpcyBhbiBhbnN3ZXIuIA1Sb25pLCBhc2tpbmcgd2hhdCB0aGUgc2NvcGUgb2YgdGhlIGxhYmxl cy4gUm9iLCBhc3N1bWVkIHRoZXkgd2hlcmUgbG9jYWwuIA1Cb3R6a28sIHdoYXQgaXMgdGhlIHZh bHVlIG9mIHRoZSBzZW5kIGxhYmVsIG9uIGEgc2VuZCBvbmx5IHN0cmVhbXMuIFJvYiwgY2FuIG1h a2UgY2xlYXIgd2hhdCBhbiBlbmNvZGVyIGNhbiBwcm9kdWNlLCBmb3IgZXhhbXBsZSBkdWUgdG8g ZW5jb2RlciBzZXBhcmF0aW9uLiANUm9uaTogSWYgb25lIHdhbnRzIHRvIG1vdmUgZnJvbSAzIHN0 cmVhbXMgdG8gb25seSB0aGUgc3dpdGNoZWQuIFRoZW4geW91IG5lZWQgdG8gZG8gYW4gTy9BLiBS b2IsIG5vLCBub3QgbmVjZXNzYXJ5IGlmIHlvdSBhcmUgb2sgd2l0aCBrZWVwaW5nIHRoZSBzdHJl YW1zLiBJZiB5b3Ugd2FudCB0byBsaW1pdCB0aGVtIHRvIGEgc2luZ2xlLCB0aGVuIGRvIGEgTy9B LiBQYXVsLCBubyBsaW1pdHMgb24gd2hhdCB5b3UgcHV0IGluIHRoZSBzdHJlYW1zLiBIb3dldmVy LCBtaWRkbGVib3hlcyBtYXkgbm90IGxpa2UgdG8gc3RvcCBjb250ZW50LiBSb25pLCBpZiB5b3Ug c2VuZCBSVENQIHRoZW4gdGhleSBzaG91bGQga2VlcCB0aGluZ3MgYWxpdmUsIGV2ZW4gaWYgdGhl cmUgaXMgbm8gbWVkaWEuDUVuY29kaW5nIGdyb3VwIGNvbnN0cmFpbnRzLg1Sb2IgcHJlc2VudGlu ZyB0aGUgaXNzdWUgdGhhdCBleGlzdGluZyBwcm9wb3NhbHMgZG9u1XQgY2FuIGV4cHJlc3Mgb3Zl ciBtdWx0aXBsZSBjb2RlY3MuDUNocmlzdGVyIEg6IElzbtV0IHRoYXQgcGFydCBvZiB0aGUgYWR2 ZXJ0aXNlbWVudC4gVGhlIGNvbnN0cmFpbnMgZ2V0IGV4cHJlc3NlZCBieSBpbmRpY2F0aW5nIHdo YXQgeW91IGFyZSBhY3R1YWxseSBjYXBhYmxlIG9mIGRlbGl2ZXJpbmcuIElmIG9uZSBoYXZlIGRp ZmZlcmVudCBjb21iaW5hdGlvbnMgcG9zc2libGUsIG1ha2luZyB0aGVzZSBpbnRvIGRpZmZlcm5l dCBjYXB1dHJlcy4gUm9iOiBJdCBpcyB0aGUgZW5jb2RpbmcgZ3JvdXAgY29uc3RyYWludHMgdGhh dCB2YXJpZXMsIG5vdCBjYXB0dXJlcy4gU2hvdWxkbtV0IGJlIGRpZmZlcm5ldCBjYXB0dXJlcy4g DVg6IEl0IGlzIGltcG9ydGFudCB0byBhbHdheXMgZXhwcmVzcyBtYXhpbXVtLiBUaGVyZSBpcyBk eW5hbWljIGxpbWl0YXRpb25zIHRoZXkgd2lsbCB1c3VhbGx5IG5vdCBiZSBuZWVkaW5nIE8vQSBy ZW5lZy4NTWFyayBEOiBBZ3JlZSBmcm9tIGZyYW1ld29yayBwb2ludCB2aWV3IHRoYXQgdGhlc2Ug YXJlIG9wZW4gcXVlc3Rpb25zLiBNYXRjaGVzIHRoZSB0aGlua2luZyBvZiB3aGF0IGlzIGF2YWls YWJsZSBzbyBmYXIuIFNob3VsZCBsb29rIGF0IHNvbHV0aW9ucyB0aGF0IHdvcmtzIGluIENMVUUs IG1heWJlIG5vdCBhIGdlbmVyYWwgb25lLg1Sb2I6IElmIHdlIGhhdmUgY29kZWMgaW5kZXBlbmRl bnQgY29uc3RyYWludHMgd2UgY291bGQgcHV0IHRoZW0gaW4gZWl0aGVyIGluIFNEUCBvciBDTFVF LiBDdWxsZW4gSmVubmluZ3MgaWYgdGhlc2UgYXJlIHB1dCBpbiBTRFAgdGhlbiBvdGhlciB1c2Vy cyBpbiB0aGUgUkFJIHdpbGwgdXNlIHRoZW0gYWxzby4gDVJvbmk6IE5lZWQgdG8gc3RhcnQgbG9v a2luZyBpZiB0aGVyZSBhcmUgY29uc3RyYWludHMgY3JlYXRlZCBpZiB3ZSBhZGQgbXVsdGlwbGV4 aW5nIGV0Yy4gUm9iLCB5ZXMgd2lsbCBjbGFyaWZ5IHRoaXMgYWRkIGxhZGRlciBkaWFncmFtcyBh bmQgYm90aCBzaWRlIG9mIGV4Y2hhbmdlcyBpbiB0aGUgc2lnbmFsaW5nIGRvY3VtZW50LiAKDVdh eSBGb3J3YXJkICYgV3JhcC11cAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ1Mb29raW5nIGZvciBw ZXJzb24gY29udHJpYnV0aW5nIHNlY3VyaXR5IGFuYWx5c2lzDQoKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpKZWFuIE1haG9uZXkncyBub3RlcyBmb3IgVGh1 cnNkYXkgTWFyY2ggMTR0aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KRGF0ZS9UaW1lIChXRyBzZXNzaW9uIDIpOiBUaHVyc2RheSwgTWFyY2ggMTQsIDEzMDAt MTUwMCAgCkxlbmd0aDogMi4wIGhvdXJzICAKTG9jYXRpb246IENhcmliYmVhbiAyCgpbQ292ZXJl ZCBpbiBwcmV2aW91cyBzZXNzaW9uOiBGcmFtZXdvcmssIGRhdGEgbW9kZWwsIFNEUCBzaWduYWxp bmddCgpOb3RlIHRha2VyczogTWFnbnVzIFdlc3Rlcmx1bmQsIEplYW4gTWFob25leQoKSmFiYmVy IHNjcmliZTogTG9yZW56byBNaW5pZXJvIAoKQ2hhaXJzOiBNYXJ5IEJhcm5lcywgUGF1bCBLeXpp dmF0CgkKQWdlbmRhIEJhc2ggKDUgbWluKQpQcmVzZW50YXRpb246IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODYvc2xpZGVzL3NsaWRlcy04Ni1jbHVlLTgucHB0eApQcmVzZW50ZXI6 IENoYWlycwoKQWdlbmRhIHVwZGF0ZWQgdGhpcyBtb3JuaW5nIAoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClJlcXVpcmVt ZW50czogZHJhZnQtamVubmluZ3MtbW11c2ljLW1lZGlhLXJlcS0wMA0KUHJlc2VudGF0aW9uOiBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L3NsaWRlcy9zbGlkZXMtODYtbW11c2lj LTcucGRmClByZXNlbnRlcjogTWFyeQoKU2xpZGUgMiAtIERlc2lyYWJsZSBQcm9wZXJ0aWVzCgpN YXJ5IC0gVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBvdGhlciBzZXNzaW9uLCBidXQgbm90IGlu IHRoZSBjb250ZXh0IG9mIGNsdWUuIEhpZ2ggcHJpb3JpdHkgcmVxdWlyZW1lbnRzIGFyZSBpbiBy ZWQsIGJ1dCB0aGV5IG1heSBub3QgYmUgaGlnaCBwcmlvcml0eSBmb3IgY2x1ZS4gQW55IGNvbW1l bnRzPwoKUm9iIEhhbnNlbiAtIFdlIGNhcmUgYWJvdXQgdGhpcywgYnV0IHRoZSBvcmRlciBpcyB3 cm9uZywgYW5kIHRoZSBXZWJSVEMgcmVxdWlyZW1lbnQgaXNuJ3QgcmVsZXZhbnQuIAoKTWFyeSAt IERvbid0IGtub3cgdGhhdCBwdXNoaW5nIGFzIG1hbnkgbWVkaWEgZmxvd3MgYXMgcG9zc2libGUg d291bGQgYmUgaGlnaCBwcmlvcml0eS4KClJvbmkgRXZlbiAtIHdlIGRvbid0IGNhcmUgWz9dIFdh bnQgdG8gbXVsdGlwbGV4IGlzIHNpbmdsZSBbP10gY29ubmVjdGlvbi4gV2Ugd2UgaGF2ZSBzaW1p bGFyIHJlcXVpcmVtZW50cy4KCkpvbmF0aGFuIExlbm5veCAtIDZ0aCBidWxsZXQgLSBUaGUgcmVx dWlyZW1lbnQgc2hvdWxkIHNheSAiY2FwdHVyZXMvZW5jb2RpbmdzIiByYXRoZXIgdGhhbiAidHJh Y2tzIiwgZXZlcnl0aGluZyBlbHNlIG9rLiAKCnNsaWRlIDQgLSBOZWdvdGlhdGUgd2l0aCBib3Ro IG5ldyBhbmQgb2xkIGVuZHBvaW50cwoKTGVubm94IC0gTXVsdGlwbGUgTy9BLCB3ZSBuZWVkIHRv IGNvb3JkaW5hdGUgU0RQIGFuZCBjbHVlIGNoYW5uZWwgbWFkZSBuZXcsIG1vcmUgTy9Bcy4gSWYg d2UgbmVlZCBhZGRpdGlvbmFsIE8vQXMsIG1ha2Ugc3VyZSB0aGV5J3JlIGNvbXBhdGlibGUuCgpS b25pIC0gd2Ugd2lsbCBoYXZlIGEgMm5kIE8vQSwgdGhlIGluaXRpYWwgTy9BIGlzIGZvciAxIHZp ZGVvLzEgYXVkaW8sIHRoZSBuZXh0IGlzIGNsdWUgc3VwcG9ydC4gSXQncyBpbiBwYXVsJ3MgZG9j LgoKTWFyeSAtIFdlIGRvbid0IGhhdmUgYWdyZWVtZW50IG9uIHRoZSBjb250ZW50LiAKClN0ZXZl ID8/IEJvdHprbyAtIE91ciBpbml0aWFsIE8vQSBoYXMgdG8gYmUgaGlnaGx5IGludGVyb3BlcmFi bGUgd2l0aCBTSVAgZGVwbG95bWVudHMgLSBXZWJSVEMgZG9lc24ndCBoYXZlIHRoYXQuCgpNYXJ5 IC0gd2UncmUgdHJ5aW5nIHRvIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0gZnVuZGFtZW50YWxseS4g CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KRGVzaWduIFRlYW0gUmVhZG91dDogIEV2YWx1YXRpbmcgUHJvcG9zYWxzDQpQcmVz ZW50YXRpb246IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODYvc2xpZGVzL3NsaWRl cy04Ni1jbHVlLTkucHB0eApQcmVzZW50ZXI6IFJvYiBIYW5zZW4KCnNsaWRlIDMgLSAKCmNoYW5n ZWQgc2luY2UgTW9uZGF5IC0gd2UgZG9uJ3QgbmVlZCB0aGUgY29uc3RyYWludHMgb3IgbmVlZCB0 byBmaW5kIGFub3RoZXIgd2F5IG9mIGRvaW5nIGl0LiAKCnNsaWRlIDQgLSAKClJvbmkgLSBPbiB0 aGUgMm5kIGJ1bGxldCwgaWYgd2UgaGF2ZSAzIGNhbWVyYXMgZG8gd2UgbmVlZCAzIG0tbGluZXM/ CgpSb2IgLSB5ZXMKClJvbmkgLSBJIGRvbid0IHRoaW5rIHdlIGFncmVlZCB0byB0aGF0LiBJZiB5 b3UgaGF2ZSBzYW1lIHNvdXJjZXMsIG9uZSBtLWxpbmUuIAoKUm9iIC0gQnV0IGhvdyB0byBleHBy ZXNzIGhvdyB0byBkbyBtdWx0aXBsZSB0aGluZ3MsIGxpa2UgcmVzb2x1dGlvbnM/CgpSb25pIC0g dGhpcyBpcyBzZW5kIGFuZCByZWNlaXZlLiBUaGF0J3Mgd2hhdCB3ZSdyZSB0YWxraW5nIGFib3V0 PwoKUm9iIC0gdXNpbmcgbXVsdGkgbS1saW5lcyBkb2Vzbid0IGJyZWFrIGl0LiBZb3UgbmVlZCBz ZXBhcmF0ZSBtLWxpbmVzIGlmIHlvdSB3YW50IGRpZmZlcmVudCByZXNvbHV0aW9ucy4KCkNocmlz dGVyIC0gb25lIG0tbGluZSBmb3Igc2VuZCBhbmQgb25lIGZvciByZWNlaXZlIHN0cmVhbT8gCgpS b2IgLSB5ZXMKCkNocmlzdGVyIC0gSSBoYXZlIGlzc3VlcyB3aXRoIHRoaXMuCgpSb2IgLSBpdCB3 aWxsIGJlIGRldGFpbGVkIGluIGxhdGVyIHNsaWRlcy4gCgpzbGlkZSA1IC0gCgpSb2IgLSB3ZSBk b24ndCB3YW50IHRvIG1hbmRhdGUgbXVsdGlwbGV4aW5nLiAKCkpvbmF0aGFuIC0gSSBzdWdnZXN0 ZWQgcGxhbiBaIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgaWYgdGhlIG1tdXNpYyB3b3JraW5nIGdy b3VwIGNyYXNoZWQgYW5kIGJ1cm5lZCwgd2hhdCB3b3VsZCBjbHVlIGRvPyBBcyB3ZSBkZXNpZ24g bXVsdGlwbGV4aW5nLCB3aGF0IGRvZXMgaXQgbmVlZCB0byByZXByZXNlbnQ/Cgpyb25pIC0gd2ls bCBiZSBkZXNjcmliZWQgYXMgbm90IG11bHRpcGxleCwgYW5kIHRoZW4gZGVjaWRlIGhvdyB0byBk byBpdCBhZnRlciBtbXVzaWMuIEV2ZW50dWFsbHkgd2Ugd2FudCB0byBtdWx0aXBsZXguIHNlcGFy YXRlIG0tbGluZXMgaXNuJ3Qgc2VwYXJhdGUgbS1saW5lcy4gCgpSb2IgLSB0aGlzIGlzbid0IG91 ciBmaW5hbCBzeW50YXgsIGJ1dCBpdCBzaG91bGRuJ3QgYmUgdGhyb3dhd2F5IHdvcmsuCgpzbGlk ZSA2IC0gSW5pdGlhbCBPL0E6IE9mZmVyCgpMZWZ0IG91dCB0aGUgYXVkaW8uCgpDaHJpc3RlciAt IHRoZSBpbml0IE8vQSB3aWxsIGhhdmUgYSBtLWxpbmUgZm9yIHRoZSBjbHVlIGNoYW5uZWwuCgpS b2IgLSB0aGVyZSBtYXkgYmUgc2lnbmFsaW5nIGluIHRoZSBzaXAgaGVhZGVycyB0aGF0IHlvdSBz dXBwb3J0IGNsdWUuIFRoaXMgaXMganVzdCBvbmUgbGluZSAtIHNlbmQgcmVjZWl2ZS4gCgpzbGlk ZSA3IC0gMm5kIE8vQQoKUm9iIC0gY2FuIHNlbmQgMyB2aWRlbyBzdHJlYW1zIC0gbGFiZWxlZC4g CihhIG1ham9yIGxpbWl0YXRpb24gLSBtaXNzZWQpCgpSb25pIHBvaW50ZWQgb3V0IGEgdHlwby4K ClJvYiAtIGRpZG4ndCBtZWFuIHRvIGNoYW5nZSB0aGUgbGV2ZWwuIEkgaGFkIHJlbW92ZWQgc29t ZSBsaW5lcyBb4oCmXQoKW+KApl0KClJvYiAtIGlmIHdlJ3JlIGhhcHB5IHdpdGggdGhpcyBhcHBy b2FjaCwgd2UgY2FuIHVwZGF0ZSB0aGUgY2FsbCBmbG93cy4gCgpzbGlkZSA4IC0gCgozIGNhbWVy YSBzeXN0ZW0sIG5lZWRzIHRvIGJlIGFibGUgdG8gdGFsayB0byAxIHNjcmVlbiBzeXN0ZW1zLiBJ IGhhdmUgYSBzd2l0Y2ggc3RyZWFtIC0gcGljayBvbiB3aG8gaXMgbG91ZGVzdC4gQ2FuIHN1YnNj cmliZSB0byBvbmUgb2YgdGhlIHN0cmVhbXMuIFRoZSBlbmQgcG9pbnQgY2FuIGVuZm9yY2Ugd2hh dCB5b3UgY2FuIHNlbGVjdC4gIAoKUm9uaSAtIGl0IHdvdWxkIGJlIGdvb2QgdGhhdCB5b3UgZG9u J3QgaGF2ZSB0byBzd2l0Y2ggZWFybHkgLSB0aGUgY2VudGVyIGNhbWVyYSBpcyBuZWdvdGlhdGVk IGZpcnN0LgoKUm9iIC0gSSB0aGluayB0aGF0J3MgYW4gYXBwbGljYXRpb24gZGVjaXNpb24uIAoK Um9uaSAtIFvigKZdCgpQYXVsIC0gdGhlIGxhYmVsIGlzIGFuIGVuY29kaW5nIAoKUm9iIC0gZW5j b2RpbmcgMSBsYWJlbCAxIGV0Yy4KClJvbmkgLSBpdCdzIGJlaW5nIHNlbnQgYW5kIHJlY2VpdmVk IG9uIHVuaXF1ZSBwb3J0cy4KCgpDaHJpc3RlciAtIHlvdSBzaG91bGQgbnVtYmVyIHRoZSBjYXB0 dXJlcywgeW91IOKApi4gZGVmaW5lIENhcHR1cmUgU2NlbmUgMiwgCgpSb2IgLSBpdCdzIGEgbWF0 dGVyIG9mIHN5bnRheC4gCgpDaHJpc3RlciAtIHlvdSBoYXZlIGFsbCB0aG9zZSBjYXB0dXJlcywg YW5kIHlvdSBtYXAgaW50byBlbmNvZGluZ+KApgoKUk9iIC0gQ29uZmlndXJhdGlvbiBtYWtlcyB0 aGUgdGllcyBvbiB0aGUgb3RoZXIgc2lkZS4gVGhlcmUncyBubyBkaXJlY3QgdGllIC0gNCBjYXB0 dXJlcyBhbmQgMyBlbmNvZGluZ3MuIAoKTWFnbnVzIC0gcGxlYXNlIHN1bW1hcml6ZQoKUm9iIC0g dGhlcmUncyBubyBkaXJlY3QgbGluayBiZXR3ZWVuIGNhcHR1cmVzIGFuZCBlbmNvZGluZ3MuIFRo YXQgaXMgbWFkZSBpbiB0aGUgY29uZmlndXJhdGlvbgoKSm9uYXRoYW4gLSBOb3QgcmVsZXZhbnQg YnV0IHdoZW4geW91IGhhdmUgbXVsdGlwbGV4IHdvcmtpbmcgdGhlIHJlY2VpdmVyIGFza3MgZm9y IGFsbCB0aGUgY2FwdHVyZXMuIFdoZW4geW91IGFkZCBtdWx0aXBsZXhpbmcsIGhvdyB0byBleHBy ZXNzIHRoYXQgaWRlYSBpbiB0aGlzIHN5bnRheC4KClJvYiAtIHRoZXJlJ3MgbnVtZXJvdXMgY2Fs bGZsb3cgYW5kIGZyYW1ld29yayBpc3N1ZXMgdGhhdCBJJ20gbm90IHRyeWluZyB0byBzb2x2ZSBo ZXJlCgo/Pz8gLSBhIGNsdWUgZnJhbWV3b3JrIGVuY29kaW5nIGlzIHJlcHJlc2VudGVkIGluIFNE UCBtLWxpbmUgYW5kIHBhcmFtZXRlcnMgLSBvbmUgZW5jb2RpbmcgYW5kIGdyb3VwIHRvZ2V0aGVy IHdpdGggbGFiZWxzLiAKClJvYiAtIHllcy4KCj8/PyAtIGlmIHRoZXJlIHdhcyBhIHdheSB0aGF0 IFNEUCBjb2xsYXBzZSBpbnRvIGZld2VyIG0tbGluZXMgd291bGQgdGhpcyBtYWtlIHNlbnNlPwoK Um9iIC0gbm8sIHlvdSBjYW4ndCB1c2UgbGFiZWxzLiAKCk1hcmsgLSBUaGUgc2ltdWx0YW5lb3Vz IHNldHMgaW5kaWNhdGUgdGhhdCB0aGUgcHJvZHVjZXIgY2FuIHNlbmQgYWxsIGF0IHRoZSBzYW1l IHRpbWUsIGJ1dCB0aGUgY29uc3VtZXIgY2FuJ3QgZW5jb2RlIGFsbCwgYmVjYXVzZSB0aGVyZSdz IG9ubHkgMyBlbmNvZGluZ3MuIEknbSBqdXN0IGNsYXJpZnlpbmcuCgpyb25pIC0gZ28gYmFjayBv bmUgc2xpZGUgLSB5b3UgY291bGQgaGF2ZSB1c2VkIG9uZSBsYWJlbCBmb3IgYWxsIDMgb2YgdGhl bS4KClJvYiAtIG5vLCBJZiB0aGUgcmVjZWl2ZXIgd2FudHMgdG8gcmVjZWl2ZSB3aXRoIGRpZmYg cGFyYW1zLCBuZWVkIDMgbS1saW5lcy4gCgpSb25pIC0gdGhpcyBpcyBqdXN0IGluZm8gb24gd2hh dCBpdCBjYW4gc2VuZC4gCgpQYXVsIGF0IG1pYyAtIHlvdSBjYW4gcHV0IG11bHRpcGxlIGxhYmVs cyBvbiB0aGUgc2FtZSBtLWxpbmUuCgpSb2IgLSB5ZXMKCk1vc2UgPyAtIEkgZG9uJ3Qgc3VwcG9y dCB0aGUgbGFiZWwgLSB0aGVyZSB3aWxsIGJlIHNldCBhIGZpZWxkcyBhbmQgcGFyYW1zIOKApgoK Ck1hcnkgLSB5b3UgY2FuJ3Qgc3VwcG9ydCBub3cgYnV0IG5lZWQgdG8gbWFrZSBhbiBleHRlbnNp b24KCnBhdWwgLSB3ZSdyZSBvbmx5IGxvb2tpbmcgYXQgb25lIHNpZGUgLSB0aGUgcmVjZWl2ZSBz aWRlIGhhcyB0byBtYXRjaCB0aGUgc2VuZCBzaWRlLiAKCnNsaWRlIDkgLSAzcmQgTy9BCgpSb2Ig LSBhZGRpbmcgbS1saW5lcywgbGlrZSB0aGUgcHJldmlvdXMgb25lcwoKUGF1bCAtIHlvdSBhcmUg c2F5aW5nIHRoYXQgdGhpcyB3YXMgcHV0IGluIGJ5IHNlZWluZyBhbiBhZHZlcnRpc2VtZW50CgpS b2IgLSB5ZXMKClBhdWwgLSBpZiBpdCB3YXMgYmVjYXVzZSBpdCBzYXcgYW4gb2ZmZXIgLSBpdCB3 b3VsZCBiZSBhbiBhbnN3ZXIKClJvYiAtIHllcywgaXQncyBhbiBhbnN3ZXIuCgpQYXVsIC0gc29t ZW9uZSBuZWVkcyB0byBwdXQgc29tZXRoaW5nIGluIGZvciB0aGUgb3RoZXIgZ3V5IG9yIHlvdSBn ZXQgbG90cyBvZiBPL0FzLiAKClJPYiAtIFRoZSBmYXIgc2lkZSBoYXMgcmVjZWl2ZWQgYW5kIGhh cyBwaWNrZWQgc3RyZWFtcyBpbmNsdWRpbmcgbmV3IG0tbGluZXMgYW5kIGlzIHJlY2VpdmVkCgpS b25pIC0gdGhlIG9mZmVyIHdlbnQgdG8gdGhlIG90aGVyIHNpZGUsIHRoZSBvdGhlciBzaWRlIGRp ZG4ndCBoYW5zd2VyLiBUaGVuIHRoZXJlIHdhcyBhbiBvZmZlciBmcm9tIHRoZSBvdGhlciBzaWRl IGFuZCB0aGlzIGlzIGFuIGFuc3dlciB0byB0aGUgb3RoZXIgc2lkZS4gSXQncyBub3QgYSAzcmQg Ty9BIAoKUm9iIC0gdGhhdCdzIHJpZ2h0LCBpdCB3YXMgY2xlYXJlciB3aGVuIEkgbWFkZSB0aGUg c2xpZGVzIGxhdGUgbGFzdCBuaWdodC4gCgpSb25pIC0gdGhlIG90aGVyIHNpZGUganVzdCBvZmZl cmVkIGp1c3QgMiBzdHJlYW1zLgoKUm9iIC0geWVzIC0geW91IGRvbid0IG5lZWQgdG8gcmVmZXIg dG8gdGhlIGZhciBlbmRzLgoKTWFyayBhc2tlZCBhYm91dCB0aGUgZm9ybWF0dGluZwoKUm9iIC0g eW91IHNlZW4gdGhlIHRvcCBiZWZvcmUgYW5kIHN0YXkgYXMgdGhleSBhcmUuIAoKCnNsaWRlIDEw IC0gCgpSb2IgLSBwdXR0aW5nIHRvZ2V0aGVyIHJlY2VpdmUgbS1saW5lcyB3aXRoIHRoZSByZW1v dGUgY2FwdHVyZQoKUm9uaSAtIEkgZGlkbid0IHNlZSB0aGUgbnVtYmVycwoKUm9iIC0gY2FwdHVy ZXMgMSwyLDMsNAoKUm9uaSAtIGNhcHR1cmUgMTAwLCAxMDEgaXMgdGhlIGZhciBzaWRlLiBUaGUg YXNzdW1wdGlvbiBoYXMgYW4gbS1saW5lIOKApi4gCgpSb2IgLSBpZiBvbmUgd2VudCBhd2F5IGFu ZCBjYW1lIGJhY2ssIHlvdSBjb3VsZCByZXVzZSBhbiBtLWxpbmUuIHlvdSd2ZSBnb3QgdGhlIGZp dmUgdHVwbGUuIAoKU3RldmUgLSB3aGF0IGlzIHRoZSB2YWx1ZSBvbiB0aGUgc2VuZC1vbmx5IGxh YmVsPyAKClJvYiAtIGl0cyBlbmNvZGluZyBncm91cGluZwoKUm9uaSAtIHNvIHRoZSBvdGhlciBz aWRlIHdhbnRzIHRoZSAzIGNhbWVyYXMgYW5kIHRoZW4gd2FudHMgb25seSB0aGUgc3dpdGNoIHZp ZXcsIGhlIHdvdWxkIG5lZWQgdG8gZG8gYW5vdGhlciBvL2EKClJvYiAtIEkgZG9uJ3QgdGhpbmsg c28gZm9yIOKApi4sIGp1c3Qgc2VuZCBuZXcgY2ZnLiBJZiB5b3UgY2hhbmdlIGZyb20gMyB0byBv bmUgeW91IHdvdWxkLgoKUGF1bCAtIGlmIHlvdSB3YW50IHRvIGdvIGZyb20gMyB0byBvbmUgLSB5 b3UgZG9uJ3QgbmVlZCB0byBjaGFuZ2UgdGhlIFNEUC4gSXQgbWlnaHQgYmUgYSBwcm9ibGVtIHdp dGggbWlkZGxlYm94ZXMuCgpSb2IgLSDigKYuCgpSb25pIC0geW91IGhhdmUgdG8gc2VuZCBTRFAu CgpST2IgLSB5ZXMKCkNocmlzdGVyIC0gYW5kIHN0dW4gaWYgeW91J3JlIHVzaW5nIGljZS4gCgpz bGlkZSAxNSAtIAoKUm9iIC0gSSBsZWZ0IHRoZSBjb25zdHJhaW50cyBvdXQuIEhvdyBtdWNoIGRv IHdlIHdhbnQgdG8gc29sdmUgaW4gY2x1ZT8gV2hhdCB3ZSBoYXZlIGlzIGluc3VmZmljaWVudCBh bmQgc2luZ2xlIGNvZGVjIGNlbnRyaWMKCkNocmlzdGVyIC0gRG9uJ3QgeW91IG5lZWQgdGhpcyBp biB5b3VyIGNhcHR1cmUgaW5mb3JtYXRpb24/IEknbSBhZHZlcnRpc2luZyBhIGhpZ2gtYmFuZCB3 aXRoIHN0cmVhbSBhbmQgb3RoZXIgc3RyZWFtcyBoYXZlIGxvdyByZXNvbHV0aW9uLiBJdCdzIG5v dCBtYXgsIGl0J3Mgd2hhdCBJJ20gYWR2ZXJ0aXNpbmcuIEkgZG9uJ3Qga25vdyBuZWVkIHRvIHNh eSwgaWYgeW91IGFyZSBnb2luZyB0byBkbyBzb21ldGhpbmcgZWxzZSwgSSd2ZSBnb3QgdGhlc2Ug Y29uc3RyYWludHMuCgpSb2IgLSBJIGRvbid0IHRoaW5rIGVuY29kaW5nIGlzIHRpZWQgdG8gY2Fw dHVyZXMuIFRoZXJlJ3MgaXNuJ3QgYSBtYXBwaW5nIGJldHdlZW4gd2hhdCB5b3UgY2FwdHVyZSBh bmQgd2hhdCB5b3UgZW5jb2RlLiBXZSBuZWVkIHRvIHRhbGsgYWJvdXQgdGhpcy4gSSBkb24ndCBo YXZlIGFuIGFuc3dlci4KCk1vc2VuIGVkZHkgLSB0aGVyZSdzIGFtYmlndWl0eSB3aXRoIE1heCAt IHlvdSBjYW4gZmxvYXQgZG93biBkdXJpbmcgdGhlIHNlc3Npb24uIAoKUm9iIC0geW91IGNvdWxk IHJlc2lnbmFsIFNEUAoKTW9zZW4gLSB5b3UgYXJlIGFsd2F5cyBhbGxvd2VkIHRvIGdvIGJlbG93 IG1heC4gV2ViUlRDIGhhcyBnb29kIGRlZmluaXRpb24gb2YgY29uc3RyYWludHMuIAoKTWFyayAt IGZyb20gdGhlIGZyYW1ld29yayBwb2ludCBvZiB2aWV3IC0gSSBhZ3JlZSB3aXRoIHlvdXIgIj8h PyEiLiBNdWx0aXBsZSBjb25zdHJhaW50cyBmb3Igb25lIGNvZGVjLiBUaGlzIGlzIGFuIGlzc3Vl LiBHb29kIHRvIGNvbnNpZGVyIGhvdyB0byBzb2x2ZSBpdCBpbiBjbHVlLgoKUm9iIC0gd2hlcmUg YXJlIHRoZSBjb25zdHJhaW50cyBsaXZlIC0gY2x1ZSBvciBTRFA/CgpDdWxsZW4gLSBlYXNpbHkg cHV0IHdpdGggU0RQIGFuZCB3b3VsZCB3b3JrIGJldHRlciB3aXRoIFJBSSBlY29zeXN0ZW0gYXMg YSB3aG9sZS4gCgpSb25pIC0gYWJvdXQgU0RQIGRlc2NyaXB0aW9uIC0gaWYgeW91IGRvbid0IHdy aXRlIGZ1bGwgZmxvdy4gSSB3b3VsZCBsaWtlIHRvIGxvb2sgYXQgaXQgZnJvbSBhIG11bHRpcGxl eCBwZXJzcGVjdGl2ZS4KClJvYiAtIEkgd2lsbCBjbGVhbiB0aGlzIHVwIGFuZCBleHBhbmQgaXQu IAoKUm9uaSAtIGl0IGNhbiBmYWxsIGludG8gdGhlIHNpZ25hbGluZywgbm8gaXNzdWUgd2l0aCBt YXBwaW5nIGJlY2F1c2UgdGhlcmUncyBubyBtdWx0aXBsZXhpbmcuCgpNYXJ5IC0gdGhpcyB3b3Vs ZCBiZSBpbiB0aGUgc2lnbmFsaW5nIHRlbXBsYXRlIGRvYy4gCgoKV3JhcC11cC9XYXkgRm9yd2Fy ZCAoMTAgbWluKQkKUHJlc2VudGF0aW9uOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzg2L3NsaWRlcy9zbGlkZXMtODYtY2x1ZS04LnBwdHgKUHJlc2VudGVyOiBjaGFpcnMKCnNlY3Vy aXR5IHRocmVhdHMgLSBNYXJ5IHdpbGwgcHV0IHNvbWV0aGluZyBpbiB0aGVyZSAKCk1hcnkgLSBS b25pIHdpbGwgcmV2aXZlIHVzZSBjYXNlcywgd2hpY2ggZXhwaXJlZC4gTm8gYWRkaXRpb25hbCBj b21tZW50cyBvbiBpdC4gTmVlZCBhbm90aGVyIHJldmlldyB0byBzZWUgaWYgaXQncyByZWFkeSBm b3IgV0dMQwoKUlRQIGRvYyAtIG5lZWQgbW9yZSBzb2x1dGlvbiBzdHVmZiB3b3JrZWQgb3V0LiAK ClBhdWwgLSBbP10KTWFyeSAtIFRoZSB1c2UgY2FzZSAtIC0gd2lsbCBwb3N0IHRvIHRoZSBsaXN0 IHRvIHNlZSBpZiBwZW9wbGUgd2FudCB0byBhZGQgdG8gdGhlIHVzZSBjYXNlIGRvYy4KCnNpZ25h bGluZyBkb2MgLSAKCgpTbGlkZSA3IC0gV2F5IEZvcndhcmQgCgpNYXJ5IC0gd2UgbG9zdCBzb21l IGtleSBwZW9wbGUgZWFybGllci4gV2lsbCBjb250aW51ZSB3aXRoIGRlc2lnbiB0ZWFtIGNhbGxz LiBEbyB3ZSBuZWVkIGFuIGludGVyaW0gbWVldGluZz8gV2lsbCBwb3N0IGEgZG9vZGxlLiAKCkdv bnpvIC0gd2UgYXJlIGV4cGVjdGluZyBhIHZpcnR1YWwgbWVldGluZyBmb3IgcnRjd2ViLgoKUGF1 bCAtIHJlZ2FyZGluZyBzaWduYWxpbmcgZG9jLCB3YW50IHRvIGdldCBpdCBzdGFydGVkLCBuZWVk cyBpbXB1dC4gU29tZW9uZSBoYXMgdG8gd3JpdGUgc29tZXRoaW5nLgoKTWFyeSAtIGNhbiBwdWxs IHNvbWUgZnJvbSB0aGUgZnJhbWV3b3JrIGRvYy4KCnBhdWwgLSB3ZSBuZWVkIGNvbnRyaWJ1dGlv bnMuIFBsZWFzZSBzcGVhayB1cC4gSG9wZWZ1bGx5IHRoZXJlIGlzIHNvbWVvbmUgaW50ZXJlc3Rl ZC4gPHNpbGVuY2U+CgpNYXJ5IC0gYW55dGhpbmcgZWxzZT8gTm90IGNvZGVjcy4KCldDSVQgQk9G IC0gdGhleSB3aWxsIHRhbGsgYWJvdXQgd2hhdCBoYXBwZW5lZCBhdCB0aGUgV0NJVC4gV2lsbCBi ZSBoZWxkIGF0IHRoZSBzYW1lIHRpbWUgYXMgYXZ0Y29yZSwgd2hpY2ggd2FzIGNhbmNlbGVkLCBp biBDYXJpYmJlYW4gMy4g --20cf306f73d89ac4fe04da7daba4-- From mary.ietf.barnes@gmail.com Tue Apr 16 10:28:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9921F95EC for ; Tue, 16 Apr 2013 10:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZS6nhbTjoLd for ; Tue, 16 Apr 2013 10:28:46 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8768E21F95E3 for ; Tue, 16 Apr 2013 10:28:46 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k19so333953qcs.13 for ; Tue, 16 Apr 2013 10:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=eMSu0oPOFm/QbQ9Xb65jCx329z1PenuTGA/3stc3KY8=; b=nYHDMAsHr6KjXMlwkTBV7T1x+Jz50Ag3JScXwgrh1szY+RrDisxhWiPr8o/Z7xTuT0 V4gDVQWQfPJpNI6bdPmIVztOVltnY6vI1V/VSQAkZD3vLg2iaICY2fWZpE2EAG9OOM0n n3X80IzXz8d+quv7yd1PlCHI24JKm40S1z5M7was9Qkgoc8L9v5Y1+mTcnVb7a5Kg+qh Z7f5yBpTQPR5iTWsC2c7OoTj705f1D+iCXOxuLQ0SHEWC1JinVFT3G11xJ23yonBCZ0o sLmvfKYKQXgBnT/d5Smgj/3qglPtejnaWh4yb+Flx4yVPib7Q3+gOHVS15eadeChbKbz XrNA== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr3784388qaj.72.1366133326001; Tue, 16 Apr 2013 10:28:46 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Tue, 16 Apr 2013 10:28:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Apr 2013 12:28:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Draft CLUE meeting summary X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2013 17:28:47 -0000 HI all, This is a draft of the meeting summary. We will post the completed version shortly (the raw notes have been in the meeting proceedings for a while), we just hadn't completed the summary. The action items are identified - we are just filling in the summary. I will send a separate note about scheduling a virtual interim to try to get some intermediate progress before IETF-87. I do not believe at this point that a f2f interim would be particularly fruitful. Mary. On Tue, Apr 16, 2013 at 12:26 PM, Mary Barnes wrote: > From mary.ietf.barnes@gmail.com Tue Apr 16 10:29:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8031E21F96C3 for ; Tue, 16 Apr 2013 10:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=1.780, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6ImOQ5UEzvV for ; Tue, 16 Apr 2013 10:29:35 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0B021F968B for ; Tue, 16 Apr 2013 10:29:35 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dx4so1002442qab.8 for ; Tue, 16 Apr 2013 10:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=pdZb8EKQBf2HxD4N99Tj7kTph6Vl1pqbEHnG/pog4dI=; b=ufwpCsxs7LXLW94WjKvaKIRCpyIELkYFbYMuQYY+ed71inRcgkt7Cg41ptJFDbGyy5 K1y8peTHNsJ5IJ5xFR2BrkiV/nrH8aVye3OwR6DwcOWzOy9Z3u/IcdDTxCMHXkvEFyP+ JQJ8vWXxM+3ZFwetaWkZ2H3EiCKdjO+WV/8dgEbhjsSuNg2xqTMpucBE0UkdRHr+yxcc QHhTAFnFJKnVFNhoqg7i6jONW8cdjJZ0/qq3B/uBNj2POpaqaYfcQMnNjGk8oYg/MAwB 9bCggikXWiUkd8JDmY2j0lm7vzioJODOVOsEXfZuHBQJcGro3Sm7Zp3wzybHJ1F6LQGk 81bw== MIME-Version: 1.0 X-Received: by 10.49.28.4 with SMTP id x4mr3926745qeg.39.1366133374827; Tue, 16 Apr 2013 10:29:34 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Tue, 16 Apr 2013 10:29:34 -0700 (PDT) In-Reply-To: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> Date: Tue, 16 Apr 2013 12:29:34 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2013 17:29:36 -0000 Hi all, There has been some good progress on the Framework I believe since the IETF-86 meeting. However, we could use more discussion around the signaling solution. Are folks working together offline or are we still where we were with Rob's proposal & discussion at the second session? Working offlist with a smaller group can be helpful, but please cc the chairs so we have an idea of the ongoing status. We haven't had the regular calls because there didn't seem to be a need. So, I am proposing a virtual interim - we could have it two days in a row (2 hrs each day) or just plan on two virtual interims separated by several weeks. If folks could please respond by CoB on Thursday, April 18th, we can get it scheduled by Friday. Thanks, Mary. ---------- Forwarded message ---------- From: Doodle Date: Mon, Apr 15, 2013 at 4:57 AM Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" To: Mary Barnes You have initiated a poll "CLUE WG (Virtual) Interim meeting" at Doodle. The link to your poll is: http://doodle.com/vrn825xzmbyaddgh Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) From mary.ietf.barnes@gmail.com Wed Apr 17 07:34:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACDB21F86A8 for ; Wed, 17 Apr 2013 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.709 X-Spam-Level: X-Spam-Status: No, score=-102.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugrO-fIfPQaT for ; Wed, 17 Apr 2013 07:34:37 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id B60E721F8648 for ; Wed, 17 Apr 2013 07:34:36 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dx4so1489897qab.1 for ; Wed, 17 Apr 2013 07:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=uN8rokG2UwQPstcZ8WJVFQWE26pqTerOWsP0MRquBlI=; b=uwHoFVh0sK/eUKjn48ssDaAdknYMjvodEPXQ3ITMt3IcOuEtfs0z5TmKvP3x94dJw4 vcce/sYjXOukanSFUep8S2YBn8T0ZhOpZadV/bxVxNrPj6ve/uNd61BBbvNvowGxKRI6 yXiIxDCeavmvcHSW1bflVWEVzcbM0doEfxamXe3vOozKL/muB3hrW0kRO/g/Vw5wIJpE W3y/8TngxH5ta1Vzh1wRK1TO0J8WJrwpBn2lDwt0QoPqyj6Si4MpFUvFbr+EPXT3gisf Lvaa+FoIHMbFgHPivkqPR+a3hhC1rHEKNPtFkJ6jBHC7fw3v8TYU/3ZNq0SeA00QPrHO Nrtw== MIME-Version: 1.0 X-Received: by 10.49.82.4 with SMTP id e4mr7559412qey.62.1366209276234; Wed, 17 Apr 2013 07:34:36 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Wed, 17 Apr 2013 07:34:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 09:34:36 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Draft CLUE meeting summary X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 14:34:37 -0000 Note that the CLUE IETF-86 minutes are now "complete". It was tough to tease out real conclusions, so please review and provide any comments by Friday, April 20th. While we have until May 1st to make any corrections, we may need to dig into the recordings, etc. to get any details absolutely correct. As a reminder, there is a doodle poll to arrange for a virtual interim: http://doodle.com/vrn825xzmbyaddgh Thanks, Mary. On Tue, Apr 16, 2013 at 12:26 PM, Mary Barnes wrote: > From jonathan@vidyo.com Wed Apr 17 07:47:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3601521F870F for ; Wed, 17 Apr 2013 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9jJ98+-98Q9 for ; Wed, 17 Apr 2013 07:47:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.254]) by ietfa.amsl.com (Postfix) with ESMTP id E938621F8550 for ; Wed, 17 Apr 2013 07:47:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9671F416B63 for ; Wed, 17 Apr 2013 10:47:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6BD44416C44 for ; Wed, 17 Apr 2013 10:47:14 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Wed, 17 Apr 2013 10:46:17 -0400 From: Jonathan Lennox To: Mary Barnes Date: Wed, 17 Apr 2013 10:47:16 -0400 Thread-Topic: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" Thread-Index: Ac47emj6vSy+WSESTO+YuMV1zPG5tg== Message-ID: <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> 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 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 14:47:24 -0000 The timezones offered in the Doodle poll for the U.S. are all standard time= s -- e.g., "GMT-0500 (EST)". Since the U.S. is on Daylight Savings Time for the dates covered by the pol= l, should I interpret that as actually meaning "GMT-0400 (EDT)", or do I ne= ed to select Canadian Atlantic time to get times that represent EDT (GMT-04= 00)? On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: > Hi all, >=20 > There has been some good progress on the Framework I believe since the > IETF-86 meeting. However, we could use more discussion around the > signaling solution. Are folks working together offline or are we > still where we were with Rob's proposal & discussion at the second > session? Working offlist with a smaller group can be helpful, but > please cc the chairs so we have an idea of the ongoing status. >=20 > We haven't had the regular calls because there didn't seem to be a > need. So, I am proposing a virtual interim - we could have it two > days in a row (2 hrs each day) or just plan on two virtual interims > separated by several weeks. >=20 > If folks could please respond by CoB on Thursday, April 18th, we can > get it scheduled by Friday. >=20 > Thanks, > Mary. >=20 >=20 > ---------- Forwarded message ---------- > From: Doodle > Date: Mon, Apr 15, 2013 at 4:57 AM > Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" > To: Mary Barnes >=20 >=20 > You have initiated a poll "CLUE WG (Virtual) Interim meeting" at > Doodle. The link to your poll is: >=20 > http://doodle.com/vrn825xzmbyaddgh >=20 > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have > used your e-mail address; simply ignore this e-mail, please.) > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 -- Jonathan Lennox jonathan@vidyo.com From mary.ietf.barnes@gmail.com Wed Apr 17 08:10:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0421F8614 for ; Wed, 17 Apr 2013 08:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cv7PWpwYEEt for ; Wed, 17 Apr 2013 08:10:03 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18F21F86A6 for ; Wed, 17 Apr 2013 08:10:03 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id b40so753344qcq.39 for ; Wed, 17 Apr 2013 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YyhwbH3VRFyIJHf2pdPy6hPirhO4MvKKkioe6LcpZzc=; b=yX6OoQghipr4rPf9tgwmS9wJbk15ol3+iQBFcHhi+UgeR2gtxF7BKlXQniMUvN5B+M ftO2Zcgzy+MfynDxsT3vvWYk3p2vIM1/V4JjsPmbgtY/Jizd9+0vUs9nXgEBrcyBGYkD OPPvyd/rAFQlALhTrgvJOacfEJd6ME5q2UUMNUMCr5sDTqUJqZ8E1Vjoqg3Z+vBoFs+5 /uXGtOMmrIPMR029kFjQtlj7EDqzBWJxjA89OfrAGwePRwWgDY6RN3CO+p2DV04v+h9s GKx2FwoXDuQbfZjbFogWqR7CYFbjvVLMiH3/GHX4UG1oSocf7taygr7rRASi5ozKUHG5 4kKw== MIME-Version: 1.0 X-Received: by 10.224.53.11 with SMTP id k11mr7113229qag.3.1366211401051; Wed, 17 Apr 2013 08:10:01 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Wed, 17 Apr 2013 08:10:00 -0700 (PDT) In-Reply-To: <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> Date: Wed, 17 Apr 2013 10:10:00 -0500 Message-ID: From: Mary Barnes To: Jonathan Lennox Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 15:10:05 -0000 You are asking a complex timezone question (I can't do timezone math). I intended the times to be in my timezone, which is GMT -0600 (Central). However, you are correct and Doodle has the times as GMT -0500 (for Central DT). We have two options, I can change the poll to be correct by making my timezone EDT. Or folks, can fill it out knowing that the GMT time is off by 1 hour. What is easier? Mary. On Wed, Apr 17, 2013 at 9:47 AM, Jonathan Lennox wrote: > The timezones offered in the Doodle poll for the U.S. are all standard times -- e.g., "GMT-0500 (EST)". > > Since the U.S. is on Daylight Savings Time for the dates covered by the poll, should I interpret that as actually meaning "GMT-0400 (EDT)", or do I need to select Canadian Atlantic time to get times that represent EDT (GMT-0400)? > > On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: > >> Hi all, >> >> There has been some good progress on the Framework I believe since the >> IETF-86 meeting. However, we could use more discussion around the >> signaling solution. Are folks working together offline or are we >> still where we were with Rob's proposal & discussion at the second >> session? Working offlist with a smaller group can be helpful, but >> please cc the chairs so we have an idea of the ongoing status. >> >> We haven't had the regular calls because there didn't seem to be a >> need. So, I am proposing a virtual interim - we could have it two >> days in a row (2 hrs each day) or just plan on two virtual interims >> separated by several weeks. >> >> If folks could please respond by CoB on Thursday, April 18th, we can >> get it scheduled by Friday. >> >> Thanks, >> Mary. >> >> >> ---------- Forwarded message ---------- >> From: Doodle >> Date: Mon, Apr 15, 2013 at 4:57 AM >> Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" >> To: Mary Barnes >> >> >> You have initiated a poll "CLUE WG (Virtual) Interim meeting" at >> Doodle. The link to your poll is: >> >> http://doodle.com/vrn825xzmbyaddgh >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally have >> used your e-mail address; simply ignore this e-mail, please.) >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > -- > Jonathan Lennox > jonathan@vidyo.com > > From pkyzivat@alum.mit.edu Wed Apr 17 08:17:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1538921E8037 for ; Wed, 17 Apr 2013 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNTJEsX-abVV for ; Wed, 17 Apr 2013 08:17:45 -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 0B50721E803D for ; Wed, 17 Apr 2013 08:17:44 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id R2gz1l0011YDfWL573HkUF; Wed, 17 Apr 2013 15:17:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id R3Hk1l00K3ZTu2S3g3HksR; Wed, 17 Apr 2013 15:17:44 +0000 Message-ID: <516EBD18.9060509@alum.mit.edu> Date: Wed, 17 Apr 2013 11:17:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366211864; bh=lvhpM6rLPFOy9eNxOAzPXZdQ8CrV5IKLy7hVNSzKlys=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YXlcTT0COOvawCxYL1oxAuwfhDzfkogDNeVoB/mzILsSblzkAQus2YQsDy1+gdhzj cCaGHnFM+QWryj1rcb9uHWobGZm+ABZ8AxYgwiUIDtzxr82hClR9KrImEELD+mNsa/ gP0Wt6Zzmyf5bYnNO34hC8c68iYi3rtoCWui3iSdnzwXc2c3tq2Ieqj8OcRNP2DWXB LxwVCfVJWuENFcoCgU7MNp5OXxeEXq0JdvhI9LWPlNSVnDNeVlieGu89ICtwyL3dzD hG+CRr7BhWbMq3ta4S5IO3W+wteJazI3qTCE/3WQjd+uAN1U8qeYCxpQ/c5ehum33O L2hqos1/lTDvw== Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 15:17:46 -0000 On 4/17/13 11:10 AM, Mary Barnes wrote: > You are asking a complex timezone question (I can't do timezone math). > I intended the times to be in my timezone, which is GMT -0600 > (Central). However, you are correct and Doodle has the times as GMT > -0500 (for Central DT). We have two options, I can change the poll > to be correct by making my timezone EDT. Or folks, can fill it out > knowing that the GMT time is off by 1 hour. What is easier? I think you should fix it. The other is likely to be just plain confusing. Thanks, Paul > Mary. > > On Wed, Apr 17, 2013 at 9:47 AM, Jonathan Lennox wrote: >> The timezones offered in the Doodle poll for the U.S. are all standard times -- e.g., "GMT-0500 (EST)". >> >> Since the U.S. is on Daylight Savings Time for the dates covered by the poll, should I interpret that as actually meaning "GMT-0400 (EDT)", or do I need to select Canadian Atlantic time to get times that represent EDT (GMT-0400)? >> >> On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: >> >>> Hi all, >>> >>> There has been some good progress on the Framework I believe since the >>> IETF-86 meeting. However, we could use more discussion around the >>> signaling solution. Are folks working together offline or are we >>> still where we were with Rob's proposal & discussion at the second >>> session? Working offlist with a smaller group can be helpful, but >>> please cc the chairs so we have an idea of the ongoing status. >>> >>> We haven't had the regular calls because there didn't seem to be a >>> need. So, I am proposing a virtual interim - we could have it two >>> days in a row (2 hrs each day) or just plan on two virtual interims >>> separated by several weeks. >>> >>> If folks could please respond by CoB on Thursday, April 18th, we can >>> get it scheduled by Friday. >>> >>> Thanks, >>> Mary. >>> >>> >>> ---------- Forwarded message ---------- >>> From: Doodle >>> Date: Mon, Apr 15, 2013 at 4:57 AM >>> Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" >>> To: Mary Barnes >>> >>> >>> You have initiated a poll "CLUE WG (Virtual) Interim meeting" at >>> Doodle. The link to your poll is: >>> >>> http://doodle.com/vrn825xzmbyaddgh >>> >>> Share this link with all those who should cast their votes. Do not >>> forget to cast your vote, too. >>> (If you did not initiate this poll, somebody must accidentally have >>> used your e-mail address; simply ignore this e-mail, please.) >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> -- >> Jonathan Lennox >> jonathan@vidyo.com >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Apr 17 08:24:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5221F872E for ; Wed, 17 Apr 2013 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.006 X-Spam-Level: X-Spam-Status: No, score=-103.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZL99+kKFiRq for ; Wed, 17 Apr 2013 08:24:07 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7F721F8709 for ; Wed, 17 Apr 2013 08:24:05 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so956384qeb.34 for ; Wed, 17 Apr 2013 08:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R/bzmIlRwWUaFCxl2Eu+WT3FQ8pyCcUJZlSmKQto2YE=; b=JemMB165+1o7rb4XU6w2LXMiv/WoFQzKf+vpcbW5dNRiQ1vvo484l9kg3rry7lEo4P qNAAYeDTikUvXHgLJ8pqmx9PJPBLRFnh/eZbqJ2jF+0mhzJk1Xr0+bN+fDsET0QgXenS KeIfgJKurmwxQl4GnKoNaleO+mWwbrOoedv0n35LXiEwmObb8frFyU0YJ9you8qYpE7E BkxrN56pAUI6C42bA91OoJsb5CKopJGHH3a2uIkBz8Xs1RsfdVH1dahfTkbfQ5BCaNUg r0RTF/8Phq5ueILGhG6Xv8MGElvDV21nrU1BNZBulWSFXTU2mOEiTFvIkPHeHb8xxbo4 n2gg== MIME-Version: 1.0 X-Received: by 10.229.6.193 with SMTP id a1mr2613537qca.14.1366212245569; Wed, 17 Apr 2013 08:24:05 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Wed, 17 Apr 2013 08:24:05 -0700 (PDT) In-Reply-To: <516EBD18.9060509@alum.mit.edu> References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> <516EBD18.9060509@alum.mit.edu> Date: Wed, 17 Apr 2013 10:24:05 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 15:24:10 -0000 On Wed, Apr 17, 2013 at 10:17 AM, Paul Kyzivat wrote: > On 4/17/13 11:10 AM, Mary Barnes wrote: >> >> You are asking a complex timezone question (I can't do timezone math). >> I intended the times to be in my timezone, which is GMT -0600 >> (Central). However, you are correct and Doodle has the times as GMT >> -0500 (for Central DT). We have two options, I can change the poll >> to be correct by making my timezone EDT. Or folks, can fill it out >> knowing that the GMT time is off by 1 hour. What is easier? > > > I think you should fix it. The other is likely to be just plain confusing. [MB] That means I need to redo the whole poll and folks will have to fill out again. But, that's okay, since there are some dates I can eliminate already based on the results. Although, it will still confuse me since it's not my right timezone. [/MB] > > Thanks, > Paul > > >> Mary. >> >> On Wed, Apr 17, 2013 at 9:47 AM, Jonathan Lennox >> wrote: >>> >>> The timezones offered in the Doodle poll for the U.S. are all standard >>> times -- e.g., "GMT-0500 (EST)". >>> >>> Since the U.S. is on Daylight Savings Time for the dates covered by the >>> poll, should I interpret that as actually meaning "GMT-0400 (EDT)", or do I >>> need to select Canadian Atlantic time to get times that represent EDT >>> (GMT-0400)? >>> >>> On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: >>> >>>> Hi all, >>>> >>>> There has been some good progress on the Framework I believe since the >>>> IETF-86 meeting. However, we could use more discussion around the >>>> signaling solution. Are folks working together offline or are we >>>> still where we were with Rob's proposal & discussion at the second >>>> session? Working offlist with a smaller group can be helpful, but >>>> please cc the chairs so we have an idea of the ongoing status. >>>> >>>> We haven't had the regular calls because there didn't seem to be a >>>> need. So, I am proposing a virtual interim - we could have it two >>>> days in a row (2 hrs each day) or just plan on two virtual interims >>>> separated by several weeks. >>>> >>>> If folks could please respond by CoB on Thursday, April 18th, we can >>>> get it scheduled by Friday. >>>> >>>> Thanks, >>>> Mary. >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Doodle >>>> Date: Mon, Apr 15, 2013 at 4:57 AM >>>> Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" >>>> To: Mary Barnes >>>> >>>> >>>> You have initiated a poll "CLUE WG (Virtual) Interim meeting" at >>>> Doodle. The link to your poll is: >>>> >>>> http://doodle.com/vrn825xzmbyaddgh >>>> >>>> Share this link with all those who should cast their votes. Do not >>>> forget to cast your vote, too. >>>> (If you did not initiate this poll, somebody must accidentally have >>>> used your e-mail address; simply ignore this e-mail, please.) >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> -- >>> Jonathan Lennox >>> jonathan@vidyo.com >>> >>> >> _______________________________________________ >> 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 mary.ietf.barnes@gmail.com Wed Apr 17 08:28:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55921F8B15 for ; Wed, 17 Apr 2013 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPRoBPbcWNnw for ; Wed, 17 Apr 2013 08:28:24 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8726921F871C for ; Wed, 17 Apr 2013 08:28:22 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id p6so1790635qad.19 for ; Wed, 17 Apr 2013 08:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fCwUt/j8UHA7tyaRvXUAKDNEeuLl2arQT/ygIs+WE+4=; b=goFH6ndLsin1JLuHV4D/zR8b9n2j05WXrCeiPYlYDr4WU+DcF13je1QQXfyOU/hMGb Il/QEtijIN5GaQkaH4VvRxgQuU++pOcVV7omg9tfI+Y8AIBfhsf+rhCMB6NtqjD6csqB 5jxldAKkrPT8U28nr2Hmg/TrY01CBTNEywmOXUDZy6nWC5SfRo/h6K0e/0VQPaeaUPYS qxXEHc93KavCJnxiMKdJ35G/X2XB/jFkQsBVLtztm9VM+GaaNHr1XXvsLB3eR9MvnAvo R2AUa8gWMK6Upek1LgeQSPr3wR59q9ENIm8xuR46nMWaYkat7LFFSeHgMnl/A+sZnt3K /z2w== MIME-Version: 1.0 X-Received: by 10.49.82.4 with SMTP id e4mr7776584qey.62.1366212502023; Wed, 17 Apr 2013 08:28:22 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Wed, 17 Apr 2013 08:28:21 -0700 (PDT) In-Reply-To: References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> <516EBD18.9060509@alum.mit.edu> Date: Wed, 17 Apr 2013 10:28:21 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 15:28:26 -0000 I think it's been fixed. So, everyone needs to set their timezone to one hour ahead to get it right. Mary. On Wed, Apr 17, 2013 at 10:24 AM, Mary Barnes wrote: > On Wed, Apr 17, 2013 at 10:17 AM, Paul Kyzivat wrote: >> On 4/17/13 11:10 AM, Mary Barnes wrote: >>> >>> You are asking a complex timezone question (I can't do timezone math). >>> I intended the times to be in my timezone, which is GMT -0600 >>> (Central). However, you are correct and Doodle has the times as GMT >>> -0500 (for Central DT). We have two options, I can change the poll >>> to be correct by making my timezone EDT. Or folks, can fill it out >>> knowing that the GMT time is off by 1 hour. What is easier? >> >> >> I think you should fix it. The other is likely to be just plain confusing. > [MB] That means I need to redo the whole poll and folks will have to > fill out again. But, that's okay, since there are some dates I can > eliminate already based on the results. Although, it will still > confuse me since it's not my right timezone. [/MB] >> >> Thanks, >> Paul >> >> >>> Mary. >>> >>> On Wed, Apr 17, 2013 at 9:47 AM, Jonathan Lennox >>> wrote: >>>> >>>> The timezones offered in the Doodle poll for the U.S. are all standard >>>> times -- e.g., "GMT-0500 (EST)". >>>> >>>> Since the U.S. is on Daylight Savings Time for the dates covered by the >>>> poll, should I interpret that as actually meaning "GMT-0400 (EDT)", or do I >>>> need to select Canadian Atlantic time to get times that represent EDT >>>> (GMT-0400)? >>>> >>>> On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: >>>> >>>>> Hi all, >>>>> >>>>> There has been some good progress on the Framework I believe since the >>>>> IETF-86 meeting. However, we could use more discussion around the >>>>> signaling solution. Are folks working together offline or are we >>>>> still where we were with Rob's proposal & discussion at the second >>>>> session? Working offlist with a smaller group can be helpful, but >>>>> please cc the chairs so we have an idea of the ongoing status. >>>>> >>>>> We haven't had the regular calls because there didn't seem to be a >>>>> need. So, I am proposing a virtual interim - we could have it two >>>>> days in a row (2 hrs each day) or just plan on two virtual interims >>>>> separated by several weeks. >>>>> >>>>> If folks could please respond by CoB on Thursday, April 18th, we can >>>>> get it scheduled by Friday. >>>>> >>>>> Thanks, >>>>> Mary. >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Doodle >>>>> Date: Mon, Apr 15, 2013 at 4:57 AM >>>>> Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" >>>>> To: Mary Barnes >>>>> >>>>> >>>>> You have initiated a poll "CLUE WG (Virtual) Interim meeting" at >>>>> Doodle. The link to your poll is: >>>>> >>>>> http://doodle.com/vrn825xzmbyaddgh >>>>> >>>>> Share this link with all those who should cast their votes. Do not >>>>> forget to cast your vote, too. >>>>> (If you did not initiate this poll, somebody must accidentally have >>>>> used your e-mail address; simply ignore this e-mail, please.) >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> -- >>>> Jonathan Lennox >>>> jonathan@vidyo.com >>>> >>>> >>> _______________________________________________ >>> 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 mzanaty@cisco.com Wed Apr 17 09:06:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA521E8049 for ; Wed, 17 Apr 2013 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VVuEZbd+TJF for ; Wed, 17 Apr 2013 09:06:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA921E8044 for ; Wed, 17 Apr 2013 09:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5391; q=dns/txt; s=iport; t=1366214812; x=1367424412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UHSX3FYPjJJ7Zqeq6mqMmIqmzrCcz7NMg6jHebvjmFM=; b=VS7vsq2INOYMdjrBrjmSKOYTJM1oga36qKDFIpDawzPPXFmrtbFigvvQ LVBgsEPJouuTKXIMo2UrsuQXxQ8acgPnqS5XjEs5wXj3TgYgkvJh8AGRr GrMInhQZleaV9dNE0HO4hHxJWXUL91jeWgUNxVp0YAizYaEiR9Z0pfPwh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFALbHblGtJV2b/2dsb2JhbABQDoJ4NsBDgQMWdIIfAQEBBAEBATcsCAsMBAIBCBEDAQEBAQoUCQchBgsUCQgCBAENBQgTh2cDDwyzbQ2JXYxHgSGBASYLBwaCX2EDlSODBopVhRyCTD+BczU X-IronPort-AV: E=Sophos;i="4.87,494,1363132800"; d="scan'208";a="199660604" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 17 Apr 2013 16:06:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3HG6pBf019141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 16:06:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 11:06:51 -0500 From: "Mo Zanaty (mzanaty)" To: Mary Barnes , Paul Kyzivat Thread-Topic: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" Thread-Index: AQHOO3+eqMQEHz2skUmYanQX8Tszu5ja3TWA//+uozA= Date: Wed, 17 Apr 2013 16:06:50 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6D9650@xmb-rcd-x14.cisco.com> References: <2087384085.5976907.1366019828660.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> <824A9527-BC68-4815-B96C-FC74FA140DA3@vidyo.com> <516EBD18.9060509@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2013 16:06:53 -0000 Doodle has a timezone bug when displaying/selecting your timezone. It alway= s shows standard times even though you are on summer/daylight time. But if = you just select your standard timezone, the times in the table are actually= correct for summer/daylight time. So the timezone label is wrong, but the = actual times are right. Do not set your timezone one hour ahead, that will give incorrect times in = the table. Set the name of your timezone, ignoring the standard/summer/dayl= ight label, and the table times will be correct for summer/daylight time. I= f you are in an area which doesn't follow summer/daylight time, and Doodle = understands this and offers a special timezone (like MST/Arizona), the tabl= e times are right for your (standard) timezone. If you are in an area which= doesn't follow summer/daylight time, and Doodle doesn't understand this an= d offers no special timezone for you (like CST/Mary), you need to realize t= he table times are summer/daylight time not standard time (despite the inco= rrect timezone label), so you must manually convert to standard time (subtr= act an hour). Mo -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Wednesday, April 17, 2013 11:28 AM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE WG (Virtual) Interim m= eeting" I think it's been fixed. So, everyone needs to set their timezone to one hour ahead to get it right. Mary. On Wed, Apr 17, 2013 at 10:24 AM, Mary Barnes wrote: > On Wed, Apr 17, 2013 at 10:17 AM, Paul Kyzivat wr= ote: >> On 4/17/13 11:10 AM, Mary Barnes wrote: >>> >>> You are asking a complex timezone question (I can't do timezone math). >>> I intended the times to be in my timezone, which is GMT -0600 >>> (Central). However, you are correct and Doodle has the times as GMT >>> -0500 (for Central DT). We have two options, I can change the poll >>> to be correct by making my timezone EDT. Or folks, can fill it out >>> knowing that the GMT time is off by 1 hour. What is easier? >> >> >> I think you should fix it. The other is likely to be just plain confusin= g. > [MB] That means I need to redo the whole poll and folks will have to > fill out again. But, that's okay, since there are some dates I can > eliminate already based on the results. Although, it will still > confuse me since it's not my right timezone. [/MB] >> >> Thanks, >> Paul >> >> >>> Mary. >>> >>> On Wed, Apr 17, 2013 at 9:47 AM, Jonathan Lennox >>> wrote: >>>> >>>> The timezones offered in the Doodle poll for the U.S. are all standard >>>> times -- e.g., "GMT-0500 (EST)". >>>> >>>> Since the U.S. is on Daylight Savings Time for the dates covered by th= e >>>> poll, should I interpret that as actually meaning "GMT-0400 (EDT)", or= do I >>>> need to select Canadian Atlantic time to get times that represent EDT >>>> (GMT-0400)? >>>> >>>> On Apr 16, 2013, at 1:29 PM, Mary Barnes wrote: >>>> >>>>> Hi all, >>>>> >>>>> There has been some good progress on the Framework I believe since th= e >>>>> IETF-86 meeting. However, we could use more discussion around the >>>>> signaling solution. Are folks working together offline or are we >>>>> still where we were with Rob's proposal & discussion at the second >>>>> session? Working offlist with a smaller group can be helpful, but >>>>> please cc the chairs so we have an idea of the ongoing status. >>>>> >>>>> We haven't had the regular calls because there didn't seem to be a >>>>> need. So, I am proposing a virtual interim - we could have it two >>>>> days in a row (2 hrs each day) or just plan on two virtual interims >>>>> separated by several weeks. >>>>> >>>>> If folks could please respond by CoB on Thursday, April 18th, we can >>>>> get it scheduled by Friday. >>>>> >>>>> Thanks, >>>>> Mary. >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Doodle >>>>> Date: Mon, Apr 15, 2013 at 4:57 AM >>>>> Subject: Doodle: Link for poll "CLUE WG (Virtual) Interim meeting" >>>>> To: Mary Barnes >>>>> >>>>> >>>>> You have initiated a poll "CLUE WG (Virtual) Interim meeting" at >>>>> Doodle. The link to your poll is: >>>>> >>>>> http://doodle.com/vrn825xzmbyaddgh >>>>> >>>>> Share this link with all those who should cast their votes. Do not >>>>> forget to cast your vote, too. >>>>> (If you did not initiate this poll, somebody must accidentally have >>>>> used your e-mail address; simply ignore this e-mail, please.) >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> -- >>>> Jonathan Lennox >>>> jonathan@vidyo.com >>>> >>>> >>> _______________________________________________ >>> 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 mary.ietf.barnes@gmail.com Fri Apr 19 09:47:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5307F21F95F5 for ; Fri, 19 Apr 2013 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY2l9z5Q30hb for ; Fri, 19 Apr 2013 09:47:24 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7507721F944A for ; Fri, 19 Apr 2013 09:47:21 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id z24so2160321qcq.33 for ; Fri, 19 Apr 2013 09:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lu6TPUWKDhhhgCd13gGL0AMgesT1xey9mWJgXR823DE=; b=B4uhDGpCdUE1E+jnPFo4ICXHfCqIp0Z2qscDDffo30ab1HXC+LH7X7Fyi40z0nPItj uFm774v0RwVM1r5n+wnYtEPLo7hJAgUrrpRwDWOZHpp/0NkWXcU2v2NBBGnPV3uUgiM6 J6GZjx6z5B935rHLk3YpeyAFCHRUU32S0S5ovohz6wZoQruDchz0inNDKON6oZDGx11i ZKl2SWDMdrqWwvuYyWuinNZKvC4JeOeYSkWgXI8GaLTn+4QMAovt/2O7dIIu5iwMCDGz zMp9vIanJhSYQUR9Uz+wwt1NsxVvSvnVp9kSzne+t/XzEuYZg+Q0cwAM7bXMw8DZFCR+ wvag== MIME-Version: 1.0 X-Received: by 10.49.82.4 with SMTP id e4mr16524668qey.62.1366390040935; Fri, 19 Apr 2013 09:47:20 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Fri, 19 Apr 2013 09:47:20 -0700 (PDT) In-Reply-To: <784096198.8210.1366306996681.JavaMail.nobody@jva2tc004.webex.com> References: <784096198.8210.1366306996681.JavaMail.nobody@jva2tc004.webex.com> Date: Fri, 19 Apr 2013 11:47:20 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Meeting invitation: CLUE WG Virtual Interim Meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2013 16:47:25 -0000 HI all, The doodle indicated that May 21st starting at 9:00 am Central was the best choice for the meeting. Below, please find the Webex details. A preliminary agenda has been posted on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart The meeting will be officially announced on the IETF announcement list shortly. Since this is an official interim meeting the materials will be published in the Interim Meeting proceedings: http://www.ietf.org/meeting/interim/proceedings.html Thanks, Mary. Topic: CLUE WG Virtual Interim Meeting Date: Tuesday, May 21, 2013 Time: 8:45 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 645 648 772 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=178173047&UID=1371736752&PW=NOTMwYjc0MzJj&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=178173047&UID=1371736752&PW=NOTMwYjc0MzJj&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:645 648 772 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=178173047&UID=1371736752&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAukM5WDgvTjfgpnAegUxclfmO-HIqVVr5nm-1VptrNHu&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x645648772# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From iesg-secretary@ietf.org Fri Apr 19 11:23:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9B21F961F; Fri, 19 Apr 2013 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcYF2NudPRLj; Fri, 19 Apr 2013 11:23:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5729121F961B; Fri, 19 Apr 2013 11:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130419182331.23663.89360.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 11:23:31 -0700 Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting: May 21, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2013 18:23:31 -0000 The CLUE WG will hold an Interim meeting on: May 21, 2013, 14.00-16.00 GMT (starting at 7.00 Pacific, 9.00 Central, 10.00 Eastern) Webex details and a link to the preliminary agenda have been announced on the CLUE WG mailing list: http://www.ietf.org/mail-archive/web/clue/current/msg02547.html From marks4@hushmail.com Mon Apr 22 04:52:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80221F884F for ; Mon, 22 Apr 2013 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MhZkWgzdZBZ for ; Mon, 22 Apr 2013 04:52:04 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 185CC21F85DB for ; Mon, 22 Apr 2013 04:52:03 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id B2E3DE7A7E for ; Mon, 22 Apr 2013 11:52:02 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Mon, 22 Apr 2013 11:52:01 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A9B1EA6E34; Mon, 22 Apr 2013 11:52:01 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 22 Apr 2013 07:52:01 -0400 To: clue@ietf.org From: marks4@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130422115201.A9B1EA6E34@smtp.hushmail.com> Subject: [clue] test message, please ignore X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 Apr 2013 11:52:58 -0000 I just joined the group and this message is a test message, please ignore From johnsonhammond2@hushmail.com Sat Apr 27 10:13:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7521F9822 for ; Sat, 27 Apr 2013 10:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+D0rbkHPL5q for ; Sat, 27 Apr 2013 10:13:07 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0421F9821 for ; Sat, 27 Apr 2013 10:13:06 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 386DF303C9 for ; Sat, 27 Apr 2013 17:11:56 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:11:56 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E7A3A14DBE1; Sat, 27 Apr 2013 17:11:55 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:11:55 -0400 To: clue@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427171155.E7A3A14DBE1@smtp.hushmail.com> Subject: [clue] Biggest Fake Conference in Computer Science X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2013 18:07:39 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From Mark.Duckworth@polycom.com Tue Apr 30 06:06:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8421F842B for ; Tue, 30 Apr 2013 06:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg6nAxmQ3Neo for ; Tue, 30 Apr 2013 06:06:10 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06821F9B4C for ; Tue, 30 Apr 2013 06:06:07 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 30 Apr 2013 06:06:06 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 30 Apr 2013 06:06:04 -0700 Thread-Topic: Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries Thread-Index: Ac5FojlN3bf5TUXZQr2IHkPIJ+y6/w== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> 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_49E45C59CA48264997FEBFB29B6BC2D65CE8AECRPMBOXPRD07polyc_" MIME-Version: 1.0 Subject: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2013 13:06:16 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D65CE8AECRPMBOXPRD07polyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a follow up to an action item from IETF-86. I said I would propose= text based on the discussion to allow a Media Provider to represent Simult= aneous Transmission Sets in terms of Capture Scenes and Capture Scene Entri= es. Currently the framework says a Simultaneous Transmission Set is a set = of Media Captures of a particular media type. =3D=3D=3D begin proposed new paragraph to add near end of section 6.3 =3D= =3D=3D For shorthand convenience, a Provider may describe a Simultaneous Transmiss= ion Set in terms of Capture Scene Entries and Capture Scenes. If a Capture= Scene Entry is included in a Simultaneous Transmission Set, then all Media= Captures in the Capture Scene Entry are included in the Simultaneous Trans= mission Set. 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. The end result reduces = to a set of Media Captures in any case. =3D=3D=3D end proposed new paragraph to add near end of section 6.3 =3D=3D= =3D I suggest we do not make this change, and instead just describe a Simultane= ous Transmission Set as a set of Media Captures. I think allowing the addi= tional ways to represent the set adds complication without adding value. A= Media Consumer that wants to use simultaneous sets would have more work to= do to parse out the contents of the set. Your thoughts? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D65CE8AECRPMBOXPRD07polyc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a follow= up to an action item from IETF-86.  I said I would propose text based= on the discussion to allow a Media Provider to represent Simultaneous Tran= smission Sets in terms of Capture Scenes and Capture Scene Entries.  C= urrently the framework says a Simultaneous Transmission Set is a set of Med= ia Captures of a particular media type.

=  

=3D=3D=3D begin proposed new para= graph to add near end of section 6.3 =3D=3D=3D

For shorthand convenience, a Provider may describe a Simultaneous Tr= ansmission Set in terms of Capture Scene Entries and Capture Scenes.  = If a Capture Scene Entry is included in a Simultaneous Transmission Set, th= en all Media Captures in the Capture Scene Entry are included in the Simult= aneous Transmission Set.  If a Capture Scene is included in a Simultan= eous Transmission Set, then all its Capture Scene Entries (of the correspon= ding media type) are included in the Simultaneous Transmission Set.  T= he end result reduces to a set of Media Captures in any case.

=3D=3D=3D end proposed new paragraph to add near end = of section 6.3 =3D=3D=3D

 

I suggest we do not make this change, and instea= d just describe a Simultaneous Transmission Set as a set of Media Captures.=   I think allowing the additional ways to represent the set adds compl= ication without adding value.  A Media Consumer that wants to use simu= ltaneous sets would have more work to do to parse out the contents of the s= et.

 

Your thoughts?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D65CE8AECRPMBOXPRD07polyc_-- From pkyzivat@alum.mit.edu Tue Apr 30 09:45:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E321F9C77 for ; Tue, 30 Apr 2013 09:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQwT8Gj+CdX1 for ; Tue, 30 Apr 2013 09:45:37 -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 A76C121F9BFD for ; Tue, 30 Apr 2013 09:45:37 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id WFbc1l0010QuhwU5CGlYt4; Tue, 30 Apr 2013 16:45:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id WGlY1l00u3ZTu2S3NGlYMK; Tue, 30 Apr 2013 16:45:32 +0000 Message-ID: <517FF52C.204@alum.mit.edu> Date: Tue, 30 Apr 2013 12:45:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.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=q20121106; t=1367340332; bh=pQJcmgvblO4FmC3N6OmGmyk4UHhrGMZfBP+PbkjhN/g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hzF/wvxvkKRMB7J8jtjKnB4rZeeCYDlY2oxK5eAT3etzsmomNLqyhDDKejg1SZp58 bFx0CZGE2BOyEF2EUVR630vXt+UY0oduYiz3N8rP8Se4Cj+oq4/3cT3tIwMZkxxLpZ 9iXJn6wcDaikK6R6Jgy3quqltlspUElKj1SKBNSo+yp8f9BX1+IVmv7DVXhEIr0yJA 1yzT4HGpaYK1cVwjqaP2FCcyxzdXu7VPPQA+5x8tQ5kUkfCplPr0Lu40E5ovnKoZvn 4UBhIOmXDguuF7wRnEUtKwPaZhIMmhTaSSrC0CmhmO0aH3sy+b75wsYnImuA34mfCf oplX/6mNew4TQ== Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2013 16:45:43 -0000 On 4/30/13 9:06 AM, Duckworth, Mark wrote: > This is a follow up to an action item from IETF-86. I said I would > propose text based on the discussion to allow a Media Provider to > represent Simultaneous Transmission Sets in terms of Capture Scenes and > Capture Scene Entries. Currently the framework says a Simultaneous > Transmission Set is a set of Media Captures of a particular media type. > > === begin proposed new paragraph to add near end of section 6.3 === > > For shorthand convenience, a Provider may describe a Simultaneous > Transmission Set in terms of Capture Scene Entries and Capture Scenes. > If a Capture Scene Entry is included in a Simultaneous Transmission Set, > then all Media Captures in the Capture Scene Entry are included in the > Simultaneous Transmission Set. 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. The end result reduces to a set of Media Captures in > any case. > > === end proposed new paragraph to add near end of section 6.3 === I see one issue with the above. AFAIK the only way one knows the media type of a Simultaneous Transmission Set is by observing the type of the captures it contains. In the above, if a STS contained *only* Capture Scenes, then there would be no way to decide what type it was. (Of course this wouldn't be a problem is STSs contained all types.) > I suggest we do not make this change, and instead just describe a > Simultaneous Transmission Set as a set of Media Captures. I think > allowing the additional ways to represent the set adds complication > without adding value. A Media Consumer that wants to use simultaneous > sets would have more work to do to parse out the contents of the set. > > Your thoughts? I haven't got strong feelings pro or con. But not making the change means one doesn't have to solve the above problem. Thanks, Paul From Mark.Duckworth@polycom.com Tue Apr 30 15:16:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9B21F8F12 for ; Tue, 30 Apr 2013 15:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNx6-t4e7qxF for ; Tue, 30 Apr 2013 15:16:24 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9334D21F8ECE for ; Tue, 30 Apr 2013 15:16:22 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 30 Apr 2013 15:16:22 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 30 Apr 2013 15:16:20 -0700 Thread-Topic: usage of Conference Roles - valid only with switched captures? Thread-Index: Ac5F7ekJDeapMiP/R6adJ/juAbx1xA== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> 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_49E45C59CA48264997FEBFB29B6BC2D65CECE6CRPMBOXPRD07polyc_" MIME-Version: 1.0 Subject: [clue] usage of Conference Roles - valid only with switched captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2013 22:16:29 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D65CECE6CRPMBOXPRD07polyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question about section 4.4.2 Conference Roles from draft-groves-clue-captur= e-attr-01. The initial set of roles here is Speaker and Controller, both o= f which are expected to apply to different Endpoints (or Media Capture orig= inating from an Endpoint) at different times. Given that, is the intent th= at these roles should be applied only to Media Captures which have the attr= ibute switched=3Dtrue? We don't want a Provider to send a new advertisemen= t every time the current speaker in a conference changes, do we? It would = make sense to me for a middlebox to use this type of attribute for a switch= ed capture, or even an Endpoint could use it if it switches between differe= nt local captures. Also, the Role=3DController would apply to an Endpoint, not a Media Capture= , is that correct? Or would it apply to every Media Capture that is sent f= rom the Endpoint that is the current Controller? If so, then the endpoint = would have to change its advertisement when its Controller status changes? = That doesn't make sense to me. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D65CECE6CRPMBOXPRD07polyc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Question about s= ection 4.4.2 Conference Roles from draft-groves-clue-capture-attr-01. = The initial set of roles here is Speaker and Controller, both of which are= expected to apply to different Endpoints (or Media Capture originating fro= m an Endpoint) at different times.  Given that, is the intent that the= se roles should be applied only to Media Captures which have the attribute = switched=3Dtrue?  We don’t want a Provider to send a new adverti= sement every time the current speaker in a conference changes, do we? = It would make sense to me for a middlebox to use this type of attribute fo= r a switched capture, or even an Endpoint could use it if it switches betwe= en different local captures.

 =

Also, the Role=3DController would apply to a= n Endpoint, not a Media Capture, is that correct?  Or would it apply t= o every Media Capture that is sent from the Endpoint that is the current Co= ntroller?  If so, then the endpoint would have to change its advertise= ment when its Controller status changes?  That doesn’t make sens= e to me.

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D65CECE6CRPMBOXPRD07polyc_-- From trac+clue@trac.tools.ietf.org Tue Apr 30 16:24:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B514921F842F for ; Tue, 30 Apr 2013 16:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMM5A1XHpX48 for ; Tue, 30 Apr 2013 16:24:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 07EB021F8415 for ; Tue, 30 Apr 2013 16:24:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:44270 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXJu7-0004Um-Re; Wed, 01 May 2013 01:24:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 30 Apr 2013 23:24:11 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://grenache.levkowetz.com/wg/clue/trac/ticket/9#comment:2 Message-ID: <083.4c00bc62b4644f7264449234961620a5@trac.tools.ietf.org> References: <068.55b235ae09bcadb5a9adc0e971bc9935@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <068.55b235ae09bcadb5a9adc0e971bc9935@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130430232417.07EB021F8415@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 16:24:16 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #9: Axis of capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 23:24:19 -0000 #9: Axis of capture description Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This ticket was resolved in the -07 version of the framework based on mailing list consensus: http://www.ietf.org/mail-archive/web/clue/current/msg01716.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Apr 30 16:27:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A2D21F8517 for ; Tue, 30 Apr 2013 16:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc0PKzR1DQsg for ; Tue, 30 Apr 2013 16:27:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9241021F84F9 for ; Tue, 30 Apr 2013 16:27:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:44384 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXJxX-0004BI-Rt; Wed, 01 May 2013 01:27:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 30 Apr 2013 23:27:43 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/17#comment:2 Message-ID: <083.55fb3d104883490058f6582c95f69590@trac.tools.ietf.org> References: <068.25a4178fb63cd674b6552283ea553062@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <068.25a4178fb63cd674b6552283ea553062@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130430232748.9241021F84F9@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 16:27:48 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #17: Action Item: Capture Encoding term X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 23:27:49 -0000 #17: Action Item: Capture Encoding term Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was addressed in the -07 version of the framework per the proposal on the mailing list: http://www.ietf.org/mail-archive/web/clue/current/msg02035.html A "capture encoding" definition was added and this new term is used throughout document as appropriate, replacing some usage of the terms "stream" and "encoding". -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Apr 30 16:30:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3C21F851E for ; Tue, 30 Apr 2013 16:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RelrpHVbfDpB for ; Tue, 30 Apr 2013 16:30:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBAC21F8808 for ; Tue, 30 Apr 2013 16:30:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:44436 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXJzr-0007KD-3B; Wed, 01 May 2013 01:30:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com X-Trac-Project: clue Date: Tue, 30 Apr 2013 23:30:07 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/18#comment:3 Message-ID: <083.b8e4b8622ec67782c5243f342b594d13@trac.tools.ietf.org> References: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130430233010.7FBAC21F8808@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 16:30:10 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 23:30:11 -0000 #18: Action Item (v): Limitations on Simulcast Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was resolved in the -07 version of the framework by adding Max Capture Encodings media capture attribute, per the mailing list proposal: http://www.ietf.org/mail-archive/web/clue/current/msg02036.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From Christian.Groves@nteczone.com Tue Apr 30 18:43:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95121F85B4 for ; Tue, 30 Apr 2013 18:43:45 -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=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX5cT2qRs1Zd for ; Tue, 30 Apr 2013 18:43:45 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 1791C21F8765 for ; Tue, 30 Apr 2013 18:43:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPpygFF20dxV/2dsb2JhbAANRYM9gze7VIEUgxMBAQEDAQEBASAPAQUbFQYKBgsLGAICBRYLAgIJAwIBAgEVMBMGAgEBiAISrSpykRQEgSONfYI9gRMDq3I Received: from ppp118-209-220-85.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.220.85]) by ipmail04.adl6.internode.on.net with ESMTP; 01 May 2013 11:13:40 +0930 Message-ID: <51807349.9080906@nteczone.com> Date: Wed, 01 May 2013 11:43:37 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] usage of Conference Roles - valid only with switched captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 01:43:46 -0000 Hello Mark, I'm in the process of finishing a draft that discusses "role" in some more detail. Basically the premise is that the current set of roles semantically should be separated. After the discussions on the dispatch list it become apparent that people sees "role" for different semantics, i.e. there are different categories of roles. e.g. * Meeting Roles - These roles relate to typical traditional functions when a meeting is held, chairman, secretary, etc. * Conference roles - These roles are related to the establishment and maintenance of the multimedia conference and are related to the scope of the conference system only, speaker, controller, participant etc. * Person name title - These are roles (titles) given to a person depicted by the media capture e.g. Doctor, Professor. * Occupational role - These are roles given to people in an organisation e.g. CEO, MD, VP etc. Again these would be the persons depicted in the media capture. * Meeting Specific role - Some groups may want to assign their own role that has meaning to the participants in a particular conference. They all could be considered as having some role in a conference and a media capture could be assigned multiple ones. Regards, Christian On 1/05/2013 8:16 AM, Duckworth, Mark wrote: > > Question about section 4.4.2 Conference Roles from > draft-groves-clue-capture-attr-01. The initial set of roles here is > Speaker and Controller, both of which are expected to apply to > different Endpoints (or Media Capture originating from an Endpoint) at > different times. Given that, is the intent that these roles should be > applied only to Media Captures which have the attribute switched=true? > We don’t want a Provider to send a new advertisement every time the > current speaker in a conference changes, do we? It would make sense to > me for a middlebox to use this type of attribute for a switched > capture, or even an Endpoint could use it if it switches between > different local captures. > [CNG] My definitions for Speaker / Controller / Participant would be: • Speaker / Presenter – Can share content/media with others. • Controller / Host – Indicates the person responsible for controlling admission to the conference. Sets up the meeting, adds and shares contents, control who presents, talks. • Participant – Indicates a participant in the conference who does not have any special control. Receives media and content from presenter. If it only applies to switched captures doesn't this imply that only an MCU could label a capture with these conference roles? > Also, the Role=Controller would apply to an Endpoint, not a Media > Capture, is that correct? Or would it apply to every Media Capture > that is sent from the Endpoint that is the current Controller? If so, > then the endpoint would have to change its advertisement when its > Controller status changes? That doesn’t make sense to me. > [CNG] According to my definition above, I don't think this information would change often. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Apr 30 18:53:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0421F8766 for ; Tue, 30 Apr 2013 18:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4tm5iJKlthW for ; Tue, 30 Apr 2013 18:53:36 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 45B8421F882A for ; Tue, 30 Apr 2013 18:53:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAOB0gFF20dxV/2dsb2JhbAANRYM9vwyBFYMTAQEBAwEBAQE1GxsKEQsYCRYPCQMCAQIBFTATBgIBAYgCEq0pkgUEjmY6FoM6A6oogUo Received: from ppp118-209-220-85.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.220.85]) by ipmail04.adl6.internode.on.net with ESMTP; 01 May 2013 11:23:10 +0930 Message-ID: <51807583.1010501@nteczone.com> Date: Wed, 01 May 2013 11:53:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> <517FF52C.204@alum.mit.edu> In-Reply-To: <517FF52C.204@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 01:53:37 -0000 On 1/05/2013 2:45 AM, Paul Kyzivat wrote: > On 4/30/13 9:06 AM, Duckworth, Mark wrote: >> This is a follow up to an action item from IETF-86. I said I would >> propose text based on the discussion to allow a Media Provider to >> represent Simultaneous Transmission Sets in terms of Capture Scenes and >> Capture Scene Entries. Currently the framework says a Simultaneous >> Transmission Set is a set of Media Captures of a particular media type. >> >> === begin proposed new paragraph to add near end of section 6.3 === >> >> For shorthand convenience, a Provider may describe a Simultaneous >> Transmission Set in terms of Capture Scene Entries and Capture Scenes. >> If a Capture Scene Entry is included in a Simultaneous Transmission Set, >> then all Media Captures in the Capture Scene Entry are included in the >> Simultaneous Transmission Set. 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. The end result reduces to a set of Media Captures in >> any case. >> >> === end proposed new paragraph to add near end of section 6.3 === > > I see one issue with the above. AFAIK the only way one knows the media > type of a Simultaneous Transmission Set is by observing the type of > the captures it contains. In the above, if a STS contained *only* > Capture Scenes, then there would be no way to decide what type it was. > > (Of course this wouldn't be a problem is STSs contained all types.) [CNG] Yes I agree that this is an issue. > >> I suggest we do not make this change, and instead just describe a >> Simultaneous Transmission Set as a set of Media Captures. I think >> allowing the additional ways to represent the set adds complication >> without adding value. A Media Consumer that wants to use simultaneous >> sets would have more work to do to parse out the contents of the set. >> >> Your thoughts? [CNG] In some respects not having the CS, CSE in an STS mirrors a configure response in that it only lists captures. However there appears to be a problem with a configure when having to return CSE parameters. If a consumer can "choose" attribute values what it mean for STSs? Does the value setting have an effect on what media capture combination can be supported in a capture? > > I haven't got strong feelings pro or con. But not making the change > means one doesn't have to solve the above problem. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Apr 30 19:37:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65D21F89D8 for ; Tue, 30 Apr 2013 19:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEvCJJ4B6Nfc for ; Tue, 30 Apr 2013 19:37:35 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9163721F8782 for ; Tue, 30 Apr 2013 19:37:35 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 30 Apr 2013 19:37:34 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 30 Apr 2013 19:37:32 -0700 Thread-Topic: [clue] usage of Conference Roles - valid only with switched captures? Thread-Index: Ac5GDcpAe1WN/b1pQyW0iNsIlVAhfgABhMjw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D677AEB5@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> <51807349.9080906@nteczone.com> In-Reply-To: <51807349.9080906@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [clue] usage of Conference Roles - valid only with switched captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 02:37:41 -0000 SGkgQ2hyaXN0aWFuLA0KVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb25zLCBidXQgSSBzdGlsbCBk b24ndCB1bmRlcnN0YW5kIGFib3V0IGhvdyBpdCB3b3VsZCB3b3JrIHdpdGggcm9sZXMgdGhhdCBj aGFuZ2Ugb2Z0ZW4uICBGb3IgZXhhbXBsZSwgdGhlIGN1cnJlbnQgc3BlYWtlci4gIEluIGNvbW1v biBjb25mZXJlbmNlIHNjZW5hcmlvcywgdGhlIGN1cnJlbnQgc3BlYWtlciBjYW4gY2hhbmdlIGV2 ZXJ5IGZldyBzZWNvbmRzLiAgSSB0aGluayB3ZSBkb24ndCB3YW50IHRvIGJlIGRvaW5nIG5ldyBh ZHZlcnRpc2VtZW50cyB0aGF0IGNoYW5nZSB0aGUgdmFsdWUgb2Ygcm9sZSBhdHRyaWJ1dGVzIGZv ciByb2xlPXNwZWFrZXIgKG9yIHJvbGUgbm90IGVxdWFsIHNwZWFrZXIpIGV2ZXJ5IGZldyBzZWNv bmRzLg0KDQpUaGUgZHJhZnQgc2F5czoNCglTcGVha2VyIC0gaW5kaWNhdGVzIHRoYXQgdGhlIGNh cHR1cmUgcmVsYXRlcyB0byB0aGUgY3VycmVudCBzcGVha2VyLg0KDQpNeSBpbnRlcnByZXRhdGlv biBvZiAiY3VycmVudCBzcGVha2VyIiBpcyBhIGR5bmFtaWMgY2hvaWNlLCB1c3VhbGx5IG1hZGUg YnkgYW4gTUNVLCBiYXNlZCBvbiBhdWRpbyBlbmVyZ3kgb3Igc2ltaWxhciBtZXRyaWMsIG9mIHdo aWNoIGF1ZGlvIHN0cmVhbSAoYW5kIG90aGVyIGFzc29jaWF0ZWQgbWVkaWEgc3RyZWFtcykgcmVw cmVzZW50cyB0aGUgY3VycmVudCBzcGVha2VyLiAgQW5kIGl0IGNhbiBlYXNpbHkgY2hhbmdlIGV2 ZXJ5IGZldyBzZWNvbmRzLiAgSXMgdGhpcyB3aGF0IHlvdSBtZWFuIGJ5ICJjdXJyZW50IHNwZWFr ZXIiPw0KDQpNYXJrDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1 ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YNCj4gQ2hyaXN0aWFuIEdyb3Zlcw0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAzMCwgMjAx MyA5OjQ0IFBNDQo+IFRvOiBjbHVlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gdXNh Z2Ugb2YgQ29uZmVyZW5jZSBSb2xlcyAtIHZhbGlkIG9ubHkgd2l0aCBzd2l0Y2hlZA0KPiBjYXB0 dXJlcz8NCj4gDQo+IEhlbGxvIE1hcmssDQo+IA0KPiBJJ20gaW4gdGhlIHByb2Nlc3Mgb2YgZmlu aXNoaW5nIGEgZHJhZnQgdGhhdCBkaXNjdXNzZXMgInJvbGUiIGluIHNvbWUgbW9yZQ0KPiBkZXRh aWwuIEJhc2ljYWxseSB0aGUgcHJlbWlzZSBpcyB0aGF0IHRoZSBjdXJyZW50IHNldCBvZiByb2xl cyBzZW1hbnRpY2FsbHkNCj4gc2hvdWxkIGJlIHNlcGFyYXRlZC4gQWZ0ZXIgdGhlIGRpc2N1c3Np b25zIG9uIHRoZSBkaXNwYXRjaCBsaXN0IGl0IGJlY29tZQ0KPiBhcHBhcmVudCB0aGF0IHBlb3Bs ZSBzZWVzICJyb2xlIiBmb3IgZGlmZmVyZW50IHNlbWFudGljcywgaS5lLiB0aGVyZSBhcmUNCj4g ZGlmZmVyZW50IGNhdGVnb3JpZXMgb2Ygcm9sZXMuDQo+IGUuZy4NCj4gKiBNZWV0aW5nIFJvbGVz IC0gVGhlc2Ugcm9sZXMgcmVsYXRlIHRvIHR5cGljYWwgdHJhZGl0aW9uYWwgZnVuY3Rpb25zIHdo ZW4gYQ0KPiBtZWV0aW5nIGlzIGhlbGQsIGNoYWlybWFuLCBzZWNyZXRhcnksIGV0Yy4NCj4gKiBD b25mZXJlbmNlIHJvbGVzIC0gVGhlc2Ugcm9sZXMgYXJlIHJlbGF0ZWQgdG8gdGhlIGVzdGFibGlz aG1lbnQgYW5kDQo+IG1haW50ZW5hbmNlIG9mIHRoZSBtdWx0aW1lZGlhIGNvbmZlcmVuY2UgYW5k IGFyZSByZWxhdGVkIHRvIHRoZSBzY29wZSBvZg0KPiB0aGUgY29uZmVyZW5jZSBzeXN0ZW0gb25s eSwgc3BlYWtlciwgY29udHJvbGxlciwgcGFydGljaXBhbnQgZXRjLg0KPiAqIFBlcnNvbiBuYW1l IHRpdGxlIC0gVGhlc2UgYXJlIHJvbGVzICh0aXRsZXMpIGdpdmVuIHRvIGEgcGVyc29uIGRlcGlj dGVkIGJ5IHRoZQ0KPiBtZWRpYSBjYXB0dXJlIGUuZy4gRG9jdG9yLCBQcm9mZXNzb3IuDQo+ICog T2NjdXBhdGlvbmFsIHJvbGUgLSBUaGVzZSBhcmUgcm9sZXMgZ2l2ZW4gdG8gcGVvcGxlIGluIGFu IG9yZ2FuaXNhdGlvbiBlLmcuDQo+IENFTywgTUQsIFZQIGV0Yy4gQWdhaW4gdGhlc2Ugd291bGQg YmUgdGhlIHBlcnNvbnMgZGVwaWN0ZWQgaW4gdGhlIG1lZGlhDQo+IGNhcHR1cmUuDQo+ICogTWVl dGluZyBTcGVjaWZpYyByb2xlIC0gU29tZSBncm91cHMgbWF5IHdhbnQgdG8gYXNzaWduIHRoZWly IG93biByb2xlIHRoYXQNCj4gaGFzIG1lYW5pbmcgdG8gdGhlIHBhcnRpY2lwYW50cyBpbiBhIHBh cnRpY3VsYXIgY29uZmVyZW5jZS4NCj4gDQo+IFRoZXkgYWxsIGNvdWxkIGJlIGNvbnNpZGVyZWQg YXMgaGF2aW5nIHNvbWUgcm9sZSBpbiBhIGNvbmZlcmVuY2UgYW5kIGENCj4gbWVkaWEgY2FwdHVy ZSBjb3VsZCBiZSBhc3NpZ25lZCBtdWx0aXBsZSBvbmVzLg0KPiANCj4gUmVnYXJkcywgQ2hyaXN0 aWFuDQo+IA0KPiBPbiAxLzA1LzIwMTMgODoxNiBBTSwgRHVja3dvcnRoLCBNYXJrIHdyb3RlOg0K PiA+DQo+ID4gUXVlc3Rpb24gYWJvdXQgc2VjdGlvbiA0LjQuMiBDb25mZXJlbmNlIFJvbGVzIGZy b20NCj4gPiBkcmFmdC1ncm92ZXMtY2x1ZS1jYXB0dXJlLWF0dHItMDEuIFRoZSBpbml0aWFsIHNl dCBvZiByb2xlcyBoZXJlIGlzDQo+ID4gU3BlYWtlciBhbmQgQ29udHJvbGxlciwgYm90aCBvZiB3 aGljaCBhcmUgZXhwZWN0ZWQgdG8gYXBwbHkgdG8NCj4gPiBkaWZmZXJlbnQgRW5kcG9pbnRzIChv ciBNZWRpYSBDYXB0dXJlIG9yaWdpbmF0aW5nIGZyb20gYW4gRW5kcG9pbnQpIGF0DQo+ID4gZGlm ZmVyZW50IHRpbWVzLiBHaXZlbiB0aGF0LCBpcyB0aGUgaW50ZW50IHRoYXQgdGhlc2Ugcm9sZXMg c2hvdWxkIGJlDQo+ID4gYXBwbGllZCBvbmx5IHRvIE1lZGlhIENhcHR1cmVzIHdoaWNoIGhhdmUg dGhlIGF0dHJpYnV0ZSBzd2l0Y2hlZD10cnVlPw0KPiA+IFdlIGRvbuKAmXQgd2FudCBhIFByb3Zp ZGVyIHRvIHNlbmQgYSBuZXcgYWR2ZXJ0aXNlbWVudCBldmVyeSB0aW1lIHRoZQ0KPiA+IGN1cnJl bnQgc3BlYWtlciBpbiBhIGNvbmZlcmVuY2UgY2hhbmdlcywgZG8gd2U/IEl0IHdvdWxkIG1ha2Ug c2Vuc2UgdG8NCj4gPiBtZSBmb3IgYSBtaWRkbGVib3ggdG8gdXNlIHRoaXMgdHlwZSBvZiBhdHRy aWJ1dGUgZm9yIGEgc3dpdGNoZWQNCj4gPiBjYXB0dXJlLCBvciBldmVuIGFuIEVuZHBvaW50IGNv dWxkIHVzZSBpdCBpZiBpdCBzd2l0Y2hlcyBiZXR3ZWVuDQo+ID4gZGlmZmVyZW50IGxvY2FsIGNh cHR1cmVzLg0KPiA+DQo+IFtDTkddIE15IGRlZmluaXRpb25zIGZvciBTcGVha2VyIC8gQ29udHJv bGxlciAvIFBhcnRpY2lwYW50IHdvdWxkIGJlOg0KPiDigKIgU3BlYWtlciAvIFByZXNlbnRlciDi gJMgQ2FuIHNoYXJlIGNvbnRlbnQvbWVkaWEgd2l0aCBvdGhlcnMuDQo+IOKAoiBDb250cm9sbGVy IC8gSG9zdCDigJMgSW5kaWNhdGVzIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGNvbnRyb2xs aW5nDQo+IGFkbWlzc2lvbiB0byB0aGUgY29uZmVyZW5jZS4gU2V0cyB1cCB0aGUgbWVldGluZywg YWRkcyBhbmQgc2hhcmVzIGNvbnRlbnRzLA0KPiBjb250cm9sIHdobyBwcmVzZW50cywgdGFsa3Mu DQo+IOKAoiBQYXJ0aWNpcGFudCDigJMgSW5kaWNhdGVzIGEgcGFydGljaXBhbnQgaW4gdGhlIGNv bmZlcmVuY2Ugd2hvIGRvZXMgbm90IGhhdmUNCj4gYW55IHNwZWNpYWwgY29udHJvbC4gUmVjZWl2 ZXMgbWVkaWEgYW5kIGNvbnRlbnQgZnJvbSBwcmVzZW50ZXIuDQo+IA0KPiBJZiBpdCBvbmx5IGFw cGxpZXMgdG8gc3dpdGNoZWQgY2FwdHVyZXMgZG9lc24ndCB0aGlzIGltcGx5IHRoYXQgb25seSBh biBNQ1UNCj4gY291bGQgbGFiZWwgYSBjYXB0dXJlIHdpdGggdGhlc2UgY29uZmVyZW5jZSByb2xl cz8NCj4gDQo+ID4gQWxzbywgdGhlIFJvbGU9Q29udHJvbGxlciB3b3VsZCBhcHBseSB0byBhbiBF bmRwb2ludCwgbm90IGEgTWVkaWENCj4gPiBDYXB0dXJlLCBpcyB0aGF0IGNvcnJlY3Q/IE9yIHdv dWxkIGl0IGFwcGx5IHRvIGV2ZXJ5IE1lZGlhIENhcHR1cmUNCj4gPiB0aGF0IGlzIHNlbnQgZnJv bSB0aGUgRW5kcG9pbnQgdGhhdCBpcyB0aGUgY3VycmVudCBDb250cm9sbGVyPyBJZiBzbywNCj4g PiB0aGVuIHRoZSBlbmRwb2ludCB3b3VsZCBoYXZlIHRvIGNoYW5nZSBpdHMgYWR2ZXJ0aXNlbWVu dCB3aGVuIGl0cw0KPiA+IENvbnRyb2xsZXIgc3RhdHVzIGNoYW5nZXM/IFRoYXQgZG9lc27igJl0 IG1ha2Ugc2Vuc2UgdG8gbWUuDQo+ID4NCj4gW0NOR10gQWNjb3JkaW5nIHRvIG15IGRlZmluaXRp b24gYWJvdmUsIEkgZG9uJ3QgdGhpbmsgdGhpcyBpbmZvcm1hdGlvbiB3b3VsZA0KPiBjaGFuZ2Ug b2Z0ZW4uDQo+ID4NCj4gPiBNYXJrDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBjbHVlIG1haWxpbmcgbGlzdA0K PiA+IGNsdWVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NsdWUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From Mark.Duckworth@polycom.com Tue Apr 30 19:46:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73C21F8B60 for ; Tue, 30 Apr 2013 19:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pScoXQXvWonO for ; Tue, 30 Apr 2013 19:46:04 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 530C521F8B5F for ; Tue, 30 Apr 2013 19:46:04 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 30 Apr 2013 19:46:03 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 30 Apr 2013 19:46:02 -0700 Thread-Topic: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries Thread-Index: Ac5GDxCBsfn9QJfIRRqRp4dj8qJBFAABhIzQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D677AEB7@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> <517FF52C.204@alum.mit.edu> <51807583.1010501@nteczone.com> In-Reply-To: <51807583.1010501@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 Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 02:46:09 -0000 Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Tuesday, April 30, 2013 9:53 PM > To: clue@ietf.org > Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capt= ure > Scene Entries >=20 >=20 > On 1/05/2013 2:45 AM, Paul Kyzivat wrote: > > On 4/30/13 9:06 AM, Duckworth, Mark wrote: > >> This is a follow up to an action item from IETF-86. I said I would > >> propose text based on the discussion to allow a Media Provider to > >> represent Simultaneous Transmission Sets in terms of Capture Scenes > >> and Capture Scene Entries. Currently the framework says a > >> Simultaneous Transmission Set is a set of Media Captures of a particul= ar > media type. > >> > >> =3D=3D=3D begin proposed new paragraph to add near end of section 6.3 = =3D=3D=3D > >> > >> For shorthand convenience, a Provider may describe a Simultaneous > >> Transmission Set in terms of Capture Scene Entries and Capture Scenes. > >> If a Capture Scene Entry is included in a Simultaneous Transmission > >> Set, then all Media Captures in the Capture Scene Entry are included > >> in the Simultaneous Transmission Set. 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. The end result reduces to a set of > >> Media Captures in any case. > >> > >> =3D=3D=3D end proposed new paragraph to add near end of section 6.3 = =3D=3D=3D > > > > I see one issue with the above. AFAIK the only way one knows the media > > type of a Simultaneous Transmission Set is by observing the type of > > the captures it contains. In the above, if a STS contained *only* > > Capture Scenes, then there would be no way to decide what type it was. > > > > (Of course this wouldn't be a problem is STSs contained all types.) > [CNG] Yes I agree that this is an issue. [Duckworth, Mark] I think this issue is very easy to solve in the data mode= l by including a media type parameter with the Simultaneous Transmission Se= t. But still, I'm in favor of keeping it simple and not adding that new pa= ragraph. > >> I suggest we do not make this change, and instead just describe a > >> Simultaneous Transmission Set as a set of Media Captures. I think > >> allowing the additional ways to represent the set adds complication > >> without adding value. A Media Consumer that wants to use > >> simultaneous sets would have more work to do to parse out the contents > of the set. > >> > >> Your thoughts? > [CNG] In some respects not having the CS, CSE in an STS mirrors a configu= re > response in that it only lists captures. However there appears to be a > problem with a configure when having to return CSE parameters. > If a consumer can "choose" attribute values what it mean for STSs? Does t= he > value setting have an effect on what media capture combination can be > supported in a capture? [Duckworth, Mark] I don't understand the question. What do you mean by "wh= at media capture combination can be supported in a capture"? I'll look for= the Capture Scene Entry attribute question and respond separately, I don't= see how it is related to this thread. > > I haven't got strong feelings pro or con. But not making the change > > means one doesn't have to solve the above problem. > > > > Thanks, > > Paul From Christian.Groves@nteczone.com Tue Apr 30 19:49:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF8621F8763 for ; Tue, 30 Apr 2013 19:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW3qtDYqB0To for ; Tue, 30 Apr 2013 19:49:13 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 957E621F8759 for ; Tue, 30 Apr 2013 19:49:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBAFSCgFF20dxV/2dsb2JhbAANRYM9gze7WoEVgxMBAQEEAQEBIA8BBRsVBgoBDAQLEQQBAQECAgUWCAMCAgkDAgECARUfCQgGDQEFAgEBiBStKHKRDwSBI412BwaCN4ETA6ty Received: from ppp118-209-220-85.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.220.85]) by ipmail04.adl6.internode.on.net with ESMTP; 01 May 2013 12:18:40 +0930 Message-ID: <51808283.2070101@nteczone.com> Date: Wed, 01 May 2013 12:48:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Duckworth, Mark" References: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> <51807349.9080906@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D677AEB5@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D677AEB5@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] usage of Conference Roles - valid only with switched captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 02:49:13 -0000 Hello Mark, I see it as a two step process. The attributes (including role) are used to choose the initial set of media captures and the media is then established. Any highly dynamic changes in attributes associated with established media such as changes to who is currently speaking is best handled by media path associated indications (i.e. BFCP). The text from the draft does need updating that's why I'm working on a new draft about roles. I guess the CLUE role "speaker" would denote Speaker/Presentor as the person presenting material. The "current speaker" determined by audio energy etc would be handled by BFCP (or similar). Regards, Christian On 1/05/2013 12:37 PM, Duckworth, Mark wrote: > Hi Christian, > Thanks for the explanations, but I still don't understand about how it would work with roles that change often. For example, the current speaker. In common conference scenarios, the current speaker can change every few seconds. I think we don't want to be doing new advertisements that change the value of role attributes for role=speaker (or role not equal speaker) every few seconds. > > The draft says: > Speaker - indicates that the capture relates to the current speaker. > > My interpretation of "current speaker" is a dynamic choice, usually made by an MCU, based on audio energy or similar metric, of which audio stream (and other associated media streams) represents the current speaker. And it can easily change every few seconds. Is this what you mean by "current speaker"? > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Tuesday, April 30, 2013 9:44 PM >> To: clue@ietf.org >> Subject: Re: [clue] usage of Conference Roles - valid only with switched >> captures? >> >> Hello Mark, >> >> I'm in the process of finishing a draft that discusses "role" in some more >> detail. Basically the premise is that the current set of roles semantically >> should be separated. After the discussions on the dispatch list it become >> apparent that people sees "role" for different semantics, i.e. there are >> different categories of roles. >> e.g. >> * Meeting Roles - These roles relate to typical traditional functions when a >> meeting is held, chairman, secretary, etc. >> * Conference roles - These roles are related to the establishment and >> maintenance of the multimedia conference and are related to the scope of >> the conference system only, speaker, controller, participant etc. >> * Person name title - These are roles (titles) given to a person depicted by the >> media capture e.g. Doctor, Professor. >> * Occupational role - These are roles given to people in an organisation e.g. >> CEO, MD, VP etc. Again these would be the persons depicted in the media >> capture. >> * Meeting Specific role - Some groups may want to assign their own role that >> has meaning to the participants in a particular conference. >> >> They all could be considered as having some role in a conference and a >> media capture could be assigned multiple ones. >> >> Regards, Christian >> >> On 1/05/2013 8:16 AM, Duckworth, Mark wrote: >>> Question about section 4.4.2 Conference Roles from >>> draft-groves-clue-capture-attr-01. The initial set of roles here is >>> Speaker and Controller, both of which are expected to apply to >>> different Endpoints (or Media Capture originating from an Endpoint) at >>> different times. Given that, is the intent that these roles should be >>> applied only to Media Captures which have the attribute switched=true? >>> We don’t want a Provider to send a new advertisement every time the >>> current speaker in a conference changes, do we? It would make sense to >>> me for a middlebox to use this type of attribute for a switched >>> capture, or even an Endpoint could use it if it switches between >>> different local captures. >>> >> [CNG] My definitions for Speaker / Controller / Participant would be: >> • Speaker / Presenter – Can share content/media with others. >> • Controller / Host – Indicates the person responsible for controlling >> admission to the conference. Sets up the meeting, adds and shares contents, >> control who presents, talks. >> • Participant – Indicates a participant in the conference who does not have >> any special control. Receives media and content from presenter. >> >> If it only applies to switched captures doesn't this imply that only an MCU >> could label a capture with these conference roles? >> >>> Also, the Role=Controller would apply to an Endpoint, not a Media >>> Capture, is that correct? Or would it apply to every Media Capture >>> that is sent from the Endpoint that is the current Controller? If so, >>> then the endpoint would have to change its advertisement when its >>> Controller status changes? That doesn’t make sense to me. >>> >> [CNG] According to my definition above, I don't think this information would >> change often. >>> 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