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

From: Maarten Wullink <[email-masked]>
Date: Thu, 4 Apr 2013 08:47:46 +0200

I don't know if this has been mentioned before but when looking
through the references i noticed that the url for the CORS refererence
is broken.

it should be http://www.w3.org/TR/cors/ for the latest version or
http://www.w3.org/TR/2013/CR-cors-20130129/ for the version referenced
from the draft.

On 03/27/2013 05:53 PM, Murray S. Kucherawy wrote:
> Colleagues,
> 
> 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:
> 
> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/
> 
> Last call will end Wednesday, April 10th.
> 
> Please review and comment on the draft, even if it is only to say
> on the record "I have reviewed this document thoroughly and it
> looks good."  We would like to have no fewer than five people
> report that they have taken a look at the whole document and
> reported their findings, and will be reticent to send it to the
> IESG without that.  We're also keen to hear from people that have
> implemented the specification as to their views on clarity,
> correctness, and completeness.
> 
> Thanks,
> 
> -MSK and Olaf, your co-chairs
> 
> 
> 
> _______________________________________________ weirds mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/weirds
> 

- -- 
Maarten Wullink MSc|Technical advisor / R&D engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl

---

From: Andy Newton <[email-masked]>
Date: Thu, 4 Apr 2013 09:26:53 +0000

>http://www.w3.org/TR/2013/CR-cors-20130129/ for the version referenced

Thanks Maarten. I'll fix that on the next respin. The ref in the bibxml3
library didn't go to the 2013 version so I had hand fabricated it and in
the process substituted CR for WD.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2013 20:36:34 -0700

Reminder: This closes Wednesday.  If you haven't done a review and
submitted comments but plan to, please don't leave it until the last moment.

So far I've seen quite a lot of review feedback, so we're going to be happy
that it was a thorough WGLC.  Gratitudes to everyone who has taken time to
participate!

What remains is to confirm that people are satisfied with the result.  So,
Andy et al, please post a revision based on the WGLC chatter as soon as
possible after Wednesday so those that have weighed in have a chance to
confirm their issues were addressed either on the list or in the document.

Olaf will be shepherding this one and he'll take it from there.

-MSK, WEIRDS co-chair

On Wed, Mar 27, 2013 at 9:53 AM, Murray S. Kucherawy <[email-masked]>wrote:

> draft-ietf-weirds-http.  A version 03 was just pushed to the datatracker:
>
> Please review and comment on the draft, even if it is only to say on the
> record "I have reviewed this document thoroughly and it looks good."  We
> would like to have no fewer than five people report that they have taken a
> look at the whole document and reported their findings, and will be
> reticent to send it to the IESG without that.  We're also keen to hear from
> people that have implemented the specification as to their views on
> clarity, correctness, and completeness.
>
> Thanks,
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Apr 2013 01:51:53 -0400

On Wed, Mar 27, 2013 at 05:53:22PM +0100, Murray S. Kucherawy wrote

> draft-ietf-weirds-http.  

Dear colleagues,

I have read this draft.  By and large, I think it's in good shape.  I
include some comments here.  These are made without reference to the
other comments that have been made, but I have read those comments and
mostly agree with them.

Section 1.

    Why is the "should" in (4) not a 2119?  When is it ok not to
    return 404?  (Probably just say "it returns a 404 response" or
    else even "a 4xx response" in order not to be doing protocol in
    the intro.)

Section 3.

    There are a few design criteria this document attempts to support.
	This is awkward.  How about "attempts to meet"?

    It isn't clear to me how the third paragraph describes any
    criterion.  How about, "Third, this protocol is intended to be
    able to make use of the range of mechanisms available for use with
    HTTP.  HTTP offers a number. . ."?

Section 4.1

   This specification does not define the responses a server returns
to
   a request with any other media types in the Accept: header, or with
   no Accept: header.

    It'd be nice to say why not.  I think probably because this is
    designed as a machine-to-machine protocol, where the formatting
    for human consumption is supposed to be handled on the client
    side, right?  Is that another criterion that ought to be in
    Section 3?

    It's odd that section 4 doesn't actually say how you send a query.

Section 5

	It is expected that usage of response
   codes and types for this application not defined here will be
   described in subsequent documents.

    Why is that an expectation?  Presumably, if there is an
    expectation that such response codes will be used, we also have an
    expectation of how; why not add them now?

Section 5.2

   A server SHOULD use a 301 response to inform the client of a
   permanent move and a 307 response otherwise.

    Under what circumstances would it be acceptable not to do this?
    If none, this should be a MUST.  I can't think of any such cases.

    The paragraph starting "In other words. . ." doesn't follow from
    the example immediately preceding.  I think ditching the "In other
    words" would help.  Also, the subsequent example is confusing,
    because it looks very like the path segment _is so_ modified.  I
    had to re-read this twice to get it.  Are references for "base"
    and "path segment" needed to clarify?  

Section 5.3

   If a server wishes to respond that it has no information regarding
   the query, it SHOULD return a 404 response code.

    When could it do otherwise?  I think this is MUST.

Section 5.4

   If a server receives a query which it cannot understand, it SHOULD
   return a 400 response code.

    What alternatives are there here?  If none, this is MUST.

Section 6

    Are identifiers case sensitive?  Also, why are the starting
    character rules SHOULD NOT?  Certainly, SHOULD NOT on initial 0-9
    and _ is inconsistent with the ABNF.  Also, the ABNF has no
    indication that you shouldn't start with "xml".

Section 8.2

    I think I already saw agreement to ditch the hand-wavy bits about
    possible encodings and just require that things be Unicode.  Is
    the "should be annotated" better spelled "SHOULD be annotated"?
    (In particular, it might be nice to say, "SHOULD be annotated with
    language identifiers whenever they are available. . . ", which
    gets around the obvious exception case of not having the tag
    available either because there wasn't one or because you couldn't
    do it.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Apr 2013 23:26:32 -0700

My own comments on this draft as an individual.  Apologies if they repeat
those of anyone else (and if so, please ignore accordingly); also, if
there's an older thread with some of these answers that I've managed to
forget about, please point me in the right direction.  I've paid particular
attention to the use of RFC2119 words here, since both of our ADs are
sticklers for that kind of thing.

Section 1:

"HTTP" and "URL" should be expanded on first use in Section 1.

Similarly, "Registration Data" and "Directory Service" should be defined in
this context; i.e., registration of what?  Does this refer to LDAP, which
is also a directory service?

s/should return/returns/

Section 2:

Expand/define "RIRs" on first use.

Can you refer to a definition of "autonomous system" someplace?  I can't
think of one off the top of my head, however.

Section 3:

"Should a result contain more than one result" -- Suggest changing the
first one to "reply" or "response", or the second to "entity".

s/may/can/, just to be safe.

Suggest adding "encryption" to the list in the third paragraph.

Section 4.1:

s/header/header field/ (which we insist on in mail; not certain it's also
common for web)

Section 4.2:

Under what circumstances might one deviate from this SHOULD?  What are the
possible consequences of doing so?

Section 5:

What does "SHOULD understand" mean here?  Since earlier we're saying the
complexity is imposed on servers, and the whole thing should be usable by
clients pretty much as-is, I don't understand what existing clients are
supposed to do with this SHOULD.  Also, same question as above:  Why might
one deviate from this SHOULD, and what are the possible consequences?

Section 5.1:

Same question about this SHOULD.  I think you could get away without the
normative language at all and just say that if the server has the
information, it constructs a success reply as per <some section in> [HTTP],
using a media type selected as per Section 4.1.

Section 5.2:

Same question about this SHOULD.  In fact I think that one ought to be a
MUST; the protocol is effectively broken if you don't do that.

There's one instance of "url" that should be "URL".

I suggest including the example in the last paragraph as an actual HTTP
request and reply.  Happy to help with the xml2rfc part if needed.

Same question about this SHOULD.  I think this one might also be a MUST.

Section 5.3:

Same question about this SHOULD.  The MAY is fine.

Section 5.4:

Same question about this SHOULD.  The MAY is fine.

Section 5.5:

I think the MAY should be a SHOULD, explaining that you might deviate if
you don't want to reveal explicitly that rate limiting is the reason for
the denial of a reply.

The second SHOULD is probably fine; the consequences of a client not
backing off when told to do so are kind of intuitive.

Section 6:

s/may/can/

This SHOULD is well explained; deviating from it has the consequences
implied by the final paragraph.

Section 7.1:

s/as prefix/as a prefix/

See also my earlier remark about the "Intended usage:" definition.  The
example registration appears to have it right.

Section 8.2:

s/should/SHOULD/ or s/should/needs to/, depending on whether you want it to
be normative.

Does RFC2616 or RFC3986 give guidance about how to do what's described
here?  If not, a reference needs to be provided.

Section 8.3:

I think the SHOULD here is probably fine, as long as you just explain that
failing to follow that guidance can produce a response that is effectively
unusable by the client.

Section 10:

The references should be ordered.  I think that's just a matter of adding
"<?rfc sortrefs="yes" ?>" in the meta-data before the <front> section.

Appendix A:

I don't know what the issue being discussed here is.  Can we add a
paragraph at the top describing the problem?  It sounds like an attack, but
I don't know given the text here.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Apr 2013 23:32:39 -0700

> other comments that have been made, but I have read those comments and

If I may ressurect a joke from the Atlanta meeting: "I agree with
everything Andrew just said."  To elaborate on a couple of points:

Section 4.1
>     It's odd that section 4 doesn't actually say how you send a query.

It's described in vague terms in Section 1, but now that you mention it,
including as an appendix or even its own section a complete query-reply
sequence in literal HTTP and JSON might be useful.

>     indication that you shouldn't start with "xml".

I thought the same thing, but didn't mention it myself because the prose
before and after the ABNF further explain the restriction.  I think rather
than coming up with ABNF that disallows the xml prefix, you can add a
comment within the ABNF re-stating the restriction.  In my own documents I
do this like:

thing = (a / b / c) 1*DIGIT whatever
      ; the numeric part MUST fit in a 32-bit integer

-MSK