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

On Thursday, January 19, 2006 03:56:21 PM -0500 Henning Schulzrinne 
<hgs(_at_)cs(_dot_)columbia(_dot_)edu> 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+(_at_)cmu(_dot_)edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf