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

From: Roberta Presta <[email-masked]>
Date: Tue, 17 Sep 2013 12:00:48 +0200

Hi all,

we have added in this new version some considerations about protocol 
versioning and extension introduced in the last team call.
Cheers,

Roberta

-------- Messaggio originale --------
Oggetto: 	New Version Notification for draft-presta-clue-protocol-01.txt
Data: 	Tue, 17 Sep 2013 02:55:54 -0700
Mittente: 	[email-masked]
A: 	Roberta Presta <[email-masked]>, Simon Pietro Romano 
<[email-masked]>, Simon Romano <[email-masked]>

A new version of I-D, draft-presta-clue-protocol-01.txt
has been successfully submitted by Roberta Presta and posted to the
IETF repository.

Filename:	 draft-presta-clue-protocol
Revision:	 01
Title:		 CLUE protocol
Creation date:	 2013-09-17
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-01.txt
Status:          http://datatracker.ietf.org/doc/draft-presta-clue-protocol
Htmlized:        http://tools.ietf.org/html/draft-presta-clue-protocol-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-01

Abstract:
    ToDo.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2013 12:26:09 -0400

Hi Roberta,

Thank you for continuing this work.

I need to consider this revision further regarding the state machine 
changes. I'll comment later on those if need be. For the moment I just 
want to ask some questions about the extensibility and versioning. You say:

    Obviously, client and server can not communicate if they do not share
    exactly the same XML schema.  Such schema will be the one included in
    the to-be-written RFC, and associated with the CLUE URN
    "urn:ietf:params:xml:ns:clue-message".

and then,

    When new protocol-specific information are needed somewhere in the
    protocol messages, they can be added in place of the <any> elements
    and <anyAttribute> elements envisioned by the protocol schema.  The
    policy currently defined in the protocol schema for handling <any>
    and <anyAttribute> elements is:

       elementFormDefault="qualified"

       attributeFormDefault="unqualified"

    In that case, the new information must be qualified by namespaces
    other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN)
    and "urn:ietf:params:xml:ns:clue-info" (the data model URN).
    Elements or attributes from unknown namespaces MUST be ignored.

(And similar logic for data model extensions and addition of new messages.)

This implies that every extension defines another schema. Couldn't that 
get unpleasant? My quick reading of XMPP leads me to believe that it 
allows backward compatible revisions to its schema. (But I don't fully 
understand the implications of what it does.)

Another thing - it is certainly everyone's hope that we get everything 
right enough the first time that we don't ever require a change that is 
not backward compatible. But that doesn't mean we will be successful at 
that.

What would you suggest be done if an incompatible change is required? 
Would you just have this detected via a change to the namespace URN?

While I see that could work, with multiple schemas, not all of which are 
used in every message, that could mean that an unsupported schema would 
not be detected until the clue session is well underway. That seems 
undesirable - that we would like to detect incompatibility as early as 
possible.

Also, what about aspects of the protocol other than XML? (For instance, 
suppose some future extension is dependent on future extensions to SDP.) 
Do you think there should be some *other* version/extension mechanism 
for that?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Sep 2013 16:49:21 -0400

Hi again Roberta & Simon,

Now some comments on the state machines and messages:

* Demuxing messages to provider/consumer state machines:

We are assuming a single channel for both. So messages will need to be 
identified and dispatched to one or the other of the state machines. 
That will require parsing the message to determine its type. Won't parse 
errors occur there?

This also requires that every message type be specific to one or the 
other of state machines. That is true so far for most of the messages 
you define, but not for RESPONSE? So how is RESPONSE dispatched?

What about extension messages? What should happen to those?

Errors from the channel while reading a message may affect neither state 
machine, or both. Recovering from fatal errors may require closing and 
reestablishing either the transport, or the channel within the transport.

If we are to separate the protocol from the rest of the signaling, then 
I think we will want a transport abstraction over the sctp data channel, 
that the protocol deals with. (We can jointly negotiation what that 
should look like.) Then the protocol document will still need to deal 
with parsing messages, dispatching to the proper state machine, etc. The 
the signaling draft can deal with mapping that abstraction onto SCTP, 
and worry more about the error cases. But somewhere we must address what 
happens when the clue protocol becomes unavailable, either intentionally 
or because of unrecoverable error.

* Media Consumer:

Upon receiving a valid ADV, is the consumer obligated to send a CONF 
right away? It may be that the consumer needs to do some human 
interaction to decide what to include in the CONF message. In that case, 
must it send some CONF immediately and then another later after the 
human input? (The receive error RESP transition from this state only 
makes sense if the CONF isn't sent immediately, and so new messages can 
be noticed.)

In ADV RECEIVED state, I think parsing must already have been done, so 
syntax errors must have already been handled. The remaining processing 
that could result in errors is semantic. Is there a reason for using 
RE-ADV rather than a RESPONSE message to indicate errors with the ADV?

Suppose ADV1 is received, and CONF1 is sent. Then ADV2 is received. This 
moves to ADV RECEIVED state, and CONF2 is sent. Then RESPONSE1 is 
received (might be either OK or failure, assume OK) while in TRYING 
state. That moves to IN CALL. Then RESPONSE2 is received and again could 
be either OK or failure. No transitions are defined.

(ISTM that in general only a response matched to the most recent CONF 
should be considered. Responses to other CONFs should be treated 
differently. Or else there may need to be a "transaction state machine" 
for each ADV and CONF.)

In TERMINATED state, what effect should this have on the media provider 
state machine?

If an error leads to the TERMINATED state (in either media producer or 
media consumer) what impact do you anticipate that may have on the other 
state machine?

* Media Provider:

In WAIT FOR CONF, do you imagine a short timeout, or a long one? Must it 
be long enough to allow for human interaction by the consumer? What if 
the consumer won't be ready to make a decision for a long time?

In the TIMEOUT state, after how many timeouts (or equivalently, how much 
elapsed time without a CONF) do you envision would be reasonable before 
giving up?

* Section 3.2 (CONFIGURE)

   | USAGE        |   The MC can send a CONF after the reception of     |
   |              |   an ADV or each time it wants to request other     |
   |              |   advertised captures to the MP.                    |

"can send" implies this is optional. If so, it isn't good as an ack that 
the ADVERTISEMENT was processed and found acceptable. If you are 
assuming a "no news is good news", then it would be good to explicitly 
say so. (I'm dubious of that.)

* Section 3.3 (RESPONSE)

The usage for this says it is just for CONFIGURE, while RE-ADV is an 
error-only response for ADVERTISEMENT. But RESPONSE has a lot of generic 
error types that could apply to all messages, not just CONFIGURE. And 
what should be sent in response to a message of some other (or unknown) 
type?

	Thanks,
	Paul

P.S. I will have very spotty network access from now until next Tuesday.

On 9/17/13 6:00 AM, Roberta Presta wrote:
> URL:http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-01.txt
> Status:http://datatracker.ietf.org/doc/draft-presta-clue-protocol
> Htmlized:http://tools.ietf.org/html/draft-presta-clue-protocol-01
> Diff:http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-01
>
> Abstract:
>     ToDo.
>
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Roberta Presta <[email-masked]>
Date: Tue, 24 Sep 2013 17:25:13 +0200

Hi Paul,

I try to answer in the following.

Il 17/09/2013 18:26, Paul Kyzivat ha scritto:
> This implies that every extension defines another schema. Couldn't 
> that get unpleasant? My quick reading of XMPP leads me to believe that 
> it allows backward compatible revisions to its schema. (But I don't 
> fully understand the implications of what it does.)
>
If you use a new schema that way, for exploiting an extension (a *new* 
information, or a *new* message - not a *change* to the existent 
standard stuff), there are no backward compatibility problems.
If you do not support the extension, you simply ignore it, but you are 
able to do all the other standard things.

> right enough the first time that we don't ever require a change that 
> is not backward compatible. But that doesn't mean we will be 
> successful at that.
>

We have to design the model in order to be able to easily introduce news 
in a backward compatible way. Non backward compatible changes should be 
strongly discouraged.
While non backward compatible news could be frequent in this starting 
phase, they should be not in the future, when the standard version will 
be ready.
In this starting phase, we simply change the schema associated to the 
URN, until we do not share a stable solution.

If a completely uncompatible version is designed, then it should replace 
the existing one - it is always up to implementors to keep the product 
aligned with the standards.

> While I see that could work, with multiple schemas, not all of which 
> are used in every message, that could mean that an unsupported schema 
> would not be detected until the clue session is well underway. That 
> seems undesirable - that we would like to detect incompatibility as 
> early as possible.

We recognize that we have to design a mechanism to signal that a certain 
extension is not supported and we will working on it.
Extensions to data model information and extensions to protocol messages 
should be treated separately when designing the aforementioned mechanism.

>
> Also, what about aspects of the protocol other than XML? (For 
> instance, suppose some future extension is dependent on future 
> extensions to SDP.) Do you think there should be some *other* 
> version/extension mechanism for that?
>
...That's one of the motivations for keeping as independent as possible 
CLUE signaling from SDP signaling!