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

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

 





On Thursday, January 19, 2006 03:56:21 PM -0500 Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx> 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) <jhutz+@xxxxxxx>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________

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]