On Tue, 10 Jul 2012 08:43:43 -0700
SM s...@resistor.net wrote:
In Section 6.3:
'To distinguish the obfuscated identifier from other identifiers,
it MUST have a leading underscore _.'
I suggest removing the requirement and using can. The implementer
can decide what to put in that
On Tue, 10 Jul 2012 12:32:08 -0400
Alissa Cooper acoo...@cdt.org wrote:
On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote:
The first half of the statement is basically a refinement of the previous
sentence in the section (The Forwarded HTTP header field, by design,
exposes
Hi Andreas,
At 06:41 11-07-2012, Andreas Petersson wrote:
How is it random bits of information when the specifications says
that it MUST be underscore?
As far as I can think of, the only thing that it will tell is that the
implementation is following this specification.
So, on the contrary; the
On Mon, 9 Jul 2012 14:27:49 -0400
Alissa Cooper acoo...@cdt.org wrote:
(incorporating some responses to
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html as a
LC comment)
It would be helpful if this document could further motivate the need for
proxies to generate
On Mon, 09 Jul 2012 13:59:43 -0700
SM s...@resistor.net wrote:
Also, this statement in 8.3 is not really true and probably better left out:
Proxies using this extension will preserve the information of a
direct connection, which has an end-user privacy impact, if the end-
user or
On Mon, 09 Jul 2012 22:48:59 +0100
Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some
On Mon, 09 Jul 2012 09:28:48 -0700
The IESG iesg-secret...@ietf.org wrote:
1. While RFC Required forces new registrations through the IETF RFC
process, and might discourage registrations from individuals or
organizations that are unfamiliar with or averse to that process,
Specification
Hi Andreas,
On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
The first statement above gets at this, but it seems to me that the
middle ground between random generation per request and permanent
unique token is worth emphasizing if there will be proxies that want
to keep per-client
On Tue, 10 Jul 2012 10:54:53 -0400
Alissa Cooper acoo...@cdt.org wrote:
Hi Andreas,
On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
The first statement above gets at this, but it seems to me that the
middle ground between random generation per request and permanent
unique token is
On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote:
The first half of the statement is basically a refinement of the previous
sentence in the section (The Forwarded HTTP header field, by design,
exposes information that some users consider privacy sensitive), so I don't
see what is lost
Hi Andreas,
At 04:28 10-07-2012, Andreas Petersson wrote:
I interpret it the other way around.
It makes a deployer aware that there is also end user expectations
to take into considerations.
Removing it may work as well, but I think that less well reflects the
discussion on the apps-list.
On Mon, Jul 09, 2012 at 10:48:59PM +0100, Stephen Farrell wrote:
So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some control over their
(incorporating some responses to
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html as a LC
comment)
It would be helpful if this document could further motivate the need for
proxies to generate static obfuscated tokens. These two lines in particular,
from 6.3 and 8.3,
At 11:27 09-07-2012, Alissa Cooper wrote:
Is it possible to recommend that generated tokens have limited
lifetimes (per-request or otherwise), and make the static case the
exception? The first statement above gets at this, but it seems to
me that the middle ground between random generation per
So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some control over their
location privacy.
This HTTP header will be used by proxies to forward
on the
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Forwarded HTTP Extension'
draft-ietf-appsawg-http-forwarded-06.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
16 matches
Mail list logo
