Re: [Uri-review] End of Last Call for draft-ietf-behave-turn-uri

[Marc Petit-Huguenin <[e-mail]>]

Ted Hardie wrote:
> On Thu, Nov 12, 2009 at 11:11 PM, Marc Petit-Huguenin <[e-mail]> wrote:
>> Hi Roy,
>>
>> Roy T. Fielding wrote:
>>> On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote:
>>>

[...]

>>> Umm, why don't you just use the RFC3986 ABNF directly, make it
>>> a normative dependency, and not recreate that which is already
>>> a standard?
>> Ted Hardie suggested the exact opposite.
> 
> Howdy,
> 
> Sorry for the episodic nature of these comments; jet-lag combined with
> day-job issues have really taken their toll on my response time.  My apologies
> especially that I wasn't able to discuss this in person in Hiroshima with
> any of the relevant folks--I had to leave early.
> 
> The thrust of my list comment was intended to find some way of distinguishing
> the way this URI scheme uses its components.  Using new ABNF productions
> was one fairly low-impact way of signaling these were different, but I believe
> that re-using the same names and copying the ABNF doesn't really qualify
> as new productions.  At the very least, I think you'd need new names that
> highlighted the roles these play; even that is not much of a signal
> once these are
> in the wild.
> 
> As you recall, I'd originally suggested that the URI mailing list be
> cc'ed for ideas
> on other approaches, and Roy is certainly one of the folks that I'd hoped would
> review it there.  If I can help by setting up a conference call or
> otherwise getting
> some more real-time communication going, please let me know.  I remain hopeful
> that we can find some way of approaching the problem that doesn't involve
> a complete pushback.  I apologize again for any delay my own response time has
> induced.

Well, I had other private discussions about this, and I am now seriously
considering dropping the TURN/TURNS URI and just keeping the resolution
mechanism.  The only purpose of the URI is to carry the 3 pieces of information
needed for the resolution algorithm (host/IP address, port and TURN transport),
but this 3 pieces of information can be stored in the client configuration
individually.  That is not as neat as having one, single character string, but
seeing all the difficulties in having the syntax approved, this is probably the
best solution.  I used RFC 4501 as a guideline for this design, but now people
are telling me that a DNS URI was a bad idea...

So unless someone objects to this, the next version (probably released Monday
23rd) will be without the URI stuff.

The only problem is that the name of the I-D (draft-ietf-turn-uri) will no
longer reflect the content.  Dan, any suggestion here?

Thanks.

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org