Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http

From: Ernie Dainow <[email-masked]>
Date: Mon, 01 Apr 2013 15:39:01 -0400

Section 8.1
    Clients MAY use IRIs as they see fit, but MUST transform them to 
URIs [RFC3986]

RFC3986 does not address IRIs or URI/IRI transforms, the reference 
should be RFC3987.

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Mon, 1 Apr 2013 20:19:58 +0000

On 3/30/13 1:21 PM, "John Levine" <[email-masked]> wrote:

>>
>>   "Depending on the data format of the response, servers MAY include
>>    data in character sets other than ASCII and languages other than
>>    English (the data format will most likely be in Unicode and almost
>>    certainly languages other than English will be encountered)."
>>
>>This comes out as hand-waving the internationalization
>>question.  From the charter:
>
>I agree that we should either say UTF-8 or nothing.  This isn't a policy
>issue, it's an interop issue.

Then it should say nothing. Our JSON response is UTF-8.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2013 16:24:56 -0400

> Then it should say nothing. Our JSON response is UTF-8.

I would have a minor preference to say that servers that return non-ASCII 
results do so encoded as UTF-8, but it's not a big deal.

Is there any reason not to specify UTF-8 for non-ASCII responses?  Is 
anyone we're aware of planning to use any other encoding?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 8 Apr 2013 07:13:57 +0000

Hi Ernie,

>RFC3986 does not address IRIs or URI/IRI transforms, the reference

The 3986 reference is for URIs.  I will add a 3987 reference for IRIs (and
the transform).

Thanks,
  Byron

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 8 Apr 2013 07:26:09 +0000

Hi John,

>anyone we're aware of planning to use any other encoding?

I've removed the portion of the text referring to non-ASCII data.  The
json-response draft mandates UTF-8, so I don't think the using-http draft
needs to, does it?

  Byron

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 8 Apr 2013 07:27:03 +0000

Hi,

On 30/03/13 4:44 PM, "SM" <[email-masked]> wrote:

>At 09:53 27-03-2013, Murray S. Kucherawy wrote:
>>We would like to initiate a two-week Working Group Last Call on
>>draft-ietf-weirds-http.  A version 03 was just pushed to the datatracker:
>
>The Abstract mentions that:
>
>   "This document describes the usage of the Registration Data Access
>    Protocol (RDAP) using HTTP."
>
>The Introduction Section mentions that:
>
>   "This document describes the usage of HTTP for Registration Data
>    Directory Services running on RESTful web servers."
>
>I guess that the Abstract needs to be updated.

Does this work as an abstract?

	This document describes the RESTful usage of HTTP for the
	Registration Data Access Protocol (RDAP).

>In the Introduction Section:
>
>  "In designing these common usage patterns, this draft endeavours to
>   satisfy requirements for a Registration Data Access Protocol (RDAP)."
>
>As a nit, "draft".

Now "document."

>I read the Introduction Section and I did not find anything explicit
>about the Registration Data Access Protocol.  There is however an
>example which tries to explain how this protocol works.  Where is
>this Registration Data Access Protocol specified?

Appended to the first paragraph of the introduction:

	Together with other documents from the IETF WEIRDS working group,
	this document describes the Registration Data Access Protocol (RDAP).

Does that answer the question?

>In Section 2:
>
>   "[SAC-051] describes a protocol profile of RDAP for Domain Name
>    Registries (DNRs), DNRD-AP."
>
>Please "expand on first use".

-04 will have an expansion of DNRD-AP.

>
>   "This document and others from the IETF WEIRDS working group describe
>    a single protocol, RDAP, for access to the data of both DNRs and
>    Regional Internet Registries (RIRs)."
>
>What does this have to do with terminology?

Removed, as it's now covered in the introduction.

>
>   "RIRs are also often referred to as number resource registries and
>    are responsible for the registration of IP address networks and
>    autonomous system numbers."
>
>What does this have to do with terminology?

Removed.

>In Section 3:
>
>   "Third, HTTP offers a number of transport protocol mechanisms not
>    described further in this document.  Operators are able to make use
>    of these mechanisms according to their local policy, including cache
>    control, authorization, compression, and redirection."
>
>Hmm, that does not sound like transport protocol mechanisms to me.

Could you suggest alternate text in place of "transport protocol" ?

>   "HTTP also benefits from widespread investment in scalability,
>    reliability, and performance, and widespread programmer
>    understanding of client behaviours for RESTful web services,
>    reducing the cost to deploy Registration Data Directory
>    Services and clients."
>
>I heard that one before. :-)  Section 3 starts with "query" and ends
>with HTTP for the naive programmer argument.  I suggest reordering
>the design intent starting from the "top".

Could you suggest text here?

>In Section 4.1:
>
>   "RDAP clients MUST include an Accept: header specifying application/
>    rdap+json, application/json, or both.  Servers receiving an RDAP
>    request MUST return an entity with Content-Type application/
>    rdap+json."
>
>What are RDAP clients?  I guess that the problem is that the draft
>explains it by example (Section 1) instead of specifying it.

Where should it be made explicit that RDAP clients are those adhering
To the behaviours described in the draft?  I could insert:

	Š, that is, clients adhering to the behaviours described
	in this document, Š

Š right there, but I'm not sure that's actually a sensible place to
do so.

>In Section 5:
>
>   "While no standard HTTP response code is forbidden in usage, at a
>    minimum clients SHOULD understand the response codes described
>    in this section."
>
>Why is this a SHOULD?

A client may have valid reasons in particular circumstances to ignore
a particular response code, but servers shouldn't have to provide any
additional service or support to clients that do so.

>In Section 5.1:
>
>   "If a server has the information requested by the client and wishes to
>    respond to the client with the information according to its policies,
>    it SHOULD encode the answer in the format most appropriate according
>    to the standard and defined rules for processing the HTTP Accept
>    header, and return that answer in the body of a 200 response."
>
>I can understand that this working group feels strongly about
>policy.  The question of whether the server is willing to provide the
>information is irrelevant.  If the server is providing the
>information, it returns a body with a 200 response code.  The
>specification does not have to put policy in every place.

Is there new text you'd like to suggest?

>In Section 5.2:
>
>   "If a server wishes to inform a client that the answer to a given
>    query can be found elsewhere, it SHOULD return either a 301 or a 307
>    response code and an HTTP URL in the Location: header."
>
>I see two response codes in the above?  I see a "SHOULD".  I suggest
>being clear or else it will lead to diverging implementations.  The
>above can be restated in terms of what the response code means.
>
>   "A server SHOULD use a 301 response to inform the client of a
>    permanent move and a 307 response otherwise."
>
>This makes it two SHOULDs.  Why can't that be explained with one SHOULD?

Could you provide text that does explain it with one SHOULD?

>In Section 5.3:
>
>   "If a server wishes to respond that it has no information regarding
>    the query, it SHOULD return a 404 response code."
>
>Why is this a SHOULD?

There may be valid circumstances in which a server responds with a
different
code. Perhaps a server might prefer a redirection response with a body
indicating that while it has no information, the client might like to try
a general redirection service instead.

>In Section 5.4:
>
>   "If a server receives a query which it cannot understand, it SHOULD
>    return a 400 response code."
>
>Why is this a SHOULD?  By the way, on reading of the sentence only I
>would say that the 400 response code is not appropriate.

"Cannot understand" should be "cannot interpret as an RDAP query" or
similar.  The intent is that a malformed query be given a "Bad Request"
response.

>In Section 7.1:
>
>   "In accordance with RFC5226, the IANA policy for assigning new values
>    shall be Specification Required: values and their meanings must be
>    documented in an RFC or in some other permanent and readily available
>    reference, in sufficient detail that interoperability between
>    independent implementations is possible."
>
>Note that this is IANA considerations.  I suggest not calling it
>"IANA policy".  I suggest not restating what is in RFC 5226 as it may
>end up being problematic in future (nothing to do with the working
>group).  Why is the policy "specification required"?

What text would you suggest for this section instead?  I believe there is
a separate question raised by the chairs regarding the choice of policy.

>draft-ietf-weirds-using-http-03 is well-written.  My reading of it is
>that it is under-specified.  I suggest framing the draft in terms of
>HTTP.  It will give everyone what he or she wants while disguising
>the draft as an IETF specification. :-)  There isn't a Security
>Considerations section in the draft.  My hypothesis [1] is that a
>draft intended to be published on the Standards Track to make it
>there is very low if there isn't any consideration to security.

There will be a Security Considerations section in the next version,
using the text supplied by Jean-Philippe Dionne.

Thanks for the feedback!

  Byron

---

From: SM <[email-masked]>
Date: Tue, 09 Apr 2013 01:51:26 -0700

Hi Byron,
>         Registration Data Access Protocol (RDAP).

Not really, the text is not aligned with the 
description of the document given in the Introduction section.

>         this document describes the Registration Data Access Protocol (RDAP).

After reading the above text I still do not know 
what the Registration Data Access Protocol is or 
where the protocol is specified.

>Does that answer the question?

No. :-)

>Could you suggest alternate text in place of "transport protocol" ?

It's easier to drop "transport protocol".

>Could you suggest text here?

It's difficult for me to suggest text as I did 
not follow the discussion about design 
intents.  You could start with the third point, 
then have the "First" text and then the "Second" 
text.  If you really want to document the design 
intent you could explain why HTTP is being used 
and how it fits within the constraints.

>Š right there, but I'm not sure that's actually a sensible place to

This is a draft intended for the Standards 
Track.  Such documents are usually about 
protocols which specify the exchange of commands 
and responses between a client and a server.  As 
I mentioned previous, my guess is the draft 
explains "RDAP" by example, hence causing the 
problem where it is not that clear what a RDAP 
client is.  I guess that you might get away with 
the above text or add text to explain the client and server approach.

>additional service or support to clients that do so.

Let me ask it differently; could I be provided 
with examples when the SHOULD does not have to be followed?

>Is there new text you'd like to suggest?

The text could be removed.

>Could you provide text that does explain it with one SHOULD?

I'll get back to you on this one.

>a general redirection service instead.

Ok.

>similar.  The intent is that a malformed query be given a "Bad Request"

The above sounds better.  You could use it instead.

>a separate question raised by the chairs regarding the choice of policy.

  I'll leave it to others to suggest text first 
as I have to catch up with other stuff.  I'll do 
a parse of the text after the end of the WGLC.

BTW, my reply is short.  Let me know if there are 
any part which is unclear or which would benefit from an explanation.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Apr 2013 10:14:03 +0000

>It's easier to drop "transport protocol".

I think more appropriate terminology is "transfer protocol" or even things
a bit more descriptive such as "application transfer protocol" or
"application data transfer protocol".

>the above text or add text to explain the client and server approach.

There seems to be a theme in your comments which is a good observation.
Since this is the first draft in the RDAP series, it might make sense to
beef up the introduction to include a little history of the problem space,
a description of what RDAP is and some foreshadowing of the documents to
come in the series (the query doc, the JSON response doc, and the upcoming
search work).

Just a thought.

-andy

---

From: SM <[email-masked]>
Date: Tue, 09 Apr 2013 10:19:30 -0700

Hi Andy,
>"application data transfer protocol".

I will defer to HTTP folks for the transfer protocol wording or else 
I will have to spend time determining whether the terminology is 
correct or not.

>There seems to be a theme in your comments which is a good observation.

Sorry for rehashing this.  I was trying to provide an explanation.

>come in the series (the query doc, the JSON response doc, and the upcoming

As a quick reaction, the above sounds like a good idea.  Maybe the 
working group was trying to avoid a grand unified specification and, 
in doing so, is considering each draft listed in the charter as 
independent of each other.  In future people reading these documents 
might not have sufficient context to understand how to implement the 
specifications.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Apr 2013 19:09:10 +0000

>might not have sufficient context to understand how to implement the

At one point we had a requirements document, but I think the IESG nixed
it. Absent that, this maybe the most appropriate place to this information.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Apr 2013 12:24:35 -0700

I think we do still want a grand unified specification to the extent that
doing so is practical.  If this is to be considered the core framework
specification and the rest builds upon it, then this is as good a place to
enumerate requirements as any.

But yes, our current plans don't include publication of a separate
requirements document.

-MSK

On Tue, Apr 9, 2013 at 12:09 PM, Andy Newton <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>