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 > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
