Subject: [Gen-art] spec size and organization, was: Fwd: [httpbis] #523: Gen-ART Last Call review draft-ietf-httpbis-p1-messaging-25

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Dec 2013 10:37:22 +0100

>   -General comment 1, I am not very keen with the idea of splitting the
> http
>   standard in so many RFCs.
>
>   It is hard to follow and the protocol is not complex enough to justify
>   these lengthy documents.
>
>   I would have rather see 1 concise standard RFC and few Extension RFCs,
>   Informational or BCP RFCs.
>
>   RFC2616 was ~176 pages, looking at Appendix B of the draft for changes
>   since RFC2616, makes me wonder why so much extra text was required (~300
>   pages).

It depends on how you count. You included repeated boilerplate, 
collected ABNFs, indexes, change logs, etc.

When I count the pages containing the actual spec, I get something like 
235 pages. Please also keep in mind that we have included stuff from 
other specs, such as the authentication framework and CONNECT.

And yes, we could have added more prose or examples. Or we could have 
tried to reduce the size. We could have organized the document 
differently. We could have attempted to have an exhaustive list of 
security considerations. But what we have right now is the result of a 
multi-year work, has passed WGLCs and IETF LC, and I don't think that 
now is the right time to make any additional changes except for fixing 
actual bugs.

(we'll get to the non-editorial feedback later)

Best regards, Julian

---

From: Meral Shirazipour <[email-masked]>
Date: Fri, 6 Dec 2013 21:49:42 +0000

Hi Julian,
   I agree that it may be too late to make drastic changes. Please consider the below comments though, it may help:

"
Constructive comment: 
     -Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best.
"

Best Regards,
Meral

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:37 AM
To: Meral Shirazipour
Cc: HTTP Working Group; General Area Review Team
Subject: spec size and organization, was: Fwd: [httpbis] #523: Gen-ART Last Call review draft-ietf-httpbis-p1-messaging-25

>   -General comment 1, I am not very keen with the idea of splitting 
> the http

It depends on how you count. You included repeated boilerplate, collected ABNFs, indexes, change logs, etc.

When I count the pages containing the actual spec, I get something like
235 pages. Please also keep in mind that we have included stuff from other specs, such as the authentication framework and CONNECT.

And yes, we could have added more prose or examples. Or we could have tried to reduce the size. We could have organized the document differently. We could have attempted to have an exhaustive list of security considerations. But what we have right now is the result of a multi-year work, has passed WGLCs and IETF LC, and I don't think that now is the right time to make any additional changes except for fixing actual bugs.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 08 Dec 2013 10:50:49 +0100

Meral,

some more comments inline:
>   -[Page 5] in the intro, right after it says "This HTTP/1.1 specification
>   obsoletes and moves to historic status RFC 2616....", it would
>   help to add a reference to Appendix B and mention this is where the
>   differences with RFC2616 is listed.

That would be somewhat misleading as we have "changes from 2616" 
sections in all six parts.

>   [Page 5,6], Section 1, this statement is not clear. Are we talking about
>   one HTTP transaction changing info on the server/data base?
>
>   "
>
>   If the communication is considered in isolation, then successful actions
>      ought to be reflected in corresponding changes to the observable
>      interface provided by servers.  However, since multiple clients might
>      act in parallel and perhaps at cross-purposes, we cannot require that
>      such changes be observable beyond the scope of a single response.
>
>      This document describes the architectural elements that are used or
>      referred to in HTTP, defines the "http" and "https" URI schemes,
>      describes overall network operation and connection management, and
>      defines HTTP message framing and forwarding requirements.  Our goal
>      is to define all of the mechanisms necessary for HTTP message
>      handling that are independent of message semantics, thereby defining
>      the complete set of requirements for message parsers and message-
>      forwarding intermediaries.
>   "

We talk about observable changes because that's all what's relevant for 
the protocol.

>   -[Page 11], Section 2.3, "Instead, an interception proxy filters or
>   redirects outgoing TCP port 80 packets (and occasionally other common
> port
>   traffic)."
>
>
>
>   Not sure if "occasionally other common port traffic" means port 443?
> ...

Nope (at least that's my understanding).

>   -[Page 13], not a comment for this draft but in general, has the WG
>   considered a BCP for general error handling, in line with the example
>   given after this sentence:
>
>   "
>
>   HTTP does not define
>      specific error handling mechanisms except when they have a direct
>      impact on security, since different applications of the protocol
>      require different error handling strategies.
>   "

No.

>   -[Page 15], if the statement below is a well-known and often happening
>   scenario it would help to give at least
>   one example of how a client can deduce that by going to a lower
> version of
>   HTTP the problem(?) will be fixed.
>
>   (Note that 2 paragraphs below give examples for the server case.)
>
>   "
>
>   A client MAY send a lower request version if it is known that the
>      server incorrectly implements the HTTP specification, but only after
>      the client has attempted at least one normal request and determined
>      from the response status code or header fields (e.g., Server) that
>      the server improperly handles higher request versions.
>   "

The idea is that if the server is known not to implement 1.1 properly 
than 1.0 is the only available feedback. I thought that's clear enough.

>   -[Page 15],can the server send this error message to refuse service based
>   on e.g. connection identification or other reasons? Then how can the
>   client
>   address the problem if in reality it was not related to the version of
>   HTTP?
>
>   "
>   A server can send a 505
>      (HTTP Version Not Supported) response if it wishes, for any reason,
>      to refuse service of the client's major protocol version.
>   "

This status code is for signaling that the server doesn't support the 
request protocol version. Nothing more.

>   -[Page 16], would it be ok to use MAY? If so it would be clearer to use
>   MAY. : "A recipient MAY..."
>
>   "
>   A recipient can assume that a
>      message with a higher minor version, when sent to a recipient that
>      has not yet indicated support for that higher version, is
>      sufficiently backwards-compatible to be safely processed by any
>      implementation of the same major version.
>   "

Exactly how is that clearer?

>   -[Page 17], Section 2.7.1 first line:   "...for the purpose of minting
>   identifiers".
>
>   suggestion: if another word than "minting" (e.g. generating, creating),
>   could be used it would be easier to read that section.
>
>   (also used in section 2.7.2)

I believe the term "minting" is very commonly used.

>   -[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
>
>   "If the port subcomponent is empty or not given, then TCP port
>      80 is assumed (the default reserved port for WWW services).
>   "

It's a statement of fact, no interop requirement.

>   -[Page 17], "non-interim" , not clear how it can be determines as non-
>   interim (no other message in between? or under a certain peruiod of
> time?)
>
>   Also the term "authoritative" is introduced and should be defined in this
>   context.
>
>   "
>   If the server responds to that request with a non-interim
>      HTTP response message, as described in Section 6 of [Part2], then
>      that response is considered an authoritative answer to the client's
>      request.
>   "

As defined in Part2, Section 6; that is, a status code other that 1xx.

>   -[Page 21], Should it be section 5.3?
>
>   "
>   Recipients typically parse the request-line into its component parts
>      by splitting on whitespace (see Section 3.5), ...
>   "

No.

>   -[Page 21], just verifying is it three or tree?
>
>   "
>   ..., since no whitespace is allowed in the three components.
>   "

It is "three".

>   -[Page 52], refers to an obsoleted RFC. Maybe repeating the
> explanation in
>   this draft would be a better idea.
>
>   "
>   A proxy server MUST NOT maintain a persistent connection with an
>      HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
>      discussion of the problems with the Keep-Alive header field
>      implemented by many HTTP/1.0 clients).
>   "

I think it's preferable not to inline that information; I think some 
people already complained about the spec being too long ;-)

> ...

Best regards, Julian

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 9 Dec 2013 22:42:14 +0000

Hi Julian,
   Thanks for the reply. Please see inline.

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com 

> Sent: Sunday, December 08, 2013 1:51 AM
> To: Meral Shirazipour
> Subject: Re: Fwd: [httpbis] #523: Gen-ART Last Call review draft-ietf-httpbis-
> p1-messaging-25
> 
> Meral,
> 

Actually going back to my comment :
"   -Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation?
      I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best.
"

If you take this suggesting, you can point out that each document contains a list of changes. It only makes the job of the reader easier.

> We talk about observable changes because that's all what's relevant for the
> protocol.

Ok

> >   redirects outgoing TCP port 80 packets (and occasionally other
> > common port
> >   traffic)."
> >
> >
> >

So it is other ports than 80/443? In this case, you may want to add 443 to the text.

> >      require different error handling strategies.

Ok.

> The idea is that if the server is known not to implement 1.1 properly than 1.0
> is the only available feedback. I thought that's clear enough.

Ok.

> This status code is for signaling that the server doesn't support the request
> protocol version. Nothing more.

Ok.
> Exactly how is that clearer?

Please refer to http://tools.ietf.org/html/rfc2119 for extra significance.

> I believe the term "minting" is very commonly used.

I am not the best judge either (but I had to google it).

> It's a statement of fact, no interop requirement.

Ok..

> >   interim (no other message in between? or under a certain peruiod of

"non-interim" = ?

> As defined in Part2, Section 6; that is, a status code other that 1xx.

"authoritative" means coming from origin server?

> >   ..., since no whitespace is allowed in the three components.

Ok.

> I think it's preferable not to inline that information; I think some people
> already complained about the spec being too long ;-)
> 

Fair enough:)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Dec 2013 18:41:23 +0200

Meral, Julian,

>     -Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3…

FWIW, I think this would be useful.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Dec 2013 18:47:18 +0200

Meral: thank you for your detailed review. You have done many reviews on this document set. Very much appreciated!

>      I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best.

I agree that we should not change the structure of the documents at this stage. As I said in the other mail, I think a list of other documents and their primary use might have been a useful thing to do.

> So it is other ports than 80/443? In this case, you may want to add 443 to the text.

I think the situation is that we have multiple such ports… not sure mentioning the specific ones is necessary.

> Please refer to http://tools.ietf.org/html/rfc2119 for extra significance.

I think "MAY" would be my choice, but I understand the authors if they have a reason to try to stay with language and requirements that existing documents and implementations have used.

> I am not the best judge either (but I had to google it).

I think this term is occasionally used, probably ok.

> "authoritative" means coming from origin server?

Was there a response, Julian?

Jari

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Dec 2013 18:00:08 +0100

>>>    interim (no other message in between? or under a certain peruiod of

Non-1xx.

See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.6.2>

> "authoritative" means coming from origin server?

No, it means "final" as opposed to "interim".

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Dec 2013 11:48:15 -0800

On Dec 19, 2013, at 9:00 AM, Julian Reschke wrote:

> See <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.6.2>
> 

In the quote from p1, "authoritative" is used according to its
common English definition:

  https://www.google.com/search?q=define+authoritative

and doesn't imply that the server is the origin server (it could
be a CDN), though it supposedly operates on behalf of the origin.

....Roy