Hi Miguel,
--On September 9, 2010 10:46:54 AM +0200 "Miguel A. Garcia"
<[email protected]> wrote:
Hi Cyrus.
See more comments inline. I have delete those comments that do not
require further discussion.
On 08/09/2010 16:38, Cyrus Daboo wrote:
Hi Miguel,
Thank you for your detailed review.
--On September 8, 2010 3:25:49 PM +0200 "Miguel A. Garcia"
<[email protected]> wrote:
Minor issues:
- A question on Section 4, 2nd paragraph. The text says how to _use_ the
existing "context path" with the received "path" in the TXT record.
First, I am not sure that the word "use" is good enough here. Do you
mean "replace"?
I think "use" is correct here, as at that point there is no "context
path" already defined that could be replaced.
I not comfortable yet. Look at the text:
When present, clients MUST use the "path" value as the
"context path" for the service.
My question is related to the ambiguity of "use". I don't know what "use"
really means. "Use" could refer to dispose, delete, replace. You have a
normative strength "MUST" with an ambiguous verb. I can assure you that
different implementations will "use" in a different way.
I am trying to suggest you something, please verify if this is your
intention. Do you want to say that:
When the "path" value is present, clients building a URI MUST use
the value of the "path" as a "context path" for the service.
I have changed this text to:
When present, clients MUST use the "path" value as the "context path"
for the service in HTTP requests.
In addition, I have added the following as the second sentence in paragraph
4 of section 1 to define "context path":
Thus a client needs to be able to determine the complete path
component of the Request-URI to use in HTTP requests: the "context
path".
I think the combination of the definition and the additional text to the
"use" sentence clarify the intent.
Second, I don't know what is a "context path" and where it is
defined, so, can you add a reference to a document that defines context
path?
Paragraph 5 of the Introduction introduces the term "context path". I am
not aware of any formal definition of that. Perhaps "service path" would
be a better term.
I thought the term could have been defined in some RFC. But since this is
not the case, the text in Paragraph 5 does not define "context path". So,
you need to find a formal definition of it, otherwise I don't know how to
use the "path" as "context path", if I don't know what a "context path"
is. In principle, I would suggest to inspire in the generic URI syntax
(RFC 3986?), which describes a "scheme" and a "path". Perhaps you can
define "context path" as a subset of "path" that has some properties
(which you would need to enumerate, I don't know which ones they are,
here is my problem).
See above for addition to section 1 to define "context path".
Third, it is not clear to me that even with the two above
clarifications, there is a unique way to build a new URI with the
information received in the TXT record. Can you demonstrate that there
is only one way of creating this URI with the received "path", so that
all the implementations will obtain the same result?
There is only one path value specified in the TXT record so there is only
one way to build the HTTP request-URI (using the SRV host/port and the
TXT path= values). I don't see where there are "multiple" ways to do
that.
This comment is a consequence of the previous ones. If you assume that a
context path is a subset of the path, do we know which subset of the path
is the context path all about? If we clarify the definition of context
path, I think we can clear this comment as well.
There is no "subset" of the path - the "context path" IS the full path. I
think use of the term "complete path" in the new definition of "context
path" clarifies that.
- In Section 6, bullet point 3, the text describes a client making an
SRV request and receiving SRV and TXT records in a response. So, the
client receives TXT even when it didn't ask for it. In principle,
draft-cheshire-dnsext-dns-sd does not recommend the inclusion of TXT
records when SRV is requested. So, I wonder if there is a real use case
for this paragraph.
Actually my intent was that the client needs to do another query for the
TXT record. So how about changing the text to:
When an SRV lookup is done and a valid SRV record returned,
the client MUST also make a query for a corresponding
TXT record and check for a "path" key in its value.
Very good proposal. Go ahead with it. Just replace the last sentence:
"... TXT record and check for the presence of a "path" key in the
response".
OK, text changed as per suggestion.
Question, do you need to explicitly say what to do with the "path" key at
this point in time, or is it obvious? My point is that the word "check"
is ambiguous and does not indicate what to do with the "path" key value.
Well the next sentence after the text tweaked above is:
If present, the value of the "path" key is used for the initial
"context path".
I think that covers it.
FYI Attached is a diff of my current working copy with the last published
-08 version showing the current proposed changes (this includes one or two
items from IESG review too).
