Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt

From: [email-masked]
Date: Mon, 26 Mar 2012 08:10:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Forwarded HTTP Extension
	Author(s)       : Andreas Petersson
                          Martin Nilsson
	Filename        : draft-ietf-appsawg-http-forwarded-01.txt
	Pages           : 12
	Date            : 2012-03-26

   This document standardizes an HTTP extension header field that allows
   proxy components to disclose information lost in the proxying
   process, e.g., the originating IP address of a request or IP number
   of the proxy on the user-agent facing interface.  Given a trusted
   path of proxying components, this makes it possible to arrange so
   that each subsequent component will have access to e.g., all IP
   addresses used in the chain of proxied HTTP requests.

   This document also specifies guidelines for a proxy administrator to
   anonymize the origin of a request.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-01.txt

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 26 Mar 2012 17:34:17 +0200

> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

I believe there is not much left to fix in this draft. 
My biggest concern right now is this:

    extension = 1*( ALPHA | DIGIT | "-" )
    ext-value = <any OCTET except CTLs, "," and ";",
      but including SP>

Is that too liberal? Should recommendations be done in this draft on
what character encoding should be used? 
If the value is an URL, should the document recommend IDNA? 
Should the draft say anything about case sensitivity?
Of course all this depends on what people will use it for.

 /Andreas Petersson

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Mar 2012 09:41:00 +0200

> what character encoding should be used?

Why not use the normal token / quoted-string constructs?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Mar 2012 09:54:02 +0200

On 2012-03-27 09:41, Martin Thomson wrote:
> On 26 March 2012 17:34, Andreas Petersson<[email-masked]>  wrote:
>>     ext-value =<any OCTET except CTLs, "," and ";",
>>       but including SP>
>>

Yes, please.

Also, it's no entirely clear why the spec depends on RFC 2616, not 
HTTPbis (although it copies some of its style).

Finally, as noted in other WGs: please do not special case the syntax of 
certain parameters. Just define *all* of them to be

   token / quoted-string

and then define additional constrains separately (see epic discussions 
in OAuth and WebSec).

Best regards, Julian

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 27 Mar 2012 16:03:43 +0200

On Tue, 27 Mar 2012 09:54:02 +0200

> > Why not use the normal token / quoted-string constructs?

For ext-value I assume you mean?

> HTTPbis (although it copies some of its style).

Because HTTPbis is not an RFC yet. When we started working on this draft
it was unclear both when this draft will be finished and when HTTPbis
will be finished. If HTTPbis becomes an RFC before this one, I intend to
make adjustments to this one to refer to HTTPbis and also use ABNF as
used in HTTPbis instead of RFC2616-style BNF.

> and then define additional constrains separately (see epic discussions 

I don't see the point in this. If you can't motivate it in one e-mail I
doubt there is a good one. :-)

 /Andreas Petersson

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Mar 2012 16:29:46 +0200

On 2012-03-27 16:03, Andreas Petersson wrote:
> ...

Yes.

> used in HTTPbis instead of RFC2616-style BNF.

Ack.

Note that we now have the first spec in the RFC Editor queue with a 
normative reference to HTTPbis.

> doubt there is a good one. :-)

The reason is that if you special-case the value syntax based on the 
parameter name, you'll end up

- writing a custom parser (and most custom parsers I've seen a 
incredibly broken),

or

- using a generic parser (and accept values that the ABNF says are 
invalid, causing interop problems with other implementations).

The simplest possible approach is to allow the same syntax for all 
parameters.

Best regards, Julian

PS: I think we need a downfall clip about this; maybe Jari can help me 
with that 
(<http://www.youtube.com/watch?feature=player_embedded&v=LbK-g8tKnoc>)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Mar 2012 12:01:26 +0200

OK, details...:

>        Forwarded   = "Forwarded" ":" LWS Forwarded-v
>        Forwarded-v = 1#forwarded-element

If you use RFC2616ABNF, the LWS isn't needed here.

(If you did switch to base this on HTTPbis, I would recommend just to 
define the *value* ABNF).

>        forwarded-element =
>                OWS forwarded-value *( OWS ";" OWS forwarded-value ) OWS

I would recommend to allow leading and trailing ";"; if you don't you 
will end up with some recipients allowing them (because it's the 
simplest way to parse it) and some not doing so.

Thus:

        forwarded-element =
            [ forwarded-value ] *( ";" [ forwarded-value ] )

Also OWS isn't needed here if you use RFC2616ABNF.

(see similar discussion in websec)

>        forwarded-value   = for-kv | by-kv | proto-kv | host-kv | ext-kv
>
>        for-kv     = "for=" node
>        by-kv      = "by="  node
>        proto-kv   = "proto=" proto-name
>        host-kv    = "host=" host
>        ext-kv     =  extension "=" ext-value
>        proto-name = ALPHA *( ALPHA | DIGIT | "+" | "-" | "." )

I would change this to

    forwarded-element = token "=" value
    value             = token / quoted-string

And then define the various values independently of the base ABNF.

Example:

The syntax of a "for" value, after potential quoted-string unescaping, 
MUST conform to the "node" ABNF.

(Also, it's kind of weird to use the name "value" for something that is 
not the right-hand side of a name/value pair; would be good to make 
"forwarded-value" something else)

>        ext-value = <any OCTET except CTLs, "," and ";",

This should be

   extension = token
   ext-value = token | quoted-string

for consistency with all the other values.

Best regards, Julian