AW: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard

Hi Sam, 

please find some feedback below: 

> >>>>> "Henning" == Henning Schulzrinne <[email protected]> writes:
> 
>     >>  2) Inadequate context for use:
>     >> 
>     >> The document does not make reference to RPID, except in
>     >> "acknowledgement". Thus, it has to be interpreted as
>     >> stand-alone, and must contain its own guidance. RPID states:
>     >> 
>     >> 
>     >> 
>     >> These things guide the usage of place-types in RPID, but cannot
>     >> be found from the registry document.
>     >> 
> 
>     Henning> Since usage will strongly depend on the context and since
>     Henning> this registry is not limited to RPID, I think this would
>     Henning> belong into RPID (or other documents), not the registry.
> 
>     >> This document SHOULD give guidance for usage, saying at least:
>     >> 
>     >> - whether it's intended that several of these values can be
>     >> used together
> 
>     Henning> I'd assume yes, in general, but defining that seems to be
>     Henning> the role of the protocol using these elements, not a
>     Henning> registry.
> 
>     Henning> I think of the registry like a dictionary. A dictionary
>     Henning> does not define which words you can use together.
> 
> 
> Here I think is the crux of the problem.  The IETF and IANA should not
> be in the business of creating dictionaries.

There are documents that use a location type. We can give an initial
list of values but we cannot be exhaustive. 
Do you have a better suggestion for extending these values? 

> 
> The document under discussion creates a named set of place
> descriptions.
> 
> There is no guidance given on how this information should be used,

This information is provided in other documents (RADIUS-Geopriv and
DHCP-CIVIC). We can add references to these documents. 


> why
> you would want this registry 

To provide a mechanism for extending the currently defined list of
values. 

> or what constraints should be placed on
> it.

We have received some feedback about these constraints and we will put
them into the IANA consideration section (as suggested). Documents that
use the values in the registry provide additional constraints. 


> 
> That's a big problem.  First, there are likely to be concerns that
> matter to almost all uses of the registry.  It's desirable to require
> using applications to consider these concerns and probably even to
> describe how they handle the concerns.
> 
> 
> Another reason not giving guidance is problematic has to do with
> different assumptions about how the registry is used.  Some
> applications may assume that there will be a small number of entries
> in the registry.  That's fine until someone comes along and say
> registers all the different major food chains with presence in more
> than one country.

With the suggested change to expert review for enhancing or updating the
values in the registry this aspect seems to be covered. 

> 
> One application may assume that location is single valued; another may
> have multi-valued location.  These applications will expect different
> things from the registry.

There is no problem about this aspect. 

> 
> Even when we've tried to have guidance for registries we've run into
> problems.  Witness the recent debate about whether RTP and MIME should
> use the same media type registry.
> 
> As such, with my AD hat off, I do not support publication of an RFC
> that establishes a dictionary for place names I would probably support
> publication of an RFC that established a well-coped place name
> registry for some purpose.  I'd want to limit the size of the registry
> for localization reasons.

I would like to make sure that I properly understand you.
It would be OK for you if we copy-and-paste the document into RPID,
RADIUS-Geopriv, DHCP-CIVIC (instead of referencing it) and create a
separate registry for each of these documents.

Ciao
Hannes

> 
> --Sam
> 
> 
> _______________________________________________
> Ietf mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf