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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Ted Hardie
> Sent: Thursday, October 15, 2009 2:34 PM
> To: Magnus Westerlund
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
> <[e-mail]> 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  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > 
> ----------------------------------------------------------------------
> >
> > 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
> > [e-mail] mailing lists by 2009-10-29. Exceptionally,
> > comments may be sent to [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >
> > _______________________________________________
> > Uri-review mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/uri-review
> >
> >
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf