Subject: [clue] Proposal for dividing and restructuring Signaling work.

From: Mary Barnes <[email-masked]>
Date: Tue, 17 Sep 2013 12:08:57 -0500

HI all,

The diagram I presented is included in the proceedings in the chair charts
(slide 7):   Agenda & Status
(Chairs)<http://www.ietf.org/proceedings/interim/2013/09/17/clue/slides/slides-interim-2013-clue-3-0.pptx>

The motivation for this suggestion is that we already have another
individual doc that is describing details of the CLUE protocol.  I believe
that keeping all the details of that in a separate document will make the
work more manageable. Otherwise, I fear we will have one of those 200 page
monster documents, which is difficult to share amongst multiple authors and
a nightmare to progress.   Even with this split, my guess is that both
these documents would be anywhere from 75-100 pages when completed once we
get all the details in, including error handling, IANA registrations,
security, etc.

So, here is my suggestion for the Abstract/Intro and ToC for the signaling
document:
OLD Abstract:
This document specifies how signaling is conducted in the course of CLUE
sessions. This includes how SIP/SDP signaling is applied to CLUE sessions
as well as defining a CLUE-specific signaling protocol that complements
SIP/SDP and supports negotiation of CLUE application level data.

NEW Abstract:
This document specifies the signaling model for CLUE sessions. It describes
the orchestration of SIP/SDP O/A with the CLUE protocol to support the
CLUE use cases. This document identifies the SDP
and RTP building blocks required to establish a CLUE session.

New ToC:

1. Introduction

2. Terminology

3. Overview

This document describes the orchestration of the SIP SDP O/A signaling
with the CLUE protocol [reference].   The details of the SDP and RTP
building blocks are also identified, with relevant references to the
documents that are required for the overall CLUE solution. The
document provides details on the mapping that is required between
constructs in the CLUE Data model [ref] and SDP.  This document also
discusses how CLUE would operate in an environment where one or more
of the participants does not support CLUE.  A few examples are
provided.  A separate document provides additional detailed call flows
of the realization of the CLUE use cases based upon the protocol
details defined in this document.

--- A nice diagram would also help.  [In my opinion, this is a better
place to introduce all the CLUE solution work, which I previously
suggested should be in the Framework.]

4.  CLUE use of SDP O/A

    4.1.  Establishing the CLUE channel
    4.2.  Representing CLUE Encodings in SDP
    4.3.  Representing CLUE Encoding Groups in SDP
    4.4.  Signaling CLUE control of "m" lines
     4.5.  Ensuring interoperability with non-CLUE devices

5.  Interaction of CLUE and SDP negotiations
     5.1 Independence of SDP and CLUE negotiation
     5.2.  Recommendations for operating with non-atomic operations
     5.3.  Constraints on sending media

6.  Example: A call between two CLUE-capable endpoints

7.  Example: A call between a CLUE and non-CLUE-capable endpoint   38

8.  CLUE requirements on SDP O/A

9.  SIP Signaling

10. Interoperation with non-CLUE aware SIP Devices [I'd rather ditch
the term "legacy"]

11. CLUE over RTCWEB

....remainder is the same....

Here's the suggestion for the Abstract/Intro and ToC for the CLUE
protocol document:

This document provides the details for the CLUE protocol based upon the
constructs defined in the CLUE framework.  The CLUE protocol is used in
conjunction with SIP/SDP to establish CLUE sessions to support the CLUE use
cases.  The CLUE protocol is based on an XML schema that provides
versioning and extensibility. The CLUE protocol carries CLUE information,
as identified in the framework, in the form of XML documents and fragments
conforming to the CLUE data model schema.

Toc:

1. Introduction

2.  Terminology

3.  Overview of the CLUE protocol messages
     3.1.  ADVERTISEMENT
     3.2.  CONFIGURE
     3.3.  RESPONSE
     3.4.  RE-ADV .
4.  Protocol state machines
    4.1 Media Consumer's state machine
    4.2 Media Provider's state machine

5.  Message Sequencing

6.  Message Schema

7.  CLUE protocol XML schema extensibility and versioning

     7.1.  Aspect 1 - new information within existing messages
     7.2.  Aspect 2 - new messages

8.  Examples

9. Message Transport

10.  Message Framing

...other stuff like Security considerations, IANA, etc.

If folks could share their thoughts and opinions on this so we can get
things moving forward, that would be great.  Ideally, if we follow this
approach, finding a new editor for the WG signaling document won't seem to
be such an onerous task.

Regards,
Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2013 17:00:07 -0400

Mary,

I do agree the clue protocol can be a separate document, as long as the 
cut is done cleanly. I think that means it includes all the messages, 
defined as XML elements that are exchanged over a single reliable 
bidirectional medium, along with their semantics and sequencing. The 
signaling document will then define how they are transported. There will 
need to be a defined interface: the errors that might occur when sending 
or receiving messages that the protocol needs to cope with, and maybe 
some action(s) to reset/retry the transport.

That would, in principle, allow the protocol to be rehosted over some 
other transport, though we have no specific plans to do that.

More comments on the rest later.

	Thanks,
	Paul

On 9/17/13 1:08 PM, Mary Barnes wrote:
> HI all,
>
> The diagram I presented is included in the proceedings in the chair
> charts (slide 7): Agenda & Status (Chairs)
> <http://www.ietf.org/proceedings/interim/2013/09/17/clue/slides/slides-interim-2013-clue-3-0.pptx>
>
> individual doc that is describing details of the CLUE protocol.  I
> believe that keeping all the details of that in a separate document will
> make the work more manageable. Otherwise, I fear we will have one of
> those 200 page monster documents, which is difficult to share amongst
> multiple authors and a nightmare to progress.   Even with this split, my
> guess is that both these documents would be anywhere from 75-100 pages
> when completed once we get all the details in, including error handling,
> IANA registrations, security, etc.
>
> So, here is my suggestion for the Abstract/Intro and ToC for the
> signaling document:
> OLD Abstract:
> sessions. This includes how SIP/SDP signaling is applied to CLUE
> sessions as well as defining a CLUE-specific signaling protocol that
> complements SIP/SDP and supports negotiation of CLUE application level data.
>
> NEW Abstract:
> This document specifies the signaling model for CLUE sessions. It
> describes the orchestration of SIP/SDP O/A with the CLUE protocol to
> support the
> This document describes the orchestration of the SIP SDP O/A signaling with the CLUE protocol [reference].   The details of the SDP and RTP building blocks are also identified, with relevant references to the documents that are required for the overall CLUE solution. The document provides details on the mapping that is required between constructs in the CLUE Data model [ref] and SDP.  This document also discusses how CLUE would operate in an environment where one or more of the participants does not support CLUE.  A few examples are provided.  A separate document provides additional detailed call flows of the realization of the CLUE use cases based upon the protocol details defined in this document.
>
> --- A nice diagram would also help.  [In my opinion, this is a better place to introduce all the CLUE solution work, which I previously suggested should be in the Framework.]
>
> 4.  CLUE use of SDP O/A
>
> 10. Interoperation with non-CLUE aware SIP Devices [I'd rather ditch the term "legacy"]
>
> 11. CLUE over RTCWEB
>
> Here's the suggestion for the Abstract/Intro and ToC for the CLUE protocol document:
>
> conjunction with SIP/SDP to establish CLUE sessions to support the CLUE
> use cases.  The CLUE protocol is based on an XML schema that provides
> versioning and extensibility. The CLUE protocol carries CLUE
> information, as identified in the framework, in the form of XML
> documents and fragments conforming to the CLUE data model schema.
>
> Toc:
>
> 1. Introduction
>
> 2.  Terminology
>
> approach, finding a new editor for the WG signaling document won't seem
> to be such an onerous task.
>
> Regards,
> Mary.

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 18 Sep 2013 10:08:30 +0200

Hello everybody,

I like very much the diagram proposed in the slides and think the separation of concerns is a good approach to let things evolve smoothly. We'll work with this new philosophy  in mind.

Cheers,

Simon

Il giorno 17/set/2013, alle ore 23:00, Paul Kyzivat ha scritto:

> Mary,
> 
> I do agree the clue protocol can be a separate document, as long as the cut is done cleanly. I think that means it includes all the messages, defined as XML elements that are exchanged over a single reliable bidirectional medium, along with their semantics and sequencing. The signaling document will then define how they are transported. There will need to be a defined interface: the errors that might occur when sending or receiving messages that the protocol needs to cope with, and maybe some action(s) to reset/retry the transport.
> 
> That would, in principle, allow the protocol to be rehosted over some other transport, though we have no specific plans to do that.
> 

                     					       _\\|//_
                           				      ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/