Hi Ted,
I was waiting for some feedback from Andy but let's continue the discussion.
Ted Hardie wrote:
> Hi Marc,
>
> Thanks for your quick reply; a few notes in-line below.
>
>
>> Hmm, I see your point. Because I reuse definitions from RFC 3986, you think
>> that these definitions should be used in the same exact way that they are used
>> in RFC 3986, where in fact I merely use them as a short cut to not have to copy
>> them (especially for <host>).
>
> This is part of the issue, and probably the main part. As it stands,
> reusing those elements appears to put portions of the URI into an
> "authority section" model (go here to get the resource specified in
> the path, or returned by the query) when they are really closer to a
> query portion.
So what would be your advice here?
I can 1) add some text to make explicit that I am just referencing the elements
in RFC 3986 and that this is not an <authority> element, 2) copy and past the
elements (i.e. <port> and <host>) from RFC 3986, or something else.
>
>> There was not many opaque URI defined in standard track since RFC 3986, but the
>> IRIS URI (RFC 3981 section 7.1) looks like an opaque URI that reuse components
>> from RFC 2396 and RFC 2732.
>>
>> Anyway, I can copy and rename the definitions that I need from RFC 3986 if it is
>> what is needed.
>>
>
> IRIS is an interesting model here, as it is one of the few others to
> really use S-NAPTR. I've cc'ed Andy on this message to ping him to
> take a look at your draft. IRIS's complexity is pretty substantial on
> a number of fronts, and the URI resolution is certainly
> one of the areas where the complexity has daunted some of those
> interested in the protocol. It's also noteworthy that IRIS created a
> very rigid URI, with a very flexibile resolution mechanism. I'm not
> sure, honestly, that approach was a success.
Yes, I would be interested in this as IRIS was one of the document I use as a
guidance to design the resolution mechanism. (Off-topic: I see a lot of I-Ds
this days proposing to use SRV for various protocols. I wonder why people does
not go directly to NAPTR+SRV, as it is far more flexible for the administrators)
>>>> Where does it get the preference order? The document seems to imply that
>>>> the preference order is associated with an application using the URI, which
>>>> you have restated in 2. below. As stated above, this implies knowledge
>>>> of that preference order in the URI parser, without explicitly passing that
>>>> knowledge. If that is not correct, sorry, but that is how the document reads
>>>> to me at the moment. If that is correct, it seems fragile.
>> The I-D talks about two separate things:
>>
>> First a resolution mechanism, or algorithm, that take in input this 4 elements:
>>
>> - A list of ordered TURN transport
>> - A domain or an IP address
>> - A port that can be empty
>> - A transport that can be empty
>>
>> With this information and the RR retrieved from the network, it builds a list of
>> {IP, port, transport} tuples.
>>
>> The second thing described in the I-D is an URI that permit to conveniently
>> provide the 3 last elements in a unique character string. The URI parser (at
>> the difference of the resolution algorithm) does not care about which TURN
>> protocols are implemented or not, or which one is more efficient or more secure
>> than the other (according to the implementer).
>>
>> +------+ +----------+
>> TURN URI -->|Parser+--> domain/IP -->|Resolution+--> {IP, port, transport} list
>> | +--> port ------->|mechanism |
>> | +--> transport--->| |
>> +------+ | |
>> TURN transport list----------------->| |
>> RRs--------------------------------->| |
>> +----------+
>>
>>>
>>>
>>> 1. The NAPR/SRV/A/AAA RRs that express the preferences of the domain(s)
>>> administrators.
>>>
>>> 2. The ordered list of TURN transports that express the preferences of the
>>> application developers (i.e. the capabilities of the application - what
>>> protocols are implemented - and in case the algorithm cannot decide, the
>>> preferred protocol - the fastest implementation, or more secure, etc...).
>>>
>>> 3. The URI itself that express the preferences of the user of the application
>>> (i.e. specific IP, specific port, specific transport or just the domain if the
>>> user does not care).
>>>
>>> Moving the ordered list of TURN transports to the URI would prevent the
>>> application to provide to the resolution algorithm its own capabilities and
>>> preferences.
>>>
>>> Let me know if you think that the current text does not reflect this
>>> explanation, in which case I will try to add some text.
>
> This is clearer; thanks. My own reading of the current text did not
> reflect this understanding. Reading it, it seemed to me to imply that
> the *URI resolution* relied on knowing the TURN preferences of the
> calling application (your 2). Your text above notes that the URI
> resolution does not depend on this at all; the URI resolution proceeds
> and then the application logic is applied. Is that correct?
Yes.
I am proposing the following text to replace the beginning of section 4. Let me
know if this reflects my explanation above:
"4. Resolution Mechanism
The resolution mechanism is used only to create an allocation. All
other transactions use the IP address, transport and port used for a
successful allocation creation.
The resolution algorithm uses <scheme>, <host>, <port> and
<transport> from the TURN URI as input. It also uses as input a list
ordered by preference of TURN transports (UDP, TCP, TLS) supported
that is provided by the application using the TURN client. This list
reflects the capabilities and preferences of the application code as
opposed to the TURN URI that reflects the preferences of the user of
the application. 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."
--
Marc Petit-Huguenin
Personal email: marc@xxxxxxxxxxxxxxxxxx
Professional email: petithug@xxxxxxx
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf