RE: Sticky header draft -- as an attachment

Here are my comments, in line number order:

1) Line 76, "ABSTRACT":  "proposed" should be "proposes".

2) Lines 85-86, "ABSTRACT":
>This draft proposes a way
>to compress header names using tersely encoded abbreviations.
Each time I read this, I expect to see an algorithm at the end of the draft 
for automatically deriving the compressed names for new headers.  So I am 
disappointed when I don't :(.  Although it is more wordy, I would propose:
 This draft proposes a set of tersely encoded abbreviations for
 header names, along with recommendations for compressing the names of
 headers that may be added to HTTP in the future.

3) Line 140, "1. Introduction":  To avoid a forward reference, I would 
suggest:
>for the Connection header ("sticky"),
                           ^^^^^^^^^^

4) Lines 150-151, "1. Introduction":  Missing word:
>and their use must be negotiated
           ^^^
5) Lines 218-222, "2.1 Basic operation":
>To send a message without
>one of the remembered message-headers, send a message-header line
>consisting of just the field-name and a colon, and no field-value; upon
>reception of such a line, the message-header in the remembered set with
>that field-name is deleted.
Adding "for the duration of this message" at the end of this sentence would 
clear up any potential ambiguity as to whether the message-header is 
permanently deleted (it sounded like that to me on initial reading).

6) Lines 275-277, "2.3 Changing the sticky-header set":
>There is no way to remove
>headers from the sticky header set, or to add more headers to the set
>after a context is created.
Since headers can be removed temporarily, but no headers can be added (even 
temporarily), I would suggest instead:
 There is no way to add more headers to the sticky header set after
 a context is created.  Headers can be removed from the sticky header
 set only on a per-message basis.

7) Lines 489-492, "5. Header name compression":
>There
>can be 18 more headers added to HTTP and still only require one digit;
>at that point if more are added a second digit can handle up to 4096
>headers.
This phrasing feels awkward.  Would:
 Up to 18 more headers can be added to HTTP while still requiring
 only a single digit (+ a '#') for their compressed representation.
 Adding a second digit would handle up to 4096 total HTTP headers.
flow better?

8) Lines 505-510, "6. Security Considerations":
>This latter attack could only work
>with the non-secure authentication methods anyway so it is not
>considered to be a serious concern.
As I understand it, what I think you were trying to say was:
 This latter attack could only work
 with unencrypted communications methods anyway so it is not
      ^^^^^^^^^^^^^^^^^^^^^^^^^^
 considered to be a serious concern.
Whether HTTP is sent over an encrypted channel is the concern, as
an unencrypted channel is vulnerable to man-in-the-middle attacks
if re-authentication is not done on each message.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
fisherm@indy.tce.com                   Indianapolis, IN

Received on Wednesday, 7 August 1996 12:21:53 UTC