Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt

On Tue, 01 May 2012 19:26:50 +0100
Alexey Melnikov <alexey.melnikov@isode.com> wrote:

> Dear WG participants,
> I would like to initiate WG Last Call on 
> draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP Extension"). 
> Please send your reviews, as well as expressions of support regarding 
> document readiness for IESG (or not) either to the mailing list, or 
> directly to WG chairs (Murray Kucherawy <msk@cloudmark.com> and myself). 
> Comments like "I've read the document and it is Ok to publish" or "I've 
> read the document and it has the following issues" are useful and would 
> be gratefully accepted by chairs.
> 
> The WGLC will end on Friday, May 18th.

We are closing in on May 18:th now. We have got plenty of good input.

To summarize, I have made a preliminary change log, covering things
that has been discussed this far. I will also mention ideas that we do
not intend to incorporate in this document.

If you have suggested something that is not in the list below I may
have missed that, please send a reminder to me in such case.

If you disagree with something in the list or have other ideas, please
let me know.



*** Intended changes ***

1.1, Section 4: Clearly mention that IPv6-addresses must be quoted.
     Also show this in examples. This also applies to IPv4 addresses
     when the port is specified.

1.2, Section 4: Have a less complex example. Also, make sure that the
     quote is placed on the right side of the "=".

1.3, Section 4: Add a note that a proxy can also add a new
     "Forwarded: .."-line, as this is equivalent. 

1.4, Section 5.*: Remove some MAY-references.

1.5, Section 5.1: Add a note that the by-parameter may be useful in a
     multi-homed environment. 

1.6, Section 5.2: Add a note that in some situations it is more relevant
     to read the address of the last proxy in the last
     Forwarded-by-field.

1.7, Section 5.2: Formulate paragraph 1 to include that the information
     is not only regarding the initiating client. Also change "user
     agent" to "client".

1.8, Section 5.5: Change the requirement to notify IANA into:
>"It is possible to register additional parameters using the IANA
>registration policy described in [RFC3864]"

1.9, Section 6: Require obfport to start with an underscore. 

1.10, Section 6 & 6.3: Include "[:._-]" as valid characters in obfnode
      and obfport. 

1.11, Section 6.1: s/zero compression/compression of zeroes/

1.12, Section 6.1: s/IPv6 adress/IPv6 address/

1.13, Section 7: Add some notes on when the header should be preserved
      or not. Duscussed under #7:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05535.html

1.14, Section 7: Note that this header field is not possible to combine
      with the information from the via-header field with certainty.

1.15, Section 7.1: Remove the word "correctly" from: 
      "[...] information might not be correctly updated [...]"

1.16, Section 7.x: Encourage proxies to convert X-Forwarded-*
    when possible. 

1.17, Section 8.2: Add the text W. Tarreau mentions:
      (with the change of must -> should in the first sentence)
> This header field should never be copied into response messages by
> origin servers or intermediaries for whatever reason as it can reveal
> the whole proxy chain to the client. As a side effect, special care
> must be taken in hosting environments not to allow the TRACE request
> where the Forwarded field is used, as it would appear in the body of
> the response message.


1.18, Section 8: Add a section or a note about privacy considerations.



*** Suggestions we intend NOT to incorporate ***
(somewhat incomplete)

2.1, TCP-options. This can be standardized in a separate document.

2.2, Complex transition schemes. 


Best regards,
 Andreas Petersson