It seems to me that there's a big problem with using this for rights enforcement. If the header is added by the user's device, then on certain operating systems it will be trivial for the user to set this to whatever they want it to be - which would defeat the purpose. If the header is added by devices out of the user's control so that the user cannot spoof their location (e.g. ISP routers) then for one thing they do not know the user's exact location, and for another there needs to be an additional mechanism for the user to switch the option off. The suggestion of using this to automatically get web pages in the right language also does not seem practical. My devices know that my preferred language is English. If I take one of those devices to China, I still want to see web pages in English. Additionally there is already an HTTP header to express your preferred language. Regards, Dan On 24 November 2012 21:18, John Adams <jna@retina.net> wrote:

Don't conflate layer 5-7 needs with basic communication requirements. IP is not the place for this sort of header.

This is not data that should be sent on every packet. It becomes redundant. Not to mention the serious privacy concerns such a header brings up in the protocol. You barely address this in your RFC. You write it away with a wishy-washy "Oh err um, users will have the option to turn it off". That's worked so well for opt-out advertising -- I'm sure it will work here.

If there's a place where I can go and vote this down / debate it away, tell me where that is.

-j

On Thu, Nov 22, 2012 at 3:59 AM, Ammar Salih <ammar.salih@auis.edu.iq

...

wrote:

...

Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!

http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t

...

ext=1

Thanks!

Ammar Salih

On 11/24/12, John Adams <jna@retina.net> wrote:

Don't conflate layer 5-7 needs with basic communication requirements. IP is not the place for this sort of header.

IP is the logical place for this kind of header, as this information is node dependent, not application dependent. It would be useful for identifying the location of a server, when an IP address does not. For example, in the case of an anycasted service, the source IP address does not uniquely identify where the source came from. The requirement that the embedded location data, be GPS data, however: would seem to be overly restrictive; a simple 8-bit "Site number" identifier could be all the location data needed for diagnostic purposes. "Privacy issues" are policy considerations, that have no place in the determination of protocol header formats; providers of a service will generate location header extensions, if they are useful to them, if they are not, then they would choose to not support the extension. If a provider wants to attempt to implement rights management using header fields, then more power to them.... I never heard of a digital rights management provider implementing an open standards-based approach, and it would be a positive development if they did, but more likely than not, they will ignore header extension options, and implement rights management identification inside proprietary application layer payloads that contain the actual protected content, instead of IP packet headers, which are easily stripped off, and replaced with new IP headers containing the same packet data payload. -- -JH