Subject: [BEHAVE] TURN-06 submitted

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 11:40:03 -0500

I have just submitted TURN-06 to the archives. It should appear shortly.

Below is a list of the major changes since TURN-05. The main goal of  
this revision has been to reflect the decisions made on the mailing  
list and confirmed during the conf call of 20 Dec 2007.

There are still quite a few open issues that we need to resolve.  
These are now listed in a new section in the document. Almost all of  
these issues are currently being discussed in a thread on the mailing  
list.

In the interest of time, the authors have elected to release this  
revision in a more "raw" state that they would normally prefer. As a  
result, there are some rough spots in the presentation. The authors  
elected to do this in order to make more rapid progress on the open  
issues.

There is a conference call scheduled for Monday, January 28th to  
discuss the open issues in the document. See separate e-mail.

- Philip

Major changes since TURN-05:
    o  Changed the mechanism for allocating channels to the one proposed
       by Eric Rescorla at the Dec 2007 IETF meeting.

    o  Removed the framing mechanism (which was used to frame all
       messages) and replaced it with the ChannelData message.  As part
       of this change, noted that the demux of ChannelData messages from
       TURN messages can be done using the first two bits of the  
message.

    o  Rewrote the sections on transmitted and receiving data as a  
result
       of the above to changes, splitting it into a section on Send and
       Data Indications and a separate section on channels.

    o  Clarified the handling of Allocate Request messages.  In
       particular, subsequent Allocate Request messages over UDP with  
the
       same transaction id are not an error but a retransmission.

    o  Restricted the range of ports available for allocation to the
       Dynamic and/or Private Port range, and noted when ports outside
       this range can be used.

    o  Changed the format of the REQUESTED-TRANSPORT attribute.  The
       previous version used 00 for UDP and 01 for TCP; the new version
       uses protocol numbers from the IANA protocol number registry.   
The
       format of the attribute also changed.

    o  Made a large number of changes to the non-normative portion of  
the
       document to reflect technical changes and improve the
       presentation.

    o  Added the Issues section.

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 22 Jan 2008 10:14:09 -0800

Hi Philip,

> I have just submitted TURN-06 to the archives. It should appear shortly.

The ChannelBind codepoint is missing in section 8 as are 3 response
codes in section 10, meaning that this spec is unimplementable.  No
running code that be written on top of an unimplementable spec.

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 14:20:36 -0500

Hi Marc:

Thanks for catching the missing ChannelBind codepoint. I suggest we  
just re-use the ChannelConfirmation codepoint of TURN-05, and thus  
assign it a code point of 0x009. I'll add that to my TURN-07 draft.

As far as the three response codes, those are actually the subject of  
a debate between Rohan and myself. I'll start a separate thread on  
this issue.

Are these missing codepoints a big issue? There are a number of open  
issues in the document, and we are really hoping to close a number of  
them and issue a TURN-07 soon. So you really want to implement  
TURN-06, or would you wait until things settle down a bit?

And this raises another issue. I currently consider TURN to be in  
flux, and am assuming that no one is actually deploying the spec. So,  
unlike early versions of ICE, I am not thinking about how to detect  
version numbering or backwards compatibility, etc.  Does anyone feel  
I should think otherwise?

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 22 Jan 2008 11:29:13 -0800

Philip Matthews wrote:
> Hi Marc:
> 
> Thanks for catching the missing ChannelBind codepoint. I suggest we just
> re-use the ChannelConfirmation codepoint of TURN-05, and thus assign it
> a code point of 0x009. I'll add that to my TURN-07 draft.
> 
> As far as the three response codes, those are actually the subject of a
> debate between Rohan and myself. I'll start a separate thread on this
> issue.

Ok, but that does not prevent to assign a value to the response code.

> them and issue a TURN-07 soon. So you really want to implement TURN-06,
> or would you wait until things settle down a bit?

Well, I am an implementer, not a network protocol designer as all of
you.  The only way to be sure if something works that I know of is to
implement and test it.  So yes, I am implementing TURN-06, and plan to
offer accounts on my TURN server to TURN client implementers just after
the conference call (unless there is another complete change).

> 
> And this raises another issue. I currently consider TURN to be in flux,
> and am assuming that no one is actually deploying the spec. So, unlike
> early versions of ICE, I am not thinking about how to detect version
> numbering or backwards compatibility, etc.  Does anyone feel I should
> think otherwise?

We already talked about this I think, and there is no need for backward
compatibility between I-Ds.  People implementing the I-D know the risk
and plan accordingly.

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 14:48:17 -0500

OK. Let's try to resolve the error code issue quickly then.

- Philip