Tschofenig, Hannes wrote:
have you read, for example, the dhcp-civic draft?
If that's the draft with snail mail addresses, yes. I can't
judge it, but it would be okay for all addresses I've ever
heard of. I vaguely recall that I stumbled over its "postal
code", with all the global deregulations "postal code" could
need a corresponding "postal company" in the future.
For the "location dictionary" you'd need some rules why it's
in fact _no_ dictionary, a limited number of entries could do
the trick. Something how the "location reviewer" could say
NO to unnecessary new entries. Obviously that would need a
definition of "necessity":
P: I want "bar", "cafe", "disco".
R: We have "restaurant", we don't need "bar" or "cafe".
P: Okay, give me "disco".
No idea how to manage that. It's clearer for the proposed
collation registry, "anything you see as collation in an RfC",
same idea for the existing header field registry. The "URIs"
are almost as bad as the "locations", the most annoying so
far was "info:". The "charsets" are a rather good example.
Maybe you can copy some ideas from the "lang-subtag" registry:
Jefsey invented interesting "security considerations", stuff
like "what if each device in the world downloads the registry
once per year". Except from that point (yes, it's obscure at
first glance, but no nonsense) you could simply add pointers:
"Other privacy and security considerations are discussed in
the documents using this registry like [RFC1111], [RFC2222],
and [RFC3333]" for three hypothetical 'clients' of the future
location registry.
Maybe even "have to be discussed". As it was the draft was
an invitation for a DDoS attack on IANA with bogus locations.
Bye, Frank
P.S: geopriv removed from the Cc:, the list bounces articles
from non-subscribed users
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf