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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Some additional comments on closer reading and a general comment:

This registry intentionally (if you look at the RPID document) is not meant to directly extend the RPID schema. I suppose that one could add that any location types added automatically become XML elements in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if that's appropriate. I think it's appropriate (and necessary to add) that any registrations must be legal XML element names.


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.


Since usage will strongly depend on the context and since this registry is not limited to RPID, I think this would 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

I'd assume yes, in general, but defining that seems to be the role of the protocol using these elements, not a registry.

I think of the registry like a dictionary. A dictionary does not define which words you can use together.

- whether it's intended that a sequence of location types gives a progressively more precise set of terms (in which case internationalizing the last type you understand is appropriate) or names an intersection of the classes (in which case you would have to internationalize all of them).

There is no implication of hierarchy. In general, this seems difficult to achieve since not all location types are hierarchical. For example, an airport might contain a bank or a shopping-area, but that does not make either a subcategory of an airport.

I also don't understand the need for I18N, since these are tokens that would be translated by a local application, not rendered to users.


- whether having a text string alongside it (the "note" above) is a recommended practice.

That's again an RPID issue. Not every protocol using these tokens will have notes.


It MAY be appropriate to say something about field of use, like RPID does ("what types of communication is appropriate" would lead one to distinguish between "driving a car" and "passenger in a car", while one could imagine that other usages might want to distinguish between "expensive restaurant" and "cheap restaurant").

We are not trying to define a service location protocol that describes numerical properties of locations. I don't know how to rule this out by legal wording; presumably the expert reviewer can make common-sense judgement.






_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]