Subject: [clue] Homework - "test" of CLUE

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jun 2014 12:23:47 -0400

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

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

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

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

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

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

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

Who would be willing to participate in such an exercise?

	Thanks,
	Paul

---

From: Roberta Presta <[email-masked]>
Date: Tue, 24 Jun 2014 13:14:57 +0200

Dear all,

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

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

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

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

Regards,

Roberta

Il 20/06/2014 18:23, Paul Kyzivat ha scritto:
> During a past design team call I proposed a homework task that I 
> thought would be very helpful. The idea was well received, but nothing 
> has happened. So I'll spell it out in more detail:
>
> from an interoperability perspective. Specifically, I propose that, as 
> a first step, everybody who can represent a possible implementation of 
> CLUE should write down a proposed advertisement for each of their 
> likely device configurations, and share that with the group. (E.g., if 
> you have a one-screen system and a three-screen system, then provide 
> an advertisement for each.)
>
> The next step would be for each person to look at all the 
> advertisements other than their own, and decide if they can make sense 
> of each and make a good choice of what to configure, and how they 
> would render that on their device(s).
>
> would configure and then what they would advertise as a result. And 
> then people to review those advertisements as well.
>
> (Ideally there will be no surprises here. But what I *expect* to 
> happen here is that people will be surprised to find things they don't 
> clarify these would follow, and perhaps lead to some clarifications 
> and maybe fixes.)
>
> This exercise is a bit like doing call flows, but the level of detail 
> is different. Initially I think we only need the advertisements, and 
> the corresponding SDP that contains the encodings. The advertisements 
> could be encoded according to the message syntax in the protocol 
> document, but for simplicity I think people can take liberties and use 
> informal shorthand, as long as they include all the pieces.
>
> do the collation.) Or we could do this on the CLUE Wiki. (The Wiki 
> might be easier.) Your thoughts on this are welcome.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 21:46:52 +1000

Hello Roberta, all,

I have a few questions regarding the protocol draft:

1. General: Response String: In several messages the response string is 
listed as mandatory. If we have the response code why do we also need to 
send the string?

2. Clause 4.5: Do we still have a strong requirement to have ACK 
piggybacking in a CONFIGURE message?

3. Clause 4.8: The text indicates that the READV response contains the 
CLUE data. Would an alternative be to simply trigger the sending of an 
ADV with the CLUE data? That way we keep CLUE data in ADV and CONF only. 
The READV then only needs a simple ACK.

I've also sent off list a number of editorial suggestions.

Regards, Christian

On 24/06/2014 9:14 PM, Roberta Presta wrote:
>     [I‑D.ietf‑clue‑data‑model‑schema]
>> thought would be very helpful. The idea was well received, but 
>> nothing has happened. So I'll spell it out in more detail:
>>
>> from an interoperability perspective. Specifically, I propose that, 
>> as a first step, everybody who can represent a possible 
>> implementation of CLUE should write down a proposed advertisement for 
>> each of their likely device configurations, and share that with the 
>> group. (E.g., if you have a one-screen system and a three-screen 
>> system, then provide an advertisement for each.)
>>
>> advertisements other than their own, and decide if they can make 
>> sense of each and make a good choice of what to configure, and how 
>> they would render that on their device(s).
>>
>> combinations of endpoints and ask people with MCUs to decide what 
>> they would configure and then what they would advertise as a result. 
>> And then people to review those advertisements as well.
>>
>> happen here is that people will be surprised to find things they 
>> don't understand and/or can't deal with in any useful way. 
>> Discussions to clarify these would follow, and perhaps lead to some 
>> clarifications and maybe fixes.)
>>
>> document, but for simplicity I think people can take liberties and 
>> use informal shorthand, as long as they include all the pieces.
>>
>> email and then collate them into an individual draft. (I am willing 
>> to do the collation.) Or we could do this on the CLUE Wiki. (The Wiki 
> DELL'UNIVERSITA' DI NAPOLI

---

From: Roberta Presta <[email-masked]>
Date: Tue, 24 Jun 2014 13:57:01 +0200

Hello Christian,

thank you for the review(s!), I'm going through it.
While I was making the ADV XML samples, I noticed something needed to be 
changed in the protocol schema as a consequence of the changes in the 
data model schema (element names), so I preferred to post a new protocol 
draft version and to provide examples that are compliant with the 
updated protocol schema.
I will reply to your review asap.
Regards,

Roberta

Il 24/06/2014 13:39, Christian Groves ha scritto:
> Hello Roberta,
>
> I just finished reviewing v0 when you posted v1 of the protocol. I 
> have a few editorial update suggestions which I've marked up in the 
> attached word document. I thought it would be easier to send a marked 
> up form rather than trying to explain them via email. There's also a 
> few word comments which I can raise on the mailing list. They're 
> against the v0 version but I think most of them are valid for v1.
>
> Regards, Christian
>
>> The ADV examples that we have included in the protocol draft 
>> represent the situations described in Section 22 and 23 of the data 
>> model draft.
>>> The idea is to do a "test run" of the key aspects of clue, 
>>> especially from an interoperability perspective. Specifically, I 
>>> propose that, as a first step, everybody who can represent a 
>>> possible implementation of CLUE should write down a proposed 
>>> advertisement for each of their likely device configurations, and 
>>> share that with the group. (E.g., if you have a one-screen system 
>>> and a three-screen system, then provide an advertisement for each.)
>>>
>>> This exercise is a bit like doing call flows, but the level of 
>>> detail is different. Initially I think we only need the 
>>> advertisements, and the corresponding SDP that contains the 
>>> encodings. The advertisements could be encoded according to the 
>>> message syntax in the protocol document, but for simplicity I think 
>>> people can take liberties and use informal shorthand, as long as 
>>> they include all the pieces.
>>>
>>> to do the collation.) Or we could do this on the CLUE Wiki. (The 
>>> Wiki might be easier.) Your thoughts on this are welcome.
>>>

----

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 24 Jun 2014 06:00:40 -0700

Hi Paul,

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

Mark

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

Dear all,

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

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

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

Regards,

Roberta

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

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

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

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

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

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

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

    Thanks,
    Paul

---

From: Robert Hansen <[email-masked]>
Date: Tue, 24 Jun 2014 14:04:53 +0100

I'm in too - did we come up with a good place to put them?

Rob

On 24/06/14 14:00, Duckworth, Mark wrote:
>
> Hi Paul,
>
> I'd like to participate also.  I'll try to put together an 
> Advertisement and post it before IETF90.  I will also look through 
> Simon and Roberta's Advertisements.
>
> Mark
>
> *From:*clue [mailto:[email-masked]] *On Behalf Of *Roberta Presta
> *Sent:* Tuesday, June 24, 2014 7:15 AM
> *To:* [email-masked]
> *Subject:* Re: [clue] Homework - "test" of CLUE
>
> Dear all,
>
>     Yet another step will be to extend the above to MCUs. We could
>     pick combinations of endpoints and ask people with MCUs to decide
>     what they would configure and then what they would advertise as a
>     result. And then people to review those advertisements as well.
>
>     Discussions to clarify these would follow, and perhaps lead to
>     some clarifications and maybe fixes.)
>
>     message syntax in the protocol document, but for simplicity I
>     think people can take liberties and use informal shorthand, as
>     long as they include all the pieces.
>
>     This is extra work for everybody, so I'd like to make it as easy
>     as possible. One possibility is for people to submit contributions
>     via email and then collate them into an individual draft. (I am
>     willing to do the collation.) Or we could do this on the CLUE
>     Wiki. (The Wiki might be easier.) Your thoughts on this are welcome.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2014 10:46:02 -0400

> I'm in too - did we come up with a good place to put them?

Not yet. I'm inclined to prefer adding a page for the purpose to our 
clue wiki. Does that work for people?

	Thanks,
	Paul

>> I’d like to participate also.  I’ll try to put together an
>> Simon and Roberta’s Advertisements.
>>
>> Mark
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 24 Jun 2014 08:23:19 -0700

I think the clue wiki is a good idea.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, June 24, 2014 10:46 AM
> To: [email-masked]
> Not yet. I'm inclined to prefer adding a page for the purpose to our clue wiki.
> Does that work for people?
> 
> 	Thanks,
> 	Paul
> 
> > Rob
> >
> >>     <globalCaptureEntries> --> <globalSceneEntries>)  2. Text has
> >> been added to clarify that, in the OPTIONS RESPONSE, when

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2014 18:45:59 -0400

> I think the clue wiki is a good idea.

OK. I created another wiki page for this purpose subordinate to the main 
clue wiki page. You will fine a reference to it under the heading 
"Repository of Sample Advertisements", or you can go directly to:
http://trac.tools.ietf.org/wg/clue/trac/wiki/SampleAdvertisements.

The page isn't populated with anything real yet. Feel free to go at it!

	Thanks,
	Paul