W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Editorial Issues: Section 4.2.2

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 24 Apr 2013 16:45:31 -0700
Message-ID: <CABkgnnWTV_Fcy32nRVjYqa+hK7RpUZt-1K3gRTgAEuCWz7fRYw@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
If you believe that the issue is purely editorial - a wording change,
moving stuff into more logical places, etc... - then just open the
pull request.  Poke an editor if you see it neglected.

If you aren't sure, come to the list.  You might get a "yeah, that's
just editorial" response, but it gives people a chance to discuss it.

Key goals are: a) conduct technical discussions on the list, and b)
conduct technical discussions on the list.  Too much editorial (and
procedural) stuff drives down the signal to noise ratio.  Too little
and you risk having edits go in without working group input.

On 24 April 2013 11:19, James M Snell <jasnell@gmail.com> wrote:
> On Wed, Apr 24, 2013 at 11:13 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> Hey James,
>> On 24 April 2013 10:11, James M Snell <jasnell@gmail.com> wrote:
>>> Recommend reworking this to:
>>>   The following fields MUST be present in all HTTP requests:
>>>   ":method":  the HTTP method for this request (e.g.  "GET", "POST",
>>>   "HEAD", etc) ([HTTP-p2], Section 4)
>>>   ":path":  the request-target for this URI with "/"
>>>   prefixed (see [HTTP-p1], Section 3.1.1).  For example, for
>>>   "http://www.google.com/search?q=dogs" the path would be
>>>   "/search?q=dogs". [[anchor26: what forms of the HTTPbis
>>>   request-target are allowed here?]]
>>>   ":host":  the host and optional port portions (see [RFC3986],
>>>   Section 3.2) of the URI for this request (e.g. "www.google.com:
>>>   1234").  This header field is the same as the HTTP 'Host'
>>>   header field ([HTTP-p1], Section 5.4).
>>>   ":scheme":  the scheme portion of the URI for this request (e.g.
>>>   "https")
>> Feel free to send a pull request for this.  I see no reason not to
>> make this sort of change.
>> There are a lot of less obvious edits of this nature.  From my
>> perspective, there are too many to fix at once.  For instance, the
>> entirety of Section 5 needs to be moved to more relevant locations.
>> There's no reason why you can't just raise an issue or pull request
>> for editorial stuff that bugs you.
> I can submit pull requests. Is there a specific process the editors
> would like re: pull requests? For instance, posting a note here on
> list when a pull request is submitted so that everyone can be aware of
> the suggested change?
> - James
Received on Wednesday, 24 April 2013 23:46:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC