RE: grrp-reqs-06, 9. Internationalization Considerations

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Eric,

Meta-comment: I've not cited references to specific technical specifications
anywhere in the requirements document because they describe _how_ the
protocol must address particular issues.  One going-in assumption behind the
requirements is that any mention of how to address an issue would be left to
the protocol specifications.  There has been a consistent effort to remove
indirect references to such specifications (such as the one alluded to in
3.4-[8] (which will be removed from the next version of the draft), or for
IPv4, or IPv6, etc.), so I don't believe it proper to introduce new
technical references in other sections.

Other comments noted below, preceded with [SAH].

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:brunner@nic-naa.net]
Sent: Wednesday, February 14, 2001 11:12 AM
To: ietf-provreg@cafax.se
Cc: deng@pier.cnnic.net.cn; zwh6810@yahoo.com
Subject: grrp-reqs-06, 9. Internationalization Considerations



  [1] Current Internet standards restrict the encoding of Internet host
  and domain names to a subset of the 7-bit US-ASCII character set.

Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a.
                                -      0-9       A-Z       a-z
We may as well mention ASCII case folding, 1035 has a reasonable Note
at the end of 2.3.1 Preferred name syntax.

[SAH] OK, I'll add this reference because it helps describe the bounds of
the internationalization problem and it isn't a specific "solution"
reference.

  Registries and registrars now serve customers whose native languages
  require encodings other than US-ASCII, which automatically disallows  
  use of those languages when registering host and domain names.

Awkward language, what is it that "which" refers to? The "US-ASCII"
restricition, first sentence. If the subordinate clause is phrased
as a sentence ... 

[SAH] Alternative text, please.

  Support for internationalized host and domain names will greatly
  increase world-wide usability of a generic registry registrar
  protocol, so standards for exchanging internationalized information
  MUST be considered during the protocol design process.

Apple pie, but we don't actually state (or cite) what "internationalized"
means, yet, and the jump from "host and domain names" (technical data) to
social data (a subset of) "internationalized information" is left as an
exercise to the reader.

We could state:

	a. The protocol will support any encoding of technical and/or
	   social data, (code-set independent, or csi)
or
	b. The protocol will support some encodings (list) of technical
	   data, and some, possibly different, encodings (list) of social
	   data, (code-set dependent, or csd)
or
	c. The protocol will not support some encodings (list) of
	   technical data, and will not support some, possibly different,
	   encodings (list) of social data,

From Deng Xiang's response we know that UTF8 encodings of technical data
is a requirement of a provreg protocol deployed by the .CN ccTLD Registry
and Registrars.

It is possible that the range of encodings for social data includes GBK
and Big5 as well as UTF8.

[SAH] I don't think we should describe any particular solution to the i18n
problem in this document.  The current wording is deliberately vague WRT a
solution so that the solution is left to the protocol designers.
  
  [2] The protocol MUST allow exchange of meta-data associated with
  objects in formats consistent with current internationalized character
  encoding and language representation standards.

I honestly don't know what this means. If it means code-set identifiers
or locale identifiers or something else, we should be more specific (and
useful) about "metadata". Every time I hear that word I reach for my RDF.

[SAH] I forget who suggested this requirement, it appears redundant after
reading the last sentence in [1].  Would it be OK to strike it?

  [3] All date and time values specified in a generic registry-registrar
  protocol MUST be expressed in Universal Coordinated Time.  Dates and  
  times MUST include information to represent a four-digit calendar
  year, a calendar month, a calendar day, hours, minutes, seconds,
  fractional seconds, and the time zone for Universal Coordinated Time.
  
I suggest we cite iso8601 and pick a specific format, b (UCT, above).

I do see a problem however with any "user and/or accounting package
friendly"
temporal identifier (and we do use time, Scott is going to add a temporal
identifer sufficient to support ordering in addition to what is in -06 at
the moment). The problem is that objects have temporal properties, and these
properties are passed around as operands and as identifiers in a common
representation (good) but with no common synchronization mechanism (bad).

Anyone for NTP (not for sorting out nano-payments) as a specific requirement
for temporal consistency? How about putting an upper bound on clock deltas
between provreg entities? I claim it is Feb. 14, 1901. Another possibility
is seperating "meta- or technical time" from "social time". The first
provreg
uses, NTP-esque, the second is in provreg messages.

[SAH] I'd prefer to not cite a specific technical reference for reasons
noted above.  I would _really_ like to avoid requiring a method of temporal
synchronization in the protocol because it adds another layer of complexity
that be better handled by another protocol or another protocol layer.  I
agree, though, that temporal synchronization can be an issue if client and
server have to make independent time-based decisions that require
consistency and wouldn't object to adding a requirement that says something
like this (perhaps to section 8.2?):

[n] Protocol clients and servers MUST maintain a consistent understanding of
the current date and time to effectively manage objects with temporal
properties.

[snip]

<Scott/>