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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
On Jan 19, 2006, at 10:11 AM, JFC (Jefsey) Morfin wrote: ... multinationalisation calls for the concept to be equally understood (what does understand mean?) the same way between every cultures (every ends are equal). Either because the concept is truly universal. Or because you built all the cross-national in-between extended services to permit a polylogual relation. This means that when an American end says kitchen, the French end will receive American style Kitchen (our kithens are not _built_ the same way and do not include the same set of things). Interesting. Do French kitchens not include a coffee-maker, stove, oven, sink, refrigerator and counters? What do they have, besides fewer chemicals on/in their food, that American kitchens do not? I take a very common example. Many languages have the same term for blue and green and only consider them as different shades. Blue and green are different hues. Different shades are the same hue but different concentration, for example navy blue compared to royal blue. http://en.wikipedia.org/wiki/Color_theory Please provide a reference for languages that use the same term for blue and green. I would be surprised because these colors have different receptors in the human eye. http://en.wikipedia.org/wiki/Cone_cell Recent studies shown that people of different languages describe the different variations of blue/green the same way with the right eye (left brain) but differently with the left eye (right brain), depending on the language. Please provide references for these studies. The right eye (left brain) description is revolutionary, since the function of the optic chiasm was hypothesized by Newton in 1704 and demonstrated by by Ramon y Cajal in 1899. http://en.wikipedia.org/wiki/Optic_chiasm John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
Yes, unfortunately it does. Extending element sets seems to be rather tedious in the current XML tool set. Either you have the new elements extend the old namespace, yielding the problem you mention, or each new element (location type, here) gets a new namespace, yielding a namespace list a mile long if there are lots of extensions. Henning Schulzrinne wrote: 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. Doesn't this make it hard/impossible to check if an RPID document is schema-valid? (I mean keeping some element names in a list that's not a schema.) Perhaps that's not important for this application though. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
[taking out the iesg from CC list, but leaving WG and ietf list in] --On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne [EMAIL PROTECTED] wrote: Some additional comments on closer reading and a general comment: 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. Sigh I guess we disagree on principles here pretty strongly. I think that in order for a vocabulary like this to be useful, it has to fit its purpose. A vocabulary that is made to fit multiple purposes will in the end fit neither - for one recent example, see the discussion between the mail folks and the RTP folks over the proper registration and meaning of MIME content-types. You're defining the vocabulary now, and have the chance for establishing a reasonable context. Once it's being used for two purposes with conflicting requirements, it's too late to fix it. 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. Yes, it does. By implication, a dictionary is for a language, and a language is (among other things) a set of rules on how to put the words together - and it VERY strongly implies that in order to understand a word's meaning, you have to look at its context. But it's easy to forget about the enormous amount of baggage we have when considering a concept like word, and that there's so little baggage attached to a label type like this one. - 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. Good - then say so! 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. My mistake - this should have been localize. To illustrate: In the flat case, restroom, cafe, airport could be localized as Toalett, ukjent sted, Flyplass in Norwegian if the application doesn't know the translation of cafe; in the hierarchical case, one could imagine McDonalds, cafe, eating-place, public building, indoors - it would be OK to localize that as Spisested if cafe isn't known. - 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. There's no second protocol at the moment, so you have the chance to provide guidance... 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. Legal wording isn't what I'm looking for. Hints to the reviewer about what the WG considers common sense would be helpful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
Hi! Harald, We fully agree on this. But I see you are fighting here the same difficulty I fight against you for languages. They propose words in their language context as you propose languages tags in your internationalised context. They do the same layer violation as you do. The only solution to this is to conceptualise and to universalise the concept. ISO 11179. You define a concept, give it a unique ID (building a referent) and as many names as you need which name the concept, not its version in a given context. However I agree JTC1/SG32/W2 has not yet addressed the multilingual and the networked aspects. But IETF have clumsily approached it with IDNA and very well with the DNS. The problem is that the whole process has to be multiterative. When you consider your internationalization, the concept named in English is to be adapted into the locale culture which tries to understand your concept the same way as you do (this is monologue). This is workable but gives leadership (and economical, cultural, political, technical advantages to the American end). Better you have a true dialog where the American concepts includes the other end's concepts. Unicode very partly does that for texts items. multinationalisation calls for the concept to be equally understood (what does understand mean?) the same way between every cultures (every ends are equal). Either because the concept is truly universal. Or because you built all the cross-national in-between extended services to permit a polylogual relation. This means that when an American end says kitchen, the French end will receive American style Kitchen (our kithens are not _built_ the same way and do not include the same set of things). I take a very common example. Many languages have the same term for blue and green and only consider them as different shades. Recent studies shown that people of different languages describe the different variations of blue/green the same way with the right eye (left brain) but differently with the left eye (right brain), depending on the language. A friend of mine works on dictionary about kids: the way kids understand the same thing around the world. Example: bring me some water implies many different things to do if the kid lives in a flat, in a farm, in a desert, in the USA, in Bangladesh, etc. and the water may be very different. Welcome in multinationalisation and DRS preparatory work. BTW IAB will say if this is an IETF matter or not. jfc At 14:15 19/01/2006, Harald Tveit Alvestrand wrote: [taking out the iesg from CC list, but leaving WG and ietf list in] --On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne [EMAIL PROTECTED] wrote: Some additional comments on closer reading and a general comment: 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. Sigh I guess we disagree on principles here pretty strongly. I think that in order for a vocabulary like this to be useful, it has to fit its purpose. A vocabulary that is made to fit multiple purposes will in the end fit neither - for one recent example, see the discussion between the mail folks and the RTP folks over the proper registration and meaning of MIME content-types. You're defining the vocabulary now, and have the chance for establishing a reasonable context. Once it's being used for two purposes with conflicting requirements, it's too late to fix it. 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. Yes, it does. By implication, a dictionary is for a language, and a language is (among other things) a set of rules on how to put the words together - and it VERY strongly implies that in order to understand a word's meaning, you have to look at its context. But it's easy to forget about the enormous amount of baggage we have when considering a concept like word, and that there's so little baggage attached to a label type like this one. - 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
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
I think that in order for a vocabulary like this to be useful, it has to fit its purpose. A vocabulary that is made to fit multiple purposes will in the end fit neither - for one recent example, see the discussion between the mail folks and the RTP folks over the proper registration and meaning of MIME content-types. I can't prove or disprove that statement, unfortunately. We won't know whether the location types will be useful until somebody uses them. I suspect that real GIS applications will need a far more specialized vocabulary, but it turns out that, for example, a proposal for crime scene labeling more or less fits into the proposed registered list. (We found this out after creating the list.) Currently, there are two potential customers: RPID and AAA. Yes, it does. By implication, a dictionary is for a language, and a language is (among other things) a set of rules on how to put the words together - and it VERY strongly implies that in order to understand a word's meaning, you have to look at its context. Dictionaries I know generally define the word by itself. Indeed, many of the definitions in the document are very close to (English) dictionary definitions. To illustrate: In the flat case, restroom, cafe, airport could be localized as Toalett, ukjent sted, Flyplass in Norwegian if the application doesn't know the translation of cafe; in the hierarchical case, one could imagine McDonalds, cafe, eating-place, public building, indoors - it would be OK to localize that as Spisested if cafe isn't known. We'll note in the draft that there is no implied hierarchy, except where noted. (For example, 'restaurant' is an umbrella term that includes 'cafe' and 'bar'.) - 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. There's no second protocol at the moment, so you have the chance to provide guidance... Yes: AAA (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt) Legal wording isn't what I'm looking for. Hints to the reviewer about what the WG considers common sense would be helpful. To better understand what you have in mind, can you give an example? There are some obvious things, like: - not specific to a country - not a specific company or organization - well-defined - widely recognized ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
--On torsdag, januar 19, 2006 15:56:21 -0500 Henning Schulzrinne [EMAIL PROTECTED] wrote: That's again an RPID issue. Not every protocol using these tokens will have notes. There's no second protocol at the moment, so you have the chance to provide guidance... Yes: AAA (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt) Right - the wording there is an argument in favour of centralizing guidance (it has none). Legal wording isn't what I'm looking for. Hints to the reviewer about what the WG considers common sense would be helpful. To better understand what you have in mind, can you give an example? There are some obvious things, like: - not specific to a country - not a specific company or organization - well-defined - widely recognized That's good guidelines for a reviewer. It would allow him to reject both McDonalds (company) and Lavvo (Sami tent, not widely recognized), but would probably accept open ocean and river (if it was used in a context about where a boat is, these might make sense). I'd say not specific to a country or language. Go for it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
On Thursday, January 19, 2006 03:56:21 PM -0500 Henning Schulzrinne [EMAIL PROTECTED] wrote: Dictionaries I know generally define the word by itself. Indeed, many of the definitions in the document are very close to (English) dictionary definitions. Dictionaries define a word, including specifying one or more parts of speech, which are the places in the language syntax where the word can be used. And, as already noted, dictionaries are not abstract lists of words; they are tied to specific languages. For some languages, they provide additional information affecting the syntax surrounding the word. Good dictionaries also provide examples of real-world usage. In fact, according its website, the OED normally requires several examples of use before a word will be included, and it is these examples which are used to determine the word's definition. Note that the process is considerably different for protocol parameters, where we first decide exactly what we want to be able to say, and then assign a protocol parameter which means that. Then, the parameter is not in any natural language, but in the language of whatever wire protocol uses it -- that is why we can name protocol parameters in English without needing to worry about how to localize -- the meaning is language-independent. Of course, non-English-speaking implementors would probably appreciate translations of the definitions, just as they would appreciate translations of the protocol specs. But the presence or absence of such translations won't change whether a correct implementation works, or which other implementations it interoperates with, or even which users can use the software (the last _does_ depend on localization of whatever user interface the software has, but that's an implementation issue, not a protocol design issue). If you're going to define a value intended for consumption by humans, rather than by software, then it should probably be free-form, rather than subject to a registry, and then you do have to worry about internationalization and language tagging. What you don't need in this case is a registry for the contents of the field. Now, one solution to the problem (and a widely adopted one) is to replace the free-form field with a parameter which only _looks_ free-form, but actually has well-defined values, allowing them to be localized. That would be a legitimate reason for creating a registry such as the one described by this document, but then the document would need to describe the issue and how the registry is meant to be used to solve it. In any case, whether you are writing a dictionary, a protocol parameter registry, or a message catalog, it is necessary to specify a domain of applicability, which the document under discussion fails to do. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
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. The document under discussion creates a named set of place descriptions. There is no guidance given on how this information should be used, why you would want this registry or what constraints should be placed on it. 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. One application may assume that location is single valued; another may have multi-valued location. These applications will expect different things from the registry. 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. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
Thanks for your comments. I generally agree with your feedback and we'll revise the document accordingly. Harald Tveit Alvestrand wrote: I oppose approval of this document as-is. Four reasons: 1) FCFS is inappropriate 2) The document gives inadequate context for use 3) The document gives inadequate procedures 4) The definition of automobile is wrong Further explanation: 1) FCFS: This token registry will have value chiefly when the recipient of such a token has a complete list of tokens available to him, and can perform adequate localization. Thus, value is maximized if the churn of the registry is slow. With FCFS, one risks a number of trends that could jeopardize this (consider registering, in addition to cafe, McDonalds, Wendy's, Burger King, Jack-in-the-box, 7-eleven... or in addition to school, registering university, middle school, gymnasium, hochschule, kindergarten, vocational-training-institution) I consider expert review, with a list of criteria that includes names a type of place not described by any existing token, to be a more appropriate mechanism. If we think unlimited growth is a problem, someone needs to be able to say no; if we don't think unlimited growth is a problem, we need to say so. 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: The place-type element describes the type of place the person is currently at. This offers the watcher an indication what kind of communication is likely to be appropriate. The XML definiton says: xs:element name=place-type xs:annotation xs:documentation Describes the type of place the person is currently at. /xs:documentation /xs:annotation xs:complexType xs:sequence xs:element name=note type=Note_t minOccurs=0/ xs:choice xs:element name=aircraft type=empty / and while I'm not an XML expert, it seems to say that place-typeautomobile/road//place-type is a legal construct. I don't know if it's possible to say whether or not place-typeautomobile/road//place-type is different from place-typeroad//automobile/place-type. These things guide the usage of place-types in RPID, but cannot be found from the registry document. This document SHOULD give guidance for usage, saying at least: - whether it's intended that several of these values can be used 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). - whether having a text string alongside it (the note above) is a recommended practice. 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). 3) Inadequate procedures: It's a fact of life that any registry will need updating. This document describes registration, but no updates. It needs to say: - Who's authorized to update a registration (FCFS, Expert approval, original registrant, not at all) - Guidelines for updates (anything-goes, refinements only, redefinitions with expert approval only) - Whether registrations can be deleted or not - Whether there is a mechanism for marking entries as deprecated, use this other term 4) Self explanatory: automobile: The entity is in a railroad car. Nit: The terms show signs of having been alphabetized at one time. They are no longer alphabetized - residence is in a place in the list that would have been appropriate for home. --On mandag, januar 16, 2006 21:33:45 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg istry-0 3.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: Last Call: 'Location Types Registry' to Proposed Standard
On Wednesday, January 18, 2006 08:30:56 AM +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I oppose approval of this document as-is. Four reasons: 1) FCFS is inappropriate 2) The document gives inadequate context for use 3) The document gives inadequate procedures Agree. 4) The definition of automobile is wrong Eh. It's a protocol constant; they can define it however they want. As long as they let me register 'wyoming' to mean the entity is in a fictional location. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
A different question: Henning Schulzrinne wrote: 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. Doesn't this make it hard/impossible to check if an RPID document is schema-valid? (I mean keeping some element names in a list that's not a schema.) Perhaps that's not important for this application though. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
The IESG wrote: consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard I'm lost with the purpose of this document. Does 'water' cover WC, bathroom, bathtube ? What is a criminal mental institution ? Can an entity be on a 'cycle' 'outdoors' in the 'street' simultaneously, and if yes, how do we know that 'water' 'airplane' 'cycle' is somewhat strange ? If all that is relevant somewhere for indiscreet devices, shouldn't there be an enumeration of the IANA registered locations ? Will the next IANA registry be a complete dictionary, and will it by definition include the location registry ? Is it a good idea to have dictionaries on standards track ? Is it acceptable to have no I18N considerations in the proposed location standard ? The dummy security considerations might be incomplete, if locations could be used for say search and rescue purposes. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
On 17-Jan-2006, at 08:00, Frank Ellermann wrote: The IESG wrote: consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard I'm lost with the purpose of this document. It seems from a quick glance through it that draft-ietf-simple- rpid-08 gives context. The initial list of locations seems entirely arbitrary, and most of the definitions seem woolly and imprecise. Maybe the arbitrariness is intentional, though, and maybe the quality of definitions doesn't matter. I don't know enough about the goals of the underlying effort to comment. There are some spelling mistakes. That's about as far as my informed commentary on this draft goes :-) Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
It seems from a quick glance through it that draft-ietf-simple- rpid-08 gives context. The initial list of locations seems entirely arbitrary, and most of the definitions seem woolly and imprecise. Maybe the arbitrariness is intentional, though, and maybe the quality of definitions doesn't matter. I don't know enough about the goals of the underlying effort to comment. More precise definitions are always helpful, but I don't think it is necessary to have a complete catalogue of all possible types of locations suitable for an insurance company policy. The goal is that if there's a location, that if two people are asked to pick the closest label, they'll likely agree and they'll likely find something that matches. Clearly, this can be pushed to precision beyond need. For example, I doubt that we need to identify median strips on roads separately. There are some spelling mistakes. That's about as far as my informed commentary on this draft goes :-) Joe ___ 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
Re: Last Call: 'Location Types Registry' to Proposed Standard
Joe Abley wrote: It seems from a quick glance through it that draft-ietf-simple-rpid-08 gives context. ACK, thanks for info. So now I'm _anxiously_ awaiting an Internet standard for IANA registered moods... xs:element name=afraid type=empty/ xs:element name=amazed type=empty/ xs:element name=angry type=empty/ xs:element name=annoyed type=empty/ xs:element name=anxious type=empty / ...yes, can do. It also offers 'grumpy' and 'sarcastic'. Bye ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
At last! you start understanding what multimode means in languages. I am sorry, but in approving RFC 3066 bis, i.e. declaring itself and the IETF authoritative, this is exactly the RFC 3935 responsibility the IETF has accepted. jfc At 15:06 17/01/2006, Frank Ellermann wrote: Joe Abley wrote: It seems from a quick glance through it that draft-ietf-simple-rpid-08 gives context. ACK, thanks for info. So now I'm _anxiously_ awaiting an Internet standard for IANA registered moods... xs:element name=afraid type=empty/ xs:element name=amazed type=empty/ xs:element name=angry type=empty/ xs:element name=annoyed type=empty/ xs:element name=anxious type=empty / ...yes, can do. It also offers 'grumpy' and 'sarcastic'. Bye ___ 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
Re: Last Call: 'Location Types Registry' to Proposed Standard
I have only had a brief look at this document but I'd like to second some of the concerns raised so far. 1) If locations can be registered on a fcfs basis we can expect receivers to see locations that they are unfamiliar with. As such, we need to do better about internationalization for locations. It is not good enough to treat locations as identifiers that are not displayed to a user if receivers are often going to run into locations. 2) Many of the definitions seem arbitrary. club vs bar vs cafe vs restaurant as an example. 3) The fact that some entries describe holonym relations without any defined structure to deal with this is at least concerning. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
On Jan 17, 2006, at 5:57 PM, Sam Hartman wrote: I have only had a brief look at this document but I'd like to second some of the concerns raised so far. 1) If locations can be registered on a fcfs basis we can expect receivers to see locations that they are unfamiliar with. As such, we need to do better about internationalization for locations. It is not good enough to treat locations as identifiers that are not displayed to a user if receivers are often going to run into locations. Not that I fully understand your concern, but would you want expert review of new additions? 2) Many of the definitions seem arbitrary. club vs bar vs cafe vs restaurant as an example. Do you have a suggestion about how this can be less arbitrary? 3) The fact that some entries describe holonym relations without any defined structure to deal with this is at least concerning. Maybe this can be remedied with some guidelines as to what constitutes a reasonable entry. I'm not sure if that is possible, but it certainly seems like car would be a useful entry as opposed to seat which would both be valid if somebody were riding in a seat in a car. -andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
JFC (Jefsey) Morfin wrote: you start understanding what multimode means in languages. Maybe I understand abuse IANA as cheap dictionary for a random list of locations. But the list of smileys has some technical potential, devices could output them as icons, audio, localized text, or as traditional ASCII art. For that the list of moods could give the ASCII art, that's the most limited and shortest form, plus a corresponding English word as explanation useable directly in localized text output for en. I18N for ASCII art smileys might be tricky, maybe that depends on the script. At least BiDi is no issue. Attempts to smuggle smileys into Unicode as characters are probably futile, but an RfC could do. With the option to create an official registry of smileys later. Funny, but not necessarily nonsense. I am sorry, but in approving RFC 3066 bis, i.e. declaring itself and the IETF authoritative, this is exactly the RFC 3935 responsibility the IETF has accepted. Well, you know what bis stands for, you know the now three ISO sources for this registry, you know the executive summary 3066 + scripts, for certain charsets and languages and other situations where that's not obvious or irrelevant, you know where to find draft-lilly-content-script, and you know that 3066 didn't guarantee stable tags. That's not exactly the same situation as starting a location dictionary hosted by IANA with a proposed Internet standard. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
Andrew == Andrew Newton [EMAIL PROTECTED] writes: Andrew On Jan 17, 2006, at 5:57 PM, Sam Hartman wrote: I have only had a brief look at this document but I'd like to second some of the concerns raised so far. 1) If locations can be registered on a fcfs basis we can expect receivers to see locations that they are unfamiliar with. As such, we need to do better about internationalization for locations. It is not good enough to treat locations as identifiers that are not displayed to a user if receivers are often going to run into locations. Andrew Not that I fully understand your concern, but would you Andrew want expert review of new additions? So, I'me a receiver. I receieve a location that I'm unfamiliar with. How do I render it in my native locale? I'm not sure expert review would help with this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
So, I'me a receiver. I receieve a location that I'm unfamiliar with. How do I render it in my native locale? I don't think there is any way to accomplish this in general. You have two unpleasant choices: - render the token as-is, hoping that it makes sense to the recipient; - automatically translate the token, risking that the translation will be nonsensical. This is no different than for any other token meant to be rendered to humans. In RPID, where this is more relevant than in the Registry draft, there is a free-text field with the usual XML 'lang' attribute, which can be used to describe the location in internationalized text. However, in many systems, this is not particularly helpful. As an example, in presence, if your watchers are from many different language communities, the publisher likely can't pick a language that all watchers will understand. Thus, the use of tokens. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
On Mon, 16 Jan 2006, The IESG wrote: The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-03.txt What I would like to know is how a document that creates a registry can be considered for Proposed Standard, as opposed to BCP. A Proposed Standard is supposed to be something that can be advanced on the standards track. How on Earth does one have multiple interoperable genetically unrelated implementations of a registry? //cmh P.S. Yes I know we do this all the time but that does not mean that it makes sense! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
I oppose approval of this document as-is. Four reasons: 1) FCFS is inappropriate 2) The document gives inadequate context for use 3) The document gives inadequate procedures 4) The definition of automobile is wrong Further explanation: 1) FCFS: This token registry will have value chiefly when the recipient of such a token has a complete list of tokens available to him, and can perform adequate localization. Thus, value is maximized if the churn of the registry is slow. With FCFS, one risks a number of trends that could jeopardize this (consider registering, in addition to cafe, McDonalds, Wendy's, Burger King, Jack-in-the-box, 7-eleven... or in addition to school, registering university, middle school, gymnasium, hochschule, kindergarten, vocational-training-institution) I consider expert review, with a list of criteria that includes names a type of place not described by any existing token, to be a more appropriate mechanism. If we think unlimited growth is a problem, someone needs to be able to say no; if we don't think unlimited growth is a problem, we need to say so. 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: The place-type element describes the type of place the person is currently at. This offers the watcher an indication what kind of communication is likely to be appropriate. The XML definiton says: xs:element name=place-type xs:annotation xs:documentation Describes the type of place the person is currently at. /xs:documentation /xs:annotation xs:complexType xs:sequence xs:element name=note type=Note_t minOccurs=0/ xs:choice xs:element name=aircraft type=empty / and while I'm not an XML expert, it seems to say that place-typeautomobile/road//place-type is a legal construct. I don't know if it's possible to say whether or not place-typeautomobile/road//place-type is different from place-typeroad//automobile/place-type. These things guide the usage of place-types in RPID, but cannot be found from the registry document. This document SHOULD give guidance for usage, saying at least: - whether it's intended that several of these values can be used 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). - whether having a text string alongside it (the note above) is a recommended practice. 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). 3) Inadequate procedures: It's a fact of life that any registry will need updating. This document describes registration, but no updates. It needs to say: - Who's authorized to update a registration (FCFS, Expert approval, original registrant, not at all) - Guidelines for updates (anything-goes, refinements only, redefinitions with expert approval only) - Whether registrations can be deleted or not - Whether there is a mechanism for marking entries as deprecated, use this other term 4) Self explanatory: automobile: The entity is in a railroad car. Nit: The terms show signs of having been alphabetized at one time. They are no longer alphabetized - residence is in a place in the list that would have been appropriate for home. --On mandag, januar 16, 2006 21:33:45 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg istry-0 3.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Location Types Registry' to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-0 3.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
