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: Volume 1 Issue 2 of the IETF Journal
Brian Carpenter wrote in ietf-announce Volume 1 Issue 2 of the IETF Journal is now available at: http://ietfjournal.isoc.org/ It has an HTML version, how about a link to it on www.ietf.org ? ___ 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
Volume 1 Issue 2 of the IETF Journal
Volume 1 Issue 2 of the IETF Journal is now available at: http://ietfjournal.isoc.org/ (sent on behalf of the Editor, Peter Godwin) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
