Re: [clue] Participant info/type followup

Roberta Presta <roberta.presta@unina.it> Tue, 01 April 2014 10:15 UTC

Return-Path: <roberta.presta@unina.it>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D351A7032 for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 03:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.031
X-Spam-Level:
X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3gjeMITAKN3 for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 03:15:33 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5D1A702B for <clue@ietf.org>; Tue, 1 Apr 2014 03:15:33 -0700 (PDT)
Received: from [127.0.0.1] ([143.225.229.123]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s31AFRIe024592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 12:15:28 +0200
Message-ID: <533A91BF.7040404@unina.it>
Date: Tue, 01 Apr 2014 12:15:27 +0200
From: Roberta Presta <roberta.presta@unina.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@nteczone.com>, "clue@ietf.org" <clue@ietf.org>
References: <5318809E.2030204@nteczone.com> <5318AE5E.4050404@alum.mit.edu> <5318B0C9.1050603@nteczone.com> <5318B48E.3090300@alum.mit.edu> <53290C9B.6090106@nteczone.com> <5329F3FF.7090606@alum.mit.edu> <533A16BA.40707@nteczone.com>
In-Reply-To: <533A16BA.40707@nteczone.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DOm9A8rVI2yZc2fwcYZugYe9hrU
Subject: Re: [clue] Participant info/type followup
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 10:15:36 -0000

Hi Christian,

In section 7.1.1.X we are dealing with media capture attributes and in 
section 7.1.1.11 we want to define an attribute conveying information 
about participants.
I would say that here we can find both information (*references*, in the 
data model) about "who is represented in the capture" ("captured 
participants"?) and "who is the owner of the generating device" ("owner"?).

Maybe participant metadata, such as Participant Information and 
Participant Type as they are currently defined, should be treated in a 
separate section of the same level of capture scenes or media captures as.
Indeed we showed in London that repeating the vcard and the role of the 
participants in each capture, as if they were capture attributes,  
causes redundancy.

I know that I have a data model definition perspective, but I would 
propose to make a change that is more coherent with what we will 
describe formally.

Cheers,

Roberta





Il 01/04/2014 03:30, Christian Groves ha scritto:
> Hello Paul, all,
>
> If we follow the approach that there is a specific indicating of 
> whether the participant information is based on an explicit indication 
> then I would suggest the following text for the framework:
>
> Clause 7.1.11 Participant information
> (Under the 1st paragraph)
>
> The participant information contains an explicit indication of whether 
> it relates to a participant contained in the capture, from a 
> participants capture device or both. For example a video camera may 
> capture an image containing the participant, or a participant may send 
> a video capture with a presentation that does not depict the participant.
>
> Something similar would be needed under participant type.
>
> Thoughts?
>
> Regards, Christian
>
> On 20/03/2014 6:46 AM, Paul Kyzivat wrote:
>> On 3/18/14 11:18 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> "How" they differ is given by the example bullets below the 
>>> sentence. If
>>> you want something more normative we could remove the "For example".
>>
>> Yeah, I don't believe in specification by example. :-)
>>
>> IMO it is a bit dicey to base this distinction on the type of capture.
>>
>> I'm more comfortable with an explicit syntactic indication of the 
>> distinction, such as proposed by Roberta.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards, Christian
>>>
>>> On 7/03/2014 4:46 AM, Paul Kyzivat wrote:
>>>> On 3/6/14 5:30 PM, Christian Groves wrote:
>>>>> Hello Paul,
>>>>>
>>>>> The text says media type and presentation attribute. Is that the
>>>>> relationship you're talking about?
>>>>
>>>> "How the generated content relates to the entity described in the
>>>> participant info is dependent on media type and and the presentation
>>>> attribute."
>>>>
>>>> I take that to mean that the relationship may be different for
>>>> presentation streams than non-presentation streams. But it doesn't say
>>>> *how* they differ.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 7/03/2014 4:20 AM, Paul Kyzivat wrote:
>>>>>> Christian,
>>>>>>
>>>>>> I've read the quoted text several times, and I cannot figure out how
>>>>>> to *derive* your example conclusions from it. The text says the
>>>>>> relationship is dependent on the presentation attribute, but not 
>>>>>> how.
>>>>>>
>>>>>> AFAICT I could make a new definition where the a participant 
>>>>>> attached
>>>>>> to a presentation capture means that the participant is shown in the
>>>>>> presentation, and that would be equally compatible with the text.
>>>>>>
>>>>>> ISTM that more text is required to actually specify the 
>>>>>> relationships.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> On 3/6/14 2:05 PM, Christian Groves wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> To follow up on Jonathon's comments on participant info/type and 
>>>>>>> the
>>>>>>> semantics and particularly how it relates to a presentation. 
>>>>>>> Here's a
>>>>>>> first stab at some text to stimulate some discussions.
>>>>>>>
>>>>>>>
>>>>>>> "The participant info attribute allows a provider to associate
>>>>>>> participant information with the capture source. When used in an
>>>>>>> individual capture it indicates that the captured content (e.g.
>>>>>>> video/audio/text etc.) as opposed to the actual media streams is
>>>>>>> generated from the entity described. How the generated content 
>>>>>>> relates
>>>>>>> to the entity described in the participant info is dependent on 
>>>>>>> media
>>>>>>> type and and the presentation attribute.
>>>>>>>
>>>>>>> For example:
>>>>>>> - a video capture with participant info would indicate that the 
>>>>>>> video
>>>>>>> contains a picture of the entity associated with the information
>>>>>>> provided.
>>>>>>> - a video capture with participant info and the presentation 
>>>>>>> attribute
>>>>>>> would indicate that the presentation video is associated with the
>>>>>>> participant but could contain any video content.
>>>>>>> - a text capture with participant info would indicate that the 
>>>>>>> text is
>>>>>>> generated from the actual participant.
>>>>>>> - a text capture with participant info and the presentation 
>>>>>>> attribute
>>>>>>> would indicate that the text is associated with the participant but
>>>>>>> could contain any text content."
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> clue mailing list
>>>>>>> clue@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> clue mailing list
>>>>>> clue@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>