Hi Margaret,

Margaret Wasserman wrote:
> 
> Hi Marc,
> 
> On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote:

[...]

>> I still think that examples must not be added until the text is so
>> clear that
>> the examples are useless.
> 
> If no one else supports my position that example would be valuable, I will
> yield to your opinion on this point, as document editor.

I will add examples (it's easy as all the examples are automatically generated
by my reference implementation, to be sure that they are valid), but my point is
that the text should not rely on examples, as they are not normative.

[...]

>>>> this specification modifies the SRV algorithm by recommending an A
>>>> and AAAA query.  If the TURN client cannot contact a TURN server at
>>>> any of the IP address, port and transport tuples returned by the SRV
>>>> algorithm then the resolution MUST stop with an error."
>>>
>>> This has the same problem as the one you fixed in section 4.  We
>>> don't return an error if the SRV fails, only if both the SRV lookup
>>> and the subsequent A/AAAA lookup fail, right?
>>
>> I disagree here.  The text says "SRV algorithm" not "SRV query".  The
>> fallback
>> to A is part of the SRV algorithm, not something added by this text,
>> so the
>> tuples returned by the SRV algorithm eventually contains the result of
>> the A
>> query (and AAAA as modified by the text).
>>
>> And thinking of it, I am not sure I should have modified step 4, but
>> see below.
> 
> I understand what you are trying to say, but you haven't defined the
> term "SRV
> algorithm" (to include the A/AAAA lookup) anywhere, so it is my opinion
> that
> the meaning of this paragraph is still ambiguous.  This is the type of
> thing
> that I think could be made very clear by an example, but if you don't want
> to include examples, you need to be very clear about the step by step
> process in each of these paragraphs.

Here's the new proposed text:

"3.  If <host> is a domain name and <port> is not defined but
     <transport> is defined, then the SRV algorithm defined in
     [RFC2782] is used to generate a list of IP address and port
     tuples. <host> is used as Name, <scheme> as Service and
     <transport> as Protocol in the SRV algorithm. <scheme> and
     <transport> are converted to a TURN transport as specified in
     Table 1 and this transport is used with each tuple for contacting
     the TURN server.  The SRV algorithm recommends doing an A query
     if the SRV query returns an error or no SRV RR; in this case the
     default port declared in [I-D.ietf-behave-turn] for the SRV
     service name defined in <scheme> MUST be used for contacting the
     TURN server.  Also in this case, this specification modifies the
     SRV algorithm by recommending an A and AAAA query.  If the TURN
     client cannot contact a TURN server at any of the IP address and
     port tuples returned by the SRV algorithm with the transport
     converted from the <scheme> and <transport> then the resolution
     MUST stop with an error."


> I am not sure that it is valid to indicate that section 4 stops with an
> error,
> and then indicate that there are some cases where you would
> continue (presumably) without an error...
> 
> Maybe you should add a line to section 4, in the middle, indicating that
> if the NAPTR query returns an error, you should proceed to step 5?

Here's the new proposed text:

"4.  If <host> is a domain name and <port> and <transport> are not
     defined, then <host> is converted to an ordered list of IP
     address, port and transport tuples via the S-NAPTR algorithm
     defined in [RFC3958] by using <host> as the initial target domain
     name and "RELAY" as the Application Service Tag. The filtered
     list of TURN transports supported by the application are
     converted in Application Protocol Tags by using "turn.udp" if the
     TURN transport is UDP, "turn.tcp" if the TURN transport is TCP
     and "turn.tls" if the TURN transport is TLS.  The order to try
     the Application Protocol Tags is provided by the ranking of the
     first set of NAPTR records.  If multiple Application Protocol
     Tags have the same ranking, the preferred order set by the
     application is used.  If the first NAPTR query fails, the
     processing continues in step 5.  If the TURN client cannot
     contact a TURN server with any of the IP address, port and
     transport tuples returned by the S-NAPTR algorithm then the
     resolution MUST stop with an error.

 5.  If the first NAPTR query in the previous step does not return any
     result then the SRV algorithm defined in [RFC2782] is used to
     generate a list of IP address and port tuples.  The SRV algorithm
     is applied by using each transport in the filtered list of TURN
     transports supported by the application for the Protocol, <host>
     for the Name and <scheme> for the Service.  The same transport
     that was used to generate a list of tuples is used with each of
     this tuples for contacting the TURN server.  The SRV algorithm
     recommends doing an A query if the SRV query returns an error or
     no SRV RR; in this case the default port declared in
     [I-D.ietf-behave-turn] for the SRV service name defined in
     <scheme> MUST be used for contacting the TURN server.  Also in
     this case, this specification modifies the SRV algorithm by
     recommending an A and AAAA query.  If the TURN client cannot
     contact a TURN server at any of the IP address and port tuples
     returned by the SRV algorithm with the transports from the
     filtered list then the resolution MUST stop with an error."

> 
> Also, you mention "the first NAPTR query".  Will there be more than one?

NAPTR queries are recursive. See RFC 3958 section 2.2.3.

> If so, why and what will the subsequent queries contain?

RFC 3958 section 2.2.4 explains what to do if the subsequent NAPTR queries fails
(i.e. backtrack), this is why the turn-uri I-D explains only what should be done
when the first NAPTR query fails.

>>>
>>> It is still not clear to me, from your text, how the S-NAPTR lookup
>>> would be constructed, but that may reflect my limited understanding
>>> of S-NAPTR.
> 
> Could you give me an example of how the NAPTR query would be
> constructed from the URI?

for TURN URI "turn:example.org":

$host -t NAPTR example.org

example.org has NAPTR record 100 10 "" "RELAY:turn.udp" "" datagram.example.org.
example.org has NAPTR record 200 10 "" "RELAY:turn.tcp:turn.tls" ""
stream.example.org.

The Application Service Tag and Application Protocol Tags are used by the RFC
3958 algorithm, not to generate a NAPTR query.

-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org