Re: [clue] Participant info/type followup

Christian Groves <Christian.Groves@nteczone.com> Tue, 01 April 2014 23:13 UTC

Return-Path: <Christian.Groves@nteczone.com>
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 B14391A0009 for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 16:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdGlAHSe75tb for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 16:13:13 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9393B1A0004 for <clue@ietf.org>; Tue, 1 Apr 2014 16:13:12 -0700 (PDT)
Received: from ppp118-209-153-126.lns20.mel6.internode.on.net ([118.209.153.126]:51479 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1WV7rc-0001OU-Pm; Wed, 02 Apr 2014 10:13:04 +1100
Message-ID: <533B47FF.5020407@nteczone.com>
Date: Wed, 02 Apr 2014 10:13:03 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Roberta Presta <roberta.presta@unina.it>, "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> <533A91BF.7040404@unina.it>
In-Reply-To: <533A91BF.7040404@unina.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JPDVI21dnNgHKUiO0ei7UFv2YZQ
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 23:13:16 -0000

Hello Roberta,

 From a data model perspective I agree that it makes sense to have the 
participant metadata "referenced" to minimize duplication in the 
messages. So I support your solution in the data model to the redundancy 
problem.

In general I think its good to maintain consistency between the 
framework and the data model. However in London I thought this was more 
of a syntax shortcut (like the captureID wildcarding) rather than 
something we'd need to formalize in the framework. I guess we could add 
it at a higher level in the framework (it would functionally be the same 
thing), it would just be more work for the editor...

I could go either way on this.

Regards, Christian

On 1/04/2014 9:15 PM, Roberta Presta wrote:
> 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
>>
>
>