Subject: [clue] REMINDER: CLUE WG Signaling Design Team, tomorrow, Tuesday 10-sep

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Sep 2013 10:18:08 -0400

The first of the new series of design team meetings will be Tuesday Sept 10.
(See below for time.)

The new series is concentrating on the CLUE signaling.
This meeting is open to all who are willing to contribute.
Contribute means that you volunteer to provide text.

We have a set of volunteers, and they are the people I expect to have 
call in:
Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan.
(Others willing to contribute are welcome. If you'd like to join, please 
contact me so we can discuss your role.)

For this first session I've promised to take the lead on the issue of: 
Approach to versioning/options/extensions.
I won't have text in the draft for this by then, but I will have a 
specific proposal, in PPT form.

	Thanks,
	Paul

-------- Original Message --------
Subject: 	(Forward to attendees) Meeting invitation: CLUE WG Signaling
Design Team
Resent-Date: 	Tue, 3 Sep 2013 10:13:33 -0400
Resent-From: 	[email-masked]
Resent-To: 	[email-masked], [email-masked]
Date: 	Tue, 3 Sep 2013 14:13:20 +0000 (GMT)
From: 	Clue Working Group <[email-masked]>
Reply-To: 	[email-masked]
To: 	[email-masked]

**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Signaling Design Team
Date: Tuesday, September 10, 2013
Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 646 255 438
Meeting Password: 1234

-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3 

2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3 

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:646 255 438

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked] <mailto:[email-masked]>

To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3 

The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+16504793208x646255438#

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording,
discuss your concerns with the meeting host prior to the start of the
recording or do not join the session. Please note that any such
recordings may be subject to discovery in the event of litigation.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Sep 2013 18:11:14 -0400

I put the ppt I will be using tomorrow on the wiki.
You can pull it directly from:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/CLUE%20versioning.10sep13.pptx

	Thanks,
	Paul

On 9/9/13 10:18 AM, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Sep 2013 14:05:56 +1000

Hello Paul,

Given the time I'm not sure that I will participate, some comments to 
the open questions:

Do we distinguish between the CLUE channel and overall CLUE behavior?
Do we handle options/extensions via versioning, or separate from versioning?
Do we have any examples of options to work with?
[CNG] I think this depends on how we see the mechanism that will be used 
to update CLUE. For example: we might say that any syntax updates to 
core concepts (e.g. capture/scene/cse) needs a new version however new 
attributes could be introduced without update to the version. The 
support of these new attributes (or values) could be indicated via 
options/extensions.

Do we establish once for a session?
Or permit changes during a session?
[CNG] To keep things easy I think that any version negotiation should 
only occur once in a session. It seems to me that the CLUE protocol 
version update would only be associated with a upgrade of the endpoint 
SW. It seems unnecessary to do this whilst a session is established.

Do we negotiate in SIP, SDP, or in the CLUE channel?
[CNG] As CLUE is effectively subordinate to a session control protocol I 
thought that the version and options could be negotiated via that.

What naming/numbering scheme?
[CNG] I would say keep it simple with a single integer. I don't see that 
major and minor versions are necessary.

What requirements for backward compatibility?
[CNG] I think that any changes need to be backwards compatible. I think 
that we should adopt the principles in 3.1.4/[draft-kyzivat-clue-signaling].

Having said the above I see that the actual proposal goes against many 
of the comments. In general I'm OK with the proposal because I think 
that with versioning its just a case of picking a method and running 
with it. I'm still not convinced by the major and minor version thing as 
I haven't seen successful use of this in protocols. If we go down this 
approach and use in protocol messages then we need to mandate that at 
least the version handling messages/syntax cannot change between versions.

Regards, Christian