ietf
[Top] [All Lists]

RE: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri(Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers)to Proposed Standard]

2009-10-15 21:03:47
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
Behalf Of Ted Hardie
Sent: Thursday, October 15, 2009 2:34 PM
To: Magnus Westerlund
Cc: uri-review(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
app-ads(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: [Uri-review] [Fwd: [BEHAVE] Last Call: 
draft-ietf-behave-turn-uri(Traversal Using Relays around NAT 
(TURN) Uniform Resource Identifiers)to Proposed Standard]

Howdy,

I do not believe this document is ready for publication, as I believe
the URI scheme documentation needs work.  As it stands now, the
scheme-specific processing required for this scheme is so great that I
believe a standard URI parser will not work with the scheme as it is
intended.  Looking, for example, at the CPAN module PERL::URI, the
operation of the standard behavior for path and port seem likely to
work contrary to this scheme's intention.  I also could not follow the
details of how this would work in relation to a DDDS remote hosting
option, as mentioned in section 1, and I believe that more descriptive
text may be required.

One area of particular concern is this:

"The URI resolution algorithm uses <scheme>, <host>, <port> and
   <transport> as input.  It also uses as input a list ordered by
   preference of TURN transports (UDP, TCP, TLS) supported by the
   application using the TURN client.  The output of the 
algorithm is a
   list of {IP address, transport, port} tuples that a TURN client can
   try in order to create an allocation on a TURN server."

Having a URI resolution method rely on a preference order associated
with a calling application seems very fragile.  There seems 
to be no way
to guarantee that the information on calling application 
would be preserved in
passing the URI to a parser.  If this input list is required, 
I suspect that
that it must be noted within a URI parameter to avoid 
unexpected or incorrect
results.

Thanks for your review comments.

Since this mechanism involves a fairly distinctive URI resolution
mechanism, I suggest that this document also be reviewed by the URI
mailing list, in addition to URI-review.  It seems more likely to be
able to discuss how to best meet the requirements expressed within a
URI syntax more likely to be handled correctly by parsers already
deployed.

I requested review by uri-review on 30-JUL-2009, per your earlier
suggestion.  However, we received no review comments from that 
request, which was mentioned in the PROTO write-up for this
document.  This is my only experience with uri-review; it was
easy and painless, because we received no comments.

Somebody please shake the tree that is uri-review so that we can
progress this document.

-d


regards,

Ted Hardie

On Thu, Oct 15, 2009 at 7:58 AM, Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> wrote:
Hi,

As responsible AD I would really appreciate an URI review of the two
proposed URI schemes.

Thanks

Magnus Westerlund

IETF Transport Area Director

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: 
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com

----------------------------------------------------------------------

The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:

- 'Traversal Using Relays around NAT (TURN) Uniform 
Resource Identifiers '
  <draft-ietf-behave-turn-uri-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, 
and solicits
final comments on this action.  Please send substantive 
comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-10-29. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either 
case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via

http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-03.txt


IESG discussion can be tracked via

https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=18080&rfc_flag=0

_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave


_______________________________________________
Uri-review mailing list
Uri-review(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/uri-review


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>