Subject: [clue] PPID in draft-ietf-clue-datachannel-00

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

Hi,

Looking at the discussion in RTCweb I understand that SCTP PPID=51 is for
UTF-16 string and they may register with IANA a new PPID for utf-8.

I understand that from the RTCweb perspective defining a general string PPID
make sense. 

The CLUE document in table 1 calls this  PPID 51 - CLUE protocol.

The question is why we use  a general string PPID and not register a SCTP
ppid for CLUE? 

Roni

---

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

On 6/23/14 8:30 AM, Roni Even wrote:
> Hi,
>
> Looking at the discussion in RTCweb I understand that SCTP PPID=51 is
> for UTF-16 string and they may register with IANA a new PPID for utf-8.
>
> I understand that from the RTCweb perspective defining a general string
> PPID make sense.
>

We can use anything that is allowed by rtcweb for data channels. We only 
need a string format, and for now there is only one string format we can 
choose. If another string format becomes available we could update to 
use that one instead, or leave it as a choice.

> The question is why we use  a general string PPID and not register a
> SCTP ppid for CLUE?

As I just replied in another message, then we would not be in compliance 
with the data channel spec, and couldn't build clue clients on top of 
rtcweb.

	Thanks,
	Paul

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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 23 Jun 2014 17:56:22 +0300

Paul,
I am OK with the current approach but I am not sure that the reasons you
give prevent using different PPID

https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.6
says

"The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
   interpretation of the "Payload data".  For identifying a JavaScript
   string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for
   JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary"
   MUST be used (see Section 8)."

We are not sending a JavaScript string so it is not clear that we cannot
send a CLUE XML based message using a different PPID (not 51). 

I am not too familiar with Java script so I was wondering if we will need to
do XML to string to send a clue message and string to XML when receiving a
CLUE message? At least I saw such methods in java script.

Still your major point is that if we use WebRTC string ppid is will be
interoperable in webrtc environment, I do not see the problem since both
sides need to support CLUE anyhow so they can have any PPID if the rtcweb
data channel document does not prevent it.

Again we can keep the "CLUE" protocol in the CLUE message header.

Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 23 June, 2014 5:11 PM
> To: [email-masked]
> Subject: Re: [clue] PPID in draft-ietf-clue-datachannel-00
> 
> > I understand that from the RTCweb perspective defining a general
> > string PPID make sense.
> >
need
> a string format, and for now there is only one string format we can
choose. If
> another string format becomes available we could update to use that one
> instead, or leave it as a choice.
> 
with
> the data channel spec, and couldn't build clue clients on top of rtcweb.
> 
> 	Thanks,
> 	Paul
> 
> > Roni
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2014 11:46:44 -0400

> send a CLUE XML based message using a different PPID (not 51).

My understanding (may be wrong) is that the browser implementation of 
the data channel will determine what PPID to use based on the javascript 
datatype used to provide the payload to the API. The javascript 
application won't have direct control over the PPID.

> CLUE message? At least I saw such methods in java script.

I'm not sure either, but I assume either that conversion will either be 
done explicitly or implicitly via coercion during the call to the API.

> data channel document does not prevent it.

If the rtcweb allows explicit control of the PPID and use of any PPID 
value then I agree. I don't think that is the case. (Where is the actual 
javascript data channel API specification?)

> Again we can keep the "CLUE" protocol in the CLUE message header.

Sure. Clearly the discussion has ceased to be about that.

	Thanks,
	Paul

---

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

Hi Paul,
Looking at the discussion about ppid in the RTCweb mailing list I got the
following points
1. The application have no control on the PPID so we MUST use the ones
specified by webrtc and do the right conversions
2. The current DOMstring PPID=51 is specified as UTF-16 string and I think
that the current approach will be to define a new PPID for UTF-8 string
possibly also not to name it as DOMstring but utf-8 string

Is this correct?
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 23 June, 2014 6:47 PM
> To: Roni Even; [email-masked]
> > I am OK with the current approach but I am not sure that the reasons
> > you give prevent using different PPID
> >
> >
> > We are not sending a JavaScript string so it is not clear that we
> > cannot send a CLUE XML based message using a different PPID (not 51).
> 
> My understanding (may be wrong) is that the browser implementation of the
> data channel will determine what PPID to use based on the javascript
datatype
> used to provide the payload to the API. The javascript application won't
have
> direct control over the PPID.
> 
> > I am not too familiar with Java script so I was wondering if we will
> > need to do XML to string to send a clue message and string to XML when
> > receiving a CLUE message? At least I saw such methods in java script.
> 
done
> explicitly or implicitly via coercion during the call to the API.
> 
> > interoperable in webrtc environment, I do not see the problem since
> > both sides need to support CLUE anyhow so they can have any PPID if
> > the rtcweb data channel document does not prevent it.
> 
value then I
> agree. I don't think that is the case. (Where is the actual javascript
data
> channel API specification?)
> 
> >>> Looking at the discussion in RTCweb I understand that SCTP PPID=51
> >>> is for UTF-16 string and they may register with IANA a new PPID for
utf-8.
> >> another string format becomes available we could update to use that
> >> one instead, or leave it as a choice.
> >>

---

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

> possibly also not to name it as DOMstring but utf-8 string

It is consistent with my understanding.

I don't know for sure whether the UTF-8 is intended to *replace* UTF-16, 
or is to another alternative. My recollection from discussions in London 
is that it was intended, at least in the long term, to replace. But I 
expect they have a migration issue since there are implementations deployed.

	Thanks,
	Paul