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.
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).
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.
- Section 6. The title of the section contains the word "Guidelines". To
me, the word Guideline indicates a suggestion, or pure informative text.
So, I am surprise to see quite a lot of normative text (see bullet points
2, 4, etc.). This makes me think that the title is not accurate, and
perhaps you should talk about "Procedures" rather than "Guidelines".
I don't want to "insist" that all clients or servers do things exactly in
the way proscribed. There could be reasons for following slightly different
approaches (e.g. when out-of-band forms of authentication are used). That
said changing "Guidelines" to "Procedures" is fine given that the first
paragraph makes it clear that this procedure is optional.
I understand your comment, I can accept it.
- Section 6, first paragraph, the text reads:
This section describes a procedure that CalDAV or CardDAV clients MAY
use to do their initial configuration based on minimal user input.
This is a relative clause. I don't like to have normative statements
("MAY") in relative clauses, because normative part of it becomes
diluted. If you still want to have normative MAY, split the sentence into
two. My recommendation, you don't need normative, and the "MAY" should be
written in lower case.
As mentioned in the answer to the previous issue, I want to make it clear
that the procedure being described is not required. So how about:
This section describes a procedure that CalDAV or CardDAV clients can
use to do their initial configuration based on minimal user input. This
procedure is OPTIONAL, clients can use alternative methods to accomplish
the appropriate configuration steps.
Your proposal looks very good.
- 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".
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.
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
