Subject: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 8 Oct 2013 13:21:11 +0200

...here it is.

Simon

Inizio messaggio inoltrato:

> Da: [email-masked]
> Oggetto: New Version Notification for draft-presta-clue-protocol-02.txt
> Data: 08 ottobre 2013 13:20:31 GMT+02:00
> A: Roberta Presta <[email-masked]>, Simon Pietro Romano <[email-masked]>, Simon Romano <[email-masked]>
> 
> 
> A new version of I-D, draft-presta-clue-protocol-02.txt
> has been successfully submitted by Roberta Presta and posted to the
> IETF repository.
> 
> Filename:	 draft-presta-clue-protocol
> Revision:	 02
> Title:		 CLUE protocol
> Creation date:	 2013-10-08
> Group:		 Individual Submission
> Number of pages: 26
> URL:             http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-presta-clue-protocol
> Htmlized:        http://tools.ietf.org/html/draft-presta-clue-protocol-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-02
> 
> Abstract:
>   The CLUE protocol is an application protocol conceived for the
>   description and negotiation of a CLUE telepresence session.  The
>   design of the CLUE protocol takes into account the requirements and
>   the framework defined, respectively, in [I-D.ietf-clue-framework] and
>   [I-D.ietf-clue-telepresence-requirements].  The companion document
>   [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as
>   well as on the SIP/SDP session establishment phase.  We herein focus
>   on the application level perspective.  Message details, together with
>   the behavior of both the Media Provider and the Media Consumer are
>   discussed.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

                     					       _\\|//_
                           				      ( 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: [email-masked]

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 15:48:05 -0400

Roberta,

Thanks for this update. Its good to see progress.
Would you be willing to discuss it in the design team meeting next week?

A few comments...

Section 3:

This describes this as a client-server protocol, with the MC being the 
client and the MP being the server. But in reality we are usually in the 
situation where both ends have both an MC and MP role. And their 
messages are mixed on the same channel. I think it is necessary to 
address this as a single peer-to-peer protocol containing one or two 
nested client-server sub-protocols.

The p2p protocol can be just a mux/demux that sorts messages into one or 
the other of the sub-protocols. (I guess the rule is that ADV and 
RESPONSE are sent to the MC state machine, while RESPONSE, RE-ADV and 
OPTIONS are sent to the MP state machine.) And presumably channel 
failures, and ill-formed messages that can't be sorted to one of the 
sub-protocols need to be dealt with at this level. (And then they may 
affect the state of the sub-protocols.)

Alternatively, we *could* consider using two channels, each one being 
client-server.

Section 5:

What causes an MC to come into existence? Does every clue endpoint have 
one? Or is it optional. (E.g., a provider-only device.)

Conversely, is it an error to not get an Advertisement? Couldn't there 
be consumer-only devices?

Its certainly possible to make the protocol work with these being 
optional or required. But the details are different, so we need to choose.

The message has to be parsed (at least in part) in order to determine 
that it is an advertisement. ISTM most parse errors will occur then. So 
I think they show up in the missing state machine I talk about above re 
Section 3. I suppose there may be some (probably semantic) errors that 
are detected after knowing the message is an advertisement. Handling 
those would belong in this state machine.

I see that a CONF is required in response to an ADV. Is it your intent 
that this is to be sent soon (less than human response time)? Or is it 
your expectation that it is ok for this to be delayed long enough to 
allow human interaction and choice? (Which could be several minutes, or 
more.) I think this is an important distinction to make clear.

	Thanks,
	Paul

---

From: Roberta Presta <[email-masked]>
Date: Thu, 10 Oct 2013 13:03:51 +0200

Hi Paul,

I will prepare some slides for the next design team meeting to discuss 
the updates to the protocol draft.
Please see inline for further comments.

Il 09/10/2013 21:48, Paul Kyzivat ha scritto:
> client and the MP being the server. But in reality we are usually in 
> the situation where both ends have both an MC and MP role. And their 
> The p2p protocol can be just a mux/demux that sorts messages into one 
> or the other of the sub-protocols. (I guess the rule is that ADV and 
> OPTIONS are sent to the MP state machine.)
The demux rule should be:
- from the MC to the MP: OPTIONS, CONFIGURE, READV (only requests)
- from the MP to the MC: ADV, RESPONSE (only notifications and responses)
We have not considered yet the ack/nack mechanism needed to address the 
DTLS/SCTP channel issues.
> And presumably channel failures, and ill-formed messages that can't be 
> sorted to one of the sub-protocols need to be dealt with at this 
> level. (And then they may affect the state of the sub-protocols.)
>
> What causes an MC to come into existence? Does every clue endpoint 
> have one? Or is it optional. (E.g., a provider-only device.)
>
I see your point. A CLUE endpoint can surely be also provider-only or 
consumer-only.
We have considered that the peer-to-peer CLUE channel is created between 
at least an MC and an MP (since, otherwise, it is useless to set up it).
However, that presupposes that during the channel set up phase it is 
possible to understand when the involved parties are both consumer-(or 
provider-) only, and in that cases the channel should not be created.

If we remove that hypotesis that can lead us in trouble, we have still a 
way out with the current draft.
Indeed, when the channel is ready, it is the MC side that starts the 
CLUE dialogue with an OPTIONS request to align with the MP about the 
version and the extensions to be used within the session.
If both parties are provider-only, the current (only) way to detect that 
condition is that the channel is inactive for a time that fires N 
timeouts of the MP machine (no OPTIONS received).
On the other hand, the current (only) way to detect that both peers are 
consumer-only is that there is no answer to the OPTIONS request.
But alternatives can be considered.

> that it is an advertisement. ISTM most parse errors will occur then. 
> So I think they show up in the missing state machine I talk about 
> above re Section 3. I suppose there may be some (probably semantic) 
> errors that are detected after knowing the message is an 
> advertisement. Handling those would belong in this state machine.
>
> allow human interaction and choice? (Which could be several minutes, 
> or more.) I think this is an important distinction to make clear.
>
The CONF request, in the form depicted in the protocol draft, is not 
conceived  as a response to the ADV.
It is a request of configuration that can be sent only after an 
ADVERTISEMENT has been received. However, after a first ADV has been 
received, a CONF request can be issued also without receiving a new ADV 
if, for example, the MC wants to change the something in the current 
configuration.
Actually, we have not made any hypotesis about when issuing a CONF. We 
rather assume that the CONF is simply issued when it is ready, i.e. when 
the ADV has been parsed and interpreted and the desired streams have 
been "translated" in the CONF message. That can happen after an 
automatic elaboration, for example according to some policy of the 
receiver, or after a human configuration, it the MC party has some 
software designed to enable a human selection of the desired features.

Thank you,

Roberta

>     Thanks,
>     Paul
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Oct 2013 11:01:23 -0400

Hi Roberta,

> the updates to the protocol draft.

Thanks. This is a key piece, and needs thorough discussion. Some 
realtime discussion may help stimulate more email discussion.

> DTLS/SCTP channel issues.

I don't think we need an ack/nak for the channel, because the channel is 
reliable. But I think we need application level confirmation that the 
message was received and understood. If one message always immediately 
triggers sending of another, then that can serve as the ack. (E.g., if 
ADV always triggers an *immediate* CONF or RE-ADV.) If not, then I think 
something needs to be added. I don't think we want to require the 
message sender to wait indefinitely to learn whether the request it sent 
was acceptable to the recipient.

And we need some way to deal with errors detected by the channel, when 
writing or reading. I think those can be treated as events to a state 
machine, triggering a suitable state transition. But these can't be 
associated specifically with the MC or MP.

> I see your point. A CLUE endpoint can surely be also provider-only or

We have a choice. We can allow consumer-only and provider-only. Or we 
can say every endpoint must run a state machine for each. If so, then 
and endpoint that wants to be consumer-only will send an "empty" ADV, 
and an endpoint that wants to be provider-only will send an "empty" CONF.

There are some small efficiency gains possible if we support 
consumer-only and provider-only. But they may be offset by added 
complexity in negotiating those modes.

> provider-) only, and in that cases the channel should not be created.

If we want to make the determination outside of the protocol, then the 
most straightforward way I see is to use a separate channel for each MP. 
If an endpoint wants to be a MP then it initiates a channel. That 
channel is used asymmetrically, with the initiator being the MP and the 
other end being the MC. (This is actually anti-client-server, because 
the server is initiating the channel. But I suppose it could be done the 
other way, with the consumer initiating the channel.)

Or we continue with our current plan to use a single channel for both. 
But then we must either assume both ends are both MC and MP, or else we 
must have some explicit mechanism to negotiate that.

> timeouts of the MP machine (no OPTIONS received).

That is unpleasant.

> But alternatives can be considered.

Some other ways:

1) Each side sends an OPTIONS, regardless of whether it wants to be MC, 
MP, or both. The MC, and MP roles are then negotiated by the OPTIONS 
exchanges. (This is what I previously proposed.) But then we need a 
different state machine for this, because the message doesn't belong to 
either the MC or MP state machines.

2) One side sends an OPTIONS, and the other responds to it. I don't like 
this approach, because its asymmetric, and there is no obvious way to 
decide which end sends.

3) We could start out assuming both sides are both MC and MP. Both sides 
send an initial ADV (possibly empty, and perhaps indicating that it will 
always be empty because the sender doesn't want to be an MP.) Then the 
other side could respond. The response could be a normal MC response. Or 
it could be a special response that says "I don't want to be an MC". In 
that latter case, both ends would shut down the state machine.

Any of these could be made to work.

> software designed to enable a human selection of the desired features.

OK. If it is your intent that the CONF can be arbitrarily delayed, or 
not sent at all, then I propose that we need a separate response message 
to the ADV. It can't be RESPONSE, because that would screw up sorting 
message types between state machines. But there could be separate 
ADV-RESPONSE and CONF-RESPONSE messages, with similar content.

It would then be expected that a response is sent promptly to an ADV or 
CONF, and failure to receive one in a timely way would be a protocol 
error requiring some remedial action.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 Oct 2013 14:16:38 +1100

Hello Simon and Roberta,

Thanks for the updates. I had a look and have a few comments below:

1. Sect.1 bullet 2 : The Config allows captures and encodings to be 
selected so I would propose to update the wording:
     2.  enabling a MC to request the desired <media captures and the 
resulting> multimedia streams from the offering MP.

2. Sect.3 1st para: The MC not only requests the stream but receives 
them. I propose updating the text:
   ...while the client side is represented by the Media Consumer, which 
requests <and receives> the media streams.

3. Sect. 3 3rd para: Similar comment to 1 above. I propose rewording:
The MC selects the desired <captures and> streams coming from the MP by 
using...

4. Sect. 3.x: The tables have "Type". Is this really needed as it is 
explained in the text. Plus 3.2 the message name is "Response" and the 
type is "Response". It seems superfluous.

5. Sect.3.3: Nit: Rescription should be "Description"

6. Sect 3.x: Are we missing a message? There is a Response for a 
Configure but there is no response to an Advertisement. If the MC 
receives an Advertisement there should at least be an indication that it 
was received OK. Why would a response to a Configure or an Advertisement 
be handled differently. I think the RE-ADV should only be used when the 
MC needs to refresh its state, not for indicating that there is a 
Advertisement message syntax problem, etc. Note: this is a similar 
comment as Paul's regarding the application level ACK. I don't think 
that a ADV needs an immediate CFG.

7. Sect.5 2nd para: What is meant by ".. if the number of trials is 
below the retry
    threshold...?

8. Sect.5 3rd para: As per 6 I think that rather than RE-ADV a 
"ADV-RESP" would be sent indicating an error condition. A MP should be 
the one to decide to determine if another ADV is sent.

9. Sect.5 3rd para: This indicates that if there is an error with the 
ADV the MC goes from state "receive ADV" to "IDLE". What doesn't 
appeared to be covered is what happens if the MC is in "IN CALL" state 
when it receives the ADV and there's an error? I would assume that 
rather than go to IDLE on error that it would go back to "IN CALL"? The 
state could potentially be affected by what error is received.

10. Sect.5 General: The term "CALL" is used. For me this encompasses the 
entire session. i.e. to be "IN CALL" it would assume the CLUE 
negotiation is done, the media streams are configured and media is 
flowing etc. As this is describing a CLUE state machine should we 
instead use CLUE specific terminology? i.e. "IN CALL" -> "CAPTURES 
NEGOTIATED" etc.

11. Sect. 6 General: As per 6 above I think there should be an 
application level response, either saying success or error. Once that is 
received then it should wait for a CONFIG or RE-ADV.

12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that has 
error when it is an a IN CALL state I would expect that it remain in an 
in call state. Rather than go back to IDLE.

13 General: Do we need to define the scope of the states that they only 
cover CLUE? or do they have further scope. E.g. If the CLUE state is 
Terminated does this indicate some other behaviour that the MP or MC 
should do? i.e. send updated SIP O/A to remove media. Btw, I'm not 
suggesting this extended scope.

14 Sect 7. Para.1: Nit - Suggested update: "... the message cannot be 
processed <further>." Some processing has to be done to determine version.

15 Sect 7. Para.3: Nit - "subsequet" -> "subsequent"

16 Sect 7. Para.3: The changes need to be backwards compatible not only 
in terms of schema but also semantically and procedurally as well.

16 Sect 7. Para.4: I'm not a big supporter of having versions related to 
different CLUE protocol drafts. Compliance to a CLUE version isn't just 
based on the version of the schema. e.g. what if we change the 
procedural handling of an existing XML element? The schema wouldn't 
change. I'd prefer simply working towards v1.0.

17 Sect 7. Para.5: nits: "ascpect"->"aspect", 
"explicitely"->"explicitly", "would up"-> "would <be> up"

18 Sect 8.1 para 4: It mentions here that " Elements or attributes from 
unknown namespaces MUST be ignored". If the MP or MC receives such an 
element I would expect that an error be returned to the ADV or CFG 
message it contained or?

19 Sect 8.1: I guess each of the last 3 bullets should be possible 
depending on the type of data. I think that we need to separate the 
actual syntax and structures (i.e. CS, CSEs, STSs etc) from the Captures 
attributes. It should be possible to create new attributes or update 
their value through an extension mechanism rather than need to update 
the protocol version. Is this what is meant by the 3rd bullet? Updates 
to the syntax and structures should need a new version.

19 Sect 8.2: I think a new message does need a new version so this 
should be the ONLY chance.

20 Sect 9 Para.3: Nit instatiated->instantiated.

21 Sect 9: I think we had some previous discussion that the OPTIONs 
should only occur once at the start of the CLUE channel. This didn't 
seem to be covered.

22 Sect 9: Why is the MC responsible for sending the OPTIONS message? I 
would have thought that as the MP sends the ADV (which is effectively 
the first message) that it would send it?

Regards, Christian

On 8/10/2013 10:21 PM, Simon Pietro Romano wrote:
>> *Da: [email-masked] <mailto:[email-masked]>
>> *Oggetto: **New Version Notification for 
>> draft-presta-clue-protocol-02.txt*
>> *Data: *08 ottobre 2013 13:20:31 GMT+02:00
>> *A: *Roberta Presta <[email-masked] 
>> <mailto:[email-masked]>>, Simon Pietro Romano 
>> <[email-masked] <mailto:[email-masked]>>, Simon Romano 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Filename:draft-presta-clue-protocol
>> Revision:02
>> Title:CLUE protocol
>> Creation date:2013-10-08
>> Group:Individual Submission
>> Number of pages: 26
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>
> _\\|//_
>       ( O-O )
>  e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Roberta Presta <[email-masked]>
Date: Mon, 14 Oct 2013 14:27:31 +0200

Hello Christian,

thank you for your comments.
Please see below.

> resulting> multimedia streams from the offering MP.
We have considered a stream as a capture encoding, i.e. the association 
of a media capture and a capture encoding, as per the framework 
definition of "stream".
We will recall such definition in section "Terminology".
> requests <and receives> the media streams.
OK.
> The MC selects the desired <captures and> streams coming from the MP 
> by using...
Same considerations of point 1.
> type is "Response". It seems superfluous.
The type of the message is an important characteristic.
Indeed, notifications, requests and responses are the three main classes 
of CLUE messages.
A request is issued only by a MC to a MP, and each request expects a 
response message coming from the opposite direction.
A notification (like the advertisement) is an asynchronous announce.
CLUE messages are demultiplexed in a CLUE endpoint on the basis of the 
type of the message:
- A MC receives only responses and notifications, while it issues only 
requests
- A MP receives only requests and issues responses and notifications
CLUE messages are expected to belong to one of the aforementioned 
categories (and this is reflected in the schema definitions).
The draft definitely needs more text about it.

> 5. Sect.3.3: Nit: Rescription should be "Description"
OK.
> receives an Advertisement there should at least be an indication that 
> it was received OK. Why would a response to a Configure or an 
> Advertisement be handled differently. I think the RE-ADV should only 
> be used when the MC needs to refresh its state, not for indicating 
> that there is a Advertisement message syntax problem, etc. Note: this 
> is a similar comment as Paul's regarding the application level ACK. I 
> don't think that a ADV needs an immediate CFG.
>
Currently in the draft there isn't a mechanism that acknowledge the ADV.
We have not considered acknowledge mechanisms at all and we have tried 
to only rely on timeouts and retry mechanisms, i.e., if nothing happens 
within the timeout interval and the timeout fires, then the message is 
issued again. This is repeated until the max number of retry is achieved.
We can discuss the  introduction of acks for notification messages. An 
acknowledgement mechanism should not be needed by the request-response 
couples since the responses act as acks.
The READV functionality could be then reduced to the one of a simple 
refresh request, since problems with the received ADV could be treated 
otherwise.

> 7. Sect.5 2nd para: What is meant by ".. if the number of trials is 
Explained in answer to point 6. We will correct the text in order to 
make it clearer.
> the one to decide to determine if another ADV is sent.
I'm OK with decoupling the READV functionality from the problems with a 
received ADV as per point 6.

> rather than go to IDLE on error that it would go back to "IN CALL"? 
> The state could potentially be affected by what error is received.

The IN CALL state indicates that the media streams the  MP and the MC 
have agreed on (and are aware of) the media streams to be exchanged 
within the call.
When a MC/MP goes out from the IN CALL state it means that something has 
changed and that the media streams currently exchanged may not be 
aligned with the ones known at the CLUE level.
For example, if a MP stops sending a certain media stream for any 
reason, it issues a new advertisement to the MC after such change.
Once received the ADV, the MC then flows from the IN CALL state to the 
ADV RECEIVED one and, if there are problems with the ADV, moves back to 
the IDLE state, which is a state where MP and MC are not aligned with 
the streams actually involved in the conference. It does not mean that 
there are no streams currently exchanged between the peers.

>
> 10. Sect.5 General: The term "CALL" is used. For me this encompasses 
> the entire session. i.e. to be "IN CALL" it would assume the CLUE 
The IN CALL state can be seen as a "negotiation completed" state where 
both the CLUE parties have successfully agreed on the media streams to 
be exchanged at the CLUE level.
We could change the name of the state or alternatively add more text to 
clarify the concept.

> application level response, either saying success or error. Once that 
> is received then it should wait for a CONFIG or RE-ADV.
>
See point 6 answer.
> 12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that 
> has error when it is an a IN CALL state I would expect that it remain 
> in an in call state. Rather than go back to IDLE.
>
See point 9 answer.
> 13 General: Do we need to define the scope of the states that they 
> only cover CLUE? or do they have further scope. E.g. If the CLUE state 
> is Terminated does this indicate some other behaviour that the MP or 
> MC should do? i.e. send updated SIP O/A to remove media. Btw, I'm not 
I think it is still premature in this phase.
> processed <further>." Some processing has to be done to determine 
OK.
> 15 Sect 7. Para.3: Nit - "subsequet" -> "subsequent"
OK.
> 16 Sect 7. Para.3: The changes need to be backwards compatible not 
> only in terms of schema but also semantically and procedurally as well.
I agree. We will add text about that concept.

>
> 16 Sect 7. Para.4: I'm not a big supporter of having versions related 
> to different CLUE protocol drafts. Compliance to a CLUE version isn't 
> just based on the version of the schema. e.g. what if we change the 
OK.
> 18 Sect 8.1 para 4: It mentions here that " Elements or attributes 
> from unknown namespaces MUST be ignored". If the MP or MC receives 
> such an element I would expect that an error be returned to the ADV or 
> CFG message it contained or?
We have conceived an extensions negotiation mechanism (via the OPTIONS 
request/response message) that should avoid to fall into that situation 
(i.e. when a peer sends a message with xml elements coming from unknown 
namespaces).
However, extensions as elements placed in correspondence of <any> are 
typically conceived to indicate something more than the basic behavior 
of the CLUE negotiation.
If the other part is not able to understand that "something more", it 
does nothing less than the ordinary behavior.
> actual syntax and structures (i.e. CS, CSEs, STSs etc) from the 
> Captures attributes. It should be possible to create new attributes or 
> update their value through an extension mechanism rather than need to 
> update the protocol version. Is this what is meant by the 3rd bullet? 
> Updates to the syntax and structures should need a new version.
>
Yes, the third bullet refers to a mechanism that enables to create new 
attributes without update the data model schema version and preserving 
the compatibility with it.
However,  according to that possibility, new attributes should be 
defined elsewhere and also in this case the new schema should be linked 
wherever we want to exploit  that extension.
> should be the ONLY chance.
As per the OPTIONS mechanism we are able to handle both data model and 
protocol updates.
In that vision, there are stable protocol and data model versions (with 
associated schema files), and extensions defined in other XML schemas.
Let's say that we have:
1) an extension for the data model, i.e. a schema file S1 defining new 
data model elements. For example, we can imagine a schema defining other 
audio capture attributes represented by XML elements placed in 
correspondence of the <any> element in the data model audio capture 
definition.
2) an extension for the protocol, i.e. a schema file S2 defining for 
example a new notification message that makes the MP able to inform the 
MC about the availabilty and the status of video captures only.
The MC supporting both extensions issues an OPTIONS containing the 
references of both S1 and S2.
The MP supporting both extensions recognizes the schemas and then knows 
that it can issue specific notifications according to the format 
provided in S2 and that it can use also the features defined in S1 to 
describe the available audio captures.

> 20 Sect 9 Para.3: Nit instatiated->instantiated.
OK.
> should only occur once at the start of the CLUE channel. This didn't 
Yes, the OPTIONS occurs once at the start of the CLUE channel. It is not 
written explicitly, but there is a description and a picture of the 
mechanism explained in sec. 9.1.
We will add these important details in the next version.

> 22 Sect 9: Why is the MC responsible for sending the OPTIONS message? 
> I would have thought that as the MP sends the ADV (which is 
> effectively the first message) that it would send it?
>
With the introduction of the OPTIONS message, the ADV is no more the 
first message to be sent.
The state machines represent the evolution of the MP and of the MC after 
that the version of the protocol and the involved extensions have been 
agreed with the OPTIONS message.
The OPTIONS message is conceived as a request that expects a response.
It is the MC that issues that request, providing to the MP the supported 
extensions and the higher supported protocol version. In that way, the 
MP can select the extensions in the set supported by the MC and then use 
only information that is understood by the MC.

Roberta

---

From: Christian Groves <[email-masked]>
Date: Tue, 15 Oct 2013 10:47:56 +1100

Hello Roberta,

Thanks for the response. Please see my comments below.

Regards, Christian

On 14/10/2013 11:27 PM, Roberta Presta wrote:
> We have considered a stream as a capture encoding, i.e. the 
> association of a media capture and a capture encoding, as per the 
> framework definition of "stream".
[CNG] I think in the protocol document rather than trying to shorten 
things by referring to "stream" we should be should talk about captures, 
encodings etc to be more precise.

>>   ...while the client side is represented by the Media Consumer, 
>> which requests <and receives> the media streams.
>>
> OK.
>> explained in the text. Plus 3.2 the message name is "Response" and 
>> the type is "Response". It seems superfluous.
>>
> Indeed, notifications, requests and responses are the three main 
> classes of CLUE messages.
[CNG] I don't see why a MP would not receive a "response"?
> The draft definitely needs more text about it.
[CNG] I don't understand what "demultiplexing" has to do with the type? 
I thought this would be done based on the message name? Why can't we 
follow a simple Request/Response type? The behaviour is based on the 
message name rather than another concept of "type"
i.e. MP sends an Advertisement (req) it receives an response (ack/nack).
      MC sends a Configure (req) it receives an response (ack/nack).
      MC sends a Reavd (req) it receives a response (ack/nack)

We don't need to call an "Advertisement" a notification because 
ultimately it doesn't mean anything. The MC reacts based on the semantic 
of Advertisement and the information elements included.
> to only rely on timeouts and retry mechanisms, i.e., if nothing 
> happens within the timeout interval and the timeout fires, then the 
> message is issued again. This is repeated until the max number of 
> retry is achieved.

[CNG] Isn't there an acknowledgement mechanism for the Configure 
message? i.e. the response. I'm wondering why the mechanism is different 
for Advertisements? The MC is expected to do something at the reception 
of an Advertisement rather than just ignore it. Just a the MP is 
expected to do something when receiving the Configure.

>> "ADV-RESP" would be sent indicating an error condition. A MP should 
>> be the one to decide to determine if another ADV is sent.
>>
> I'm OK with decoupling the READV functionality from the problems with 
> a received ADV as per point 6.
>
>> appeared to be covered is what happens if the MC is in "IN CALL" 
>> state when it receives the ADV and there's an error? I would assume 
>> that rather than go to IDLE on error that it would go back to "IN 
>> CALL"? The state could potentially be affected by what error is 
>> received.
>
> When a MC/MP goes out from the IN CALL state it means that something 
> has changed and that the media streams currently exchanged may not be 
[CNG] I understand the need for re-Advertisement but one doesn't 
necessary change the current media state. A re-advertisement may also 
advertise a new VC for a camera that has been turned on. To me the media 
is still "IN CALL".
> ADV RECEIVED one and, if there are problems with the ADV, moves back 
> to the IDLE state, which is a state where MP and MC are not aligned 
> with the streams actually involved in the conference. It does not mean 
> that there are no streams currently exchanged between the peers.

> We could change the name of the state or alternatively add more text 
> to clarify the concept.
[CNG] I think we need to do both. I don't think "IN CALL" accurately 
reflects what the state is.
>> only cover CLUE? or do they have further scope. E.g. If the CLUE 
>> state is Terminated does this indicate some other behaviour that the 
>> MP or MC should do? i.e. send updated SIP O/A to remove media. Btw, 
>> I'm not suggesting this extended scope.
>>
[CNG] What do the states currently reflect? For example I don't think 
"IN CALL" is correct from a CLUE perspective because CLUE doesn't 
consider calls. However if you think that the states will cover SIP O/A 
then its a different matter.
> ..snip..
>> such an element I would expect that an error be returned to the ADV 
>> or CFG message it contained or?
> request/response message) that should avoid to fall into that 
> situation (i.e. when a peer sends a message with xml elements coming 
> from unknown namespaces).
[CNG] I understand the error situation, its the "ordinary" behaviour 
part that's a concern. If the MC and MP receives something that it 
doesn't understand I would have thought it would generate an error 
response rather than ignoring it.
>> Captures attributes. It should be possible to create new attributes 
>> or update their value through an extension mechanism rather than need 
>> to update the protocol version. Is this what is meant by the 3rd 
>> bullet? Updates to the syntax and structures should need a new version.
>>
> defined elsewhere and also in this case the new schema should be 
> linked wherever we want to exploit  that extension.
[CNG] I guess my point is that there are multiple ways of providing 
extensions but should we allow all those methods to be used. Can we 
specify that if you want to add a new message then this is the one way 
to do it. If you want to add new syntax this is the way to do it. We can 
add all sorts of flexibility but is it needed?
> In that vision, there are stable protocol and data model versions 
> (with associated schema files), and extensions defined in other XML 
> schemas.
> Let's say that we have:
> data model elements. For example, we can imagine a schema defining 
> other audio capture attributes represented by XML elements placed in 
> example a new notification message that makes the MP able to inform 
> the MC about the availabilty and the status of video captures only.
> The MP supporting both extensions recognizes the schemas and then 
> knows that it can issue specific notifications according to the format 
[CNG] See above.
>> ..snip..
[CNG] The ADV is effectively the first message with real information 
related to what CLUE is about, sharing information about captures.

> The state machines represent the evolution of the MP and of the MC 
> after that the version of the protocol and the involved extensions 
> have been agreed with the OPTIONS message.
[CNG] I agree that OPTIONs needs a response. Like all the other CLUE 
messages.
>
> It is the MC that issues that request, providing to the MP the 
> supported extensions and the higher supported protocol version. In 
> that way, the MP can select the extensions in the set supported by the 
> MC and then use only information that is understood by the MC.
[CNG] Doesn't think require effectively 3 messages? 
OPTIONS->RESPONSE->ACK for the MP to be sure what to send? If the MP 
sends OPTIONS and gets a response from the MC it then knows what to send 
in the ADV. The negotiation still works because the MC selects from what 
the MP can send.