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
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, 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,
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
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
