Re: editorial feedback on draft-mbelshe-httpbis-spdy-00

On 2012-03-24 17:19, William Chan (陈智昌) wrote:
> ...
>     3.2.1 Request
>
>     ":version" - so this essentially positions SPDY as alternate
>     transport layer for HTTP; preserving the version number. Out of
>     curiosity; what is it needed for? Preserving all information when
>     tunneling? The same question applies to ":scheme"...
>
>
> Since it's possible to layer different (future) versions of HTTP on top
> of SPDY, don't we need the ":version" header to preserve all
> information? And similarly, we can conceivably handle different schemes
> over SPDY, such as https (the obvious one), http, ws, wss, etc, so I
> think including ":scheme" is important.

If we see SPDY as a transport layer only yes; if we consider it 
HTTP/2.0; maybe not.

(This applies to http and https; ws and wss are simply different 
protocol you can switch http to).

>     6.2 SETTINGS frame
>
>     This seems to be a feature complete orthogonal to the remainder of
>     the spec. Maybe just remove it?
>
>
> Are you saying you don't feel it's worthwhile calling out the privacy
> consideration of SETTINGS frames? I'm unclear what you mean by being
> orthogonal to the remainder of the spec.

Sorry, wrong spec section. I was wondering whether the SETTINGS frame is 
needed at all.

>     Editorial Nits:
>
>
> Thanks. Updated some of them at
> https://github.com/mbelshe/SPDY-Specification/commit/e940e5d3c1cc930e52bd30b7e03f78573c0e04ad.
>
>
>     Boilerplate: month name needs to be a full name, such as "February"
>
>
> Done
>
>
>     Abstract: should not contain references (so just remove the "[RFC2616]")
>
>
> Done
>
>
>     (speaking of which this should really reference HTTPbis)
>
>     Terminology: "header" -> "header field"
>
>
> Where?

Will have to check...

>
>     has "...see Control Frames for the complete list..."; this should be
>     a proper reference (to where?)
>
>
> Not done yet.
>
>
>     2.2.2 Data frames
>
>     s/MUST send issue/MUST issue/
>
>
> Done
>
>
>     3.2.1
>
>     Cites RFC 1738 for URI syntax; should cite RFC 3986.
>
>
> Done
>
>
>     3.3
>
>     Example host names should use the names reserved for this purpose.
>
>
> Which ones are those?

*.example.com and *.example.org for instance; there's an RFC about that, 
but I'm too lazy to look it up right now :-)

>
>     s/disc cache/cache/
>
>
> I assume you meant s/disk cache/cache/. Done.

Yes.

>     10.
>
>     The TLSNPN reference needs to use the proper reference format for
>     Internet Drafts. I also note that the referenced spec has expired a
>     few months ago; if this is an integral part of SPDY we need to
>     figure out how to make progress on it.
>
>
> Agreed. It languished for awhile, but I think we need to revive the
> TLSNPN discussions.

Best regards, Julian

Received on Sunday, 25 March 2012 09:47:44 UTC