Subject: [clue] CLUE protocol message type comment

From: "Roni Even" <[email-masked]>
Date: Sun, 22 Jun 2014 17:50:07 +0300

Hi,

Trying to write the call flows make me review the other documents (good
excuse)

This is the base CLUE message type

<xs:complexType name="clueMessageType" abstract="true">

<xs:sequence>

<xs:element name="clueId" type="xs:string"/>

<xs:element name="sequenceNr" type="xs:unsignedInt"/>

</xs:sequence>

<xs:attribute name="protocol" type="xs:string" fixed="CLUE" use="required"/>

<xs:attribute name="v" type="xs:string" use="required"/>

</xs:complexType>

Some comments

1.       What is the purpose of the ClueId? Is this for displaying the
station name?

2.       The version (v) is defined as string, this is also the type for the
version in the supported version. Being a string will make comparison in
option and option response dependent on having the same string in both. For
example the option can have "v1.0" while the response will be "ver 1.0",
should be positive integer also in version list type.

3.       Why do we need the fixed attribute "protocol" with the vale CLUE,
this is already known from the ppid (51) of the sctp channel? I assume that
if we will have another transport it will include the opening of a CLUE
channel.

Roni

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Jun 2014 16:08:52 -0400

On 6/22/14 10:50 AM, Roni Even wrote:

> 3.Why do we need the fixed attribute “protocol” with the vale CLUE, this
> is already known from the ppid (51) of the sctp channel? I assume that

ppid 51 is not unique to clue - it is used for all data channel payloads.

Without something in the xml, determining that this is clue will be 
contextual. Having it be explicit will help with analysis tools, deep 
packet inspection, etc.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 23 Jun 2014 00:06:15 +0300

Hi Paul,
This is not my understanding of the PPID parameter.
There is a IANA registry for SCTP PPID
http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p
arameters-25 and looking at it PPID 51 is already assigned
Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 22 June, 2014 11:09 PM
> To: [email-masked]
> Subject: Re: [clue] CLUE protocol message type comment
> 
> > 3.Why do we need the fixed attribute "protocol" with the vale CLUE,
> > this is already known from the ppid (51) of the sctp channel? I assume
> > that if we will have another transport it will include the opening of
> > a CLUE channel.
> 
contextual.
> Having it be explicit will help with analysis tools, deep packet
inspection, etc.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Jun 2014 17:24:05 -0400

> arameters-25 and looking at it PPID 51 is already assigned

Yes, I know. Values 50-54 were defined for use with data channels. Of 
those, 52 and 54 have already been effectively deprecated. 51 and 53 are 
used for data channel payloads. The distinction between them is an 
artifact of javascript.

*All* payload data using data channels will be with either ppid 51 or 
53. We can't claim 51 as being unique for clue.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 23 Jun 2014 15:09:12 +1000

Hello Roni,

Please see below.

Regards, Christian

On 23/06/2014 12:50 AM, Roni Even wrote:
>
> Hi,
>
> Trying to write the call flows make me review the other documents 
> (good excuse)
>
> 1.What is the purpose of the ClueId? Is this for displaying the 
> station name?
>
[CNG] The draft says its the identifier of the CP (CLUE participant???) 
within the telepresence system. I agree we need some more information 
about this.
>
> 2.The version (v) is defined as string, this is also the type for the 
> version in the supported version. Being a string will make comparison 
> in option and option response dependent on having the same string in 
> both. For example the option can have “v1.0” while the response will 
> be “ver 1.0”, should be positive integer also in version list type.
>
[CNG] I agree we should specify the exact version string to use.
>
> 3.Why do we need the fixed attribute “protocol” with the vale CLUE, 
[CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" 
will help with identification. Given the size of the XML I don't think a 
few extra bytes for this is a problem.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 23 Jun 2014 11:49:42 +0300

Hi,
So I am confused.
According to RFC4960

Payload Protocol Identifier: 32 bits (unsigned integer)

      This value represents an application (or upper layer) specified
      protocol identifier.  This value is passed to SCTP by its upper
      layer and sent to its peer.  This identifier is not used by SCTP
      but can be used by certain network entities, as well as by the
      peer application, to identify the type of information being
      carried in this DATA chunk.  This field must be sent even in
      fragmented DATA chunks (to make sure it is available for agents in
      the middle of the network).  Note that this field is NOT touched
      by an SCTP implementation; therefore, its byte order is NOT
      necessarily big endian.  The upper layer is responsible for any
      byte order conversions to this field.

      The value 0 indicates that no application identifier is specified
      by the upper layer for this payload data.

And

Payload Protocol Identifiers

   Except for value 0, which is reserved by SCTP to indicate an
   unspecified payload protocol identifier in a DATA chunk, SCTP will
   not be responsible for standardizing or verifying any payload
   protocol identifiers; SCTP simply receives the identifier from the
   upper layer and carries it with the corresponding payload data.

   The upper layer, i.e., the SCTP user, SHOULD standardize any specific
   protocol identifier with IANA if it is so desired.  The use of any
   specific payload protocol identifier is out of the scope of SCTP.

So what is the purpose of the IANA registry for PPIDs and why we do not
allocate a unique CLUE PPID but re-use ones used by webRTC. This may cause
confusion for applications that will look at the PPID value and take action
based on it which is OK according to SCTP.
I am not saying we should not use the protocol-id fixed value in the CLUE
message but it is more a question also for the CLUE data channel

BTW: the registry
http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-p
arameters-25 does not mention that some values were deprecated but still
they should not be re-used

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 23 June, 2014 12:24 AM
> To: Roni Even; [email-masked]
> > arameters-25 and looking at it PPID 51 is already assigned Roni
> 
those, 52
> and 54 have already been effectively deprecated. 51 and 53 are used for
data
> channel payloads. The distinction between them is an artifact of
javascript.
> 
> *All* payload data using data channels will be with either ppid 51 or 53.
We
> can't claim 51 as being unique for clue.
> 
> 	Thanks,
> 	Paul
> 
> >
> >>> this is already known from the ppid (51) of the sctp channel? I
> >>> assume that if we will have another transport it will include the
> >>> opening of a CLUE channel.
> >>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 23 Jun 2014 11:53:13 +0300

Christian,
The version should not be a string but an integer, similar example is XCON
protocol which uses an integer.

As for PPID, it is for the application above the SCTP (RFC4960) which is
either RTCweb (ppid=50) or CLUE (which should have a unique IANA registered
PPID)

Roni

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: 23 June, 2014 8:09 AM
> To: [email-masked]
within the
> telepresence system. I agree we need some more information about this.
> >
> > both. For example the option can have "v1.0" while the response will
> > be "ver 1.0", should be positive integer also in version list type.
> >
few extra
> bytes for this is a problem.
> 
> > Roni
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2014 10:01:15 -0400

> message but it is more a question also for the CLUE data channel

This is an example of the problem of using flat namespaces for 
hierarchical structures.

If we were using SCTP directly for CLUE, then it might make sense to 
assign a CLUE-specific PPID value. But we are instead putting CLUE over 
data channel. So data channel is the "SCTP user", and we need to adhere 
to its use of PPIDs.

If we were to use some different PPID then we couldn't build a CLUE 
client over RTCWEB, because RTCWEB clients are restricted in how PPIDs 
are used.

	Thanks,
	Paul

---

From: Roberta Presta <[email-masked]>
Date: Mon, 23 Jun 2014 16:44:12 +0200

Hi Christian, hi Roni,

please see below.

Il 23/06/2014 07:09, Christian Groves ha scritto:
> [CNG] The draft says its the identifier of the CP (CLUE 
> participant???) within the telepresence system. I agree we need some 
> more information about this.
>>
The purpose of the identifier is providing a unique name for the CLUE 
entity involved in the telepresence session at the CLUE application level.
It has not been conceived (necessarily) for carrying a displayable name 
of the CLUE entity.
In the terminology section, in order to make a reference to both a CLUE 
endpoint and a CLUE MCU, we have introduced the term "CLUE participant" 
(for the sake of brevity/convenience).
These are the definitions we used:

CLUE Participant  An entity able to use the CLUE protocol within a
       telepresence session.  It can be an endpoint or a MCU able to use
       the CLUE protocol.

Endpoint  The logical point of final termination through receiving,
       decoding and rendering, and/or initiation through capturing,
       encoding, and sending of media streams.  An endpoint consists of
       one or more physical devices which source and sink media streams,
       and exactly one [RFC4353  <http://tools.ietf.org/html/rfc4353>] Participant (which, in turn, includes
       exactly one SIP User Agent).  Endpoints can be anything from
       multiscreen/multicamera room controllers to handheld devices.

MCU  Multipoint Control Unit (MCU) - a device that connects two or
       more endpoints together into one single multimedia conference
       [RFC5117  <http://tools.ietf.org/html/rfc5117>].  An MCU may include a Mixer [RFC4353  <http://tools.ietf.org/html/rfc4353>].

> [CNG] I agree we should specify the exact version string to use.

I agree we need to be more precise in the describing text.
In our mind, the content of the "v" attribute would be something like 
"1.0" or "2.34" (without letters and with a dot separating the major 
version number to the minor version one).
However, if we want to use a numeric content, we could split the major 
version number and the minor version one, by this way having the 
following attributes instead of the single "v" one:

<xs:attribute name="majorVersion" type="xs:short" use="required"/>
<xs:attribute name="minorVersion" type="xs:short" use="required"/>

For the sake of brevity, we prefer the first solution with a more 
precise text describing the content of the "v" attribute.

> [CNG] As Paul mentioned ppid is for datachannel not CLUE. Having 
> "CLUE" will help with identification. Given the size of the XML I 
> don't think a few extra bytes for this is a problem.
>
I prefer to keep it because in the future an alternative transport 
protocol could be defined for CLUE and in that way we do not leverage 
the transport channel for the identification of the application protocol.

Roberta

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 23 Jun 2014 17:07:00 +0200

Hello there,

I think Paul's e-mail sheds light on the issue. If I understand correctly, if we were to use CLUE on top of SCTP, we might simply choose a CLUE-protocol identifier (clue protocol ID) at the protocol layer and map (i.e., copy) such an identifier onto the PPID field in the SCTP chunk. Since the PPID is a 32-bit unsigned integer, we should hence register (at IANA) a proper protocol number for CLUE and put such number inside the SCTP chunk.
Though, since we're actually using "CLUE on top of the RtcWeb DataChannel on top of SCTP", we have to stick to the PPID (51) that has been assigned to the DataChannel. This reinforces my personal belief that keeping the yet-to-be-registered "clue protocol identifier" at the telepresence (i.e., CLUE) level is definitely a good idea.

What is your feeling about this?

Simon

> This is an example of the problem of using flat namespaces for hierarchical structures.
> 
> If we were using SCTP directly for CLUE, then it might make sense to assign a CLUE-specific PPID value. But we are instead putting CLUE over data channel. So data channel is the "SCTP user", and we need to adhere to its use of PPIDs.
> 
> If we were to use some different PPID then we couldn't build a CLUE client over RTCWEB, because RTCWEB clients are restricted in how PPIDs are used.
> 
> 	Thanks,
> 	Paul
> 
>> BTW: the registry

                     					       _\\|//_
                           				      ( 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: "Roni Even" <[email-masked]>
Date: Mon, 23 Jun 2014 20:20:39 +0300

Roberta,

Inline

Roni

From: clue [mailto:[email-masked]] On Behalf Of Roberta Presta
Sent: 23 June, 2014 5:44 PM
To: [email-masked]
Subject: Re: [clue] CLUE protocol message type comment

Hi Christian, hi Roni,

please see below.

1.What is the purpose of the ClueId? Is this for displaying the station
name? 

[CNG] The draft says its the identifier of the CP (CLUE participant???)
within the telepresence system. I agree we need some more information about
this. 

The purpose of the identifier is providing a unique name for the CLUE entity
involved in the telepresence session at the CLUE application level.

[Roni Even] Still not sure what is the usage, if we need a unique name for
some purpose we need to define how to create it as a unique string

If it was a displayed string than uniqueness in not an issue.

It has not been conceived (necessarily) for carrying a displayable name of
the CLUE entity.
In the terminology section, in order to make a reference to both a CLUE
endpoint and a CLUE MCU, we have introduced the term "CLUE participant" (for
the sake of brevity/convenience).
These are the definitions we used:

Endpoint  The logical point of final termination through receiving,
      decoding and rendering, and/or initiation through capturing,
      encoding, and sending of media streams.  An endpoint consists of
      one or more physical devices which source and sink media streams,
      and exactly one [RFC4353 <http://tools.ietf.org/html/rfc4353> ]
Participant (which, in turn, includes
      exactly one SIP User Agent).  Endpoints can be anything from
      multiscreen/multicamera room controllers to handheld devices.
 
MCU  Multipoint Control Unit (MCU) - a device that connects two or
      more endpoints together into one single multimedia conference
      [RFC5117 <http://tools.ietf.org/html/rfc5117> ].  An MCU may include a
Mixer [RFC4353 <http://tools.ietf.org/html/rfc4353> ].

I agree we need to be more precise in the describing text.
In our mind, the content of the "v" attribute would be something like "1.0"
or "2.34" (without letters and with a dot separating the major version
number to the minor version one).
However, if we want to use a numeric content, we could split the major
version number and the minor version one, by this way having the following
attributes instead of the single "v" one:

For the sake of brevity, we prefer the first solution with a more precise
text describing the content of the "v" attribute.

[Roni Even] My preference will be on numeric that can be compared and have
less probability of different representations of the same value.

3.Why do we need the fixed attribute "protocol" with the vale CLUE, this is
already known from the ppid (51) of the sctp channel? I assume that if we
will have another transport it will include the opening of a CLUE channel. 

[CNG] As Paul mentioned ppid is for datachannel not CLUE. Having "CLUE" will
help with identification. Given the size of the XML I don't think a few
extra bytes for this is a problem. 

I prefer to keep it because in the future an alternative transport protocol
could be defined for CLUE and in that way we do not leverage the transport
channel for the identification of the application protocol.

[Roni Even] OK

Roberta

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
 <http://www.unina.it/Vademecum5permille> www.unina.it/Vademecum5permille

  --

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 10:47:20 +1000

Hello Roberta,

Please see below.

Regards, Christian

On 24/06/2014 12:44 AM, Roberta Presta wrote:
> It has not been conceived (necessarily) for carrying a displayable 
> name of the CLUE entity.
[CNG] I think we probably need to describe more about the "unique name" 
aspect. What is the intended scope of the "uniqueness"?

> In the terminology section, in order to make a reference to both a 
> CLUE endpoint and a CLUE MCU, we have introduced the term "CLUE 
> participant" (for the sake of brevity/convenience).
>>> 2.The version (v) is defined as string, this is also the type for 
>>> the version in the supported version. Being a string will make 
>>> comparison in option and option response dependent on having the 
>>> same string in both. For example the option can have “v1.0” while 
>>> the response will be “ver 1.0”, should be positive integer also in 
>>> version list type.
>>>
[CNG] I think the first solution would be OK.