Subject: [Ietf-not43] [Fwd: CRISP: Language/script-specific data sets? ]

From: [email-masked] (Hollenbeck, Scott)
Date: Thu, 26 Dec 2002 20:05:48 -0500

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, December 26, 2002 4:52 PM
> To: [email-masked]
> Subject: [Ietf-not43] [Fwd: CRISP: Language/script-specific 
> data sets?]
> 
> 
> I received the following comment off-list.  It sounds to me like a 
> reasonable basis for a requirement.
> 
> -------- Original Message --------
> Subject: CRISP: Language/script-specific data sets?
> Date: Wed, 25 Dec 2002 13:12:56 +0100
> 
> Dear Andrew,
> 
> I'm contacting you since you are the author of the
> crisp-requirements Internet-Draft.
> 
> I notice that this draft, while it does talk about
> internationalization in relatively general terms, lacks what I
> believe to be a key requirement for an internationally useful WHOIS
> successor service.
> 
> In Asian countries (but not only there), there may be ways to
> express the same physical contact data in scripts appropriate for
> different kinds of users: For instance, you'll have "Hotel
> Intercontinental, 777 Zhangyang Road, Shanghai" (don't expect the
> local taxi driver to be able to read this), and you'll have a
> Chinese name and address which I can't read (but the taxi driver
> understands).  For CRISP, this means that there should be provisions
> for some language- or script-based polymorphism -- like a more
> advanced version of the "/EN" switch known from the .jp WHOIS
> service.

FWIW, in the provreg WG protocol we're providing the ability to provision
contact data in two character sets.  It would probably be a good idea if
there were provisions to display one or both forms using the CRISP protocol.

-Scott-

---

From: [email-masked] (Ted Hardie)
Date: Fri, 27 Dec 2002 10:51:23 -0800 (PST)

> there were provisions to display one or both forms using the CRISP protocol.

Scott,
	I just looked through draft-ietf-provreg-epp-contact-05.txt,
and it looks like you have two different mechanisms which are related
to this problem.  One is the "lang" based negotation for the response
codes which is described in described in section 5 of
draft-ietf-provreg-epp-07.txt.  If I read that mechanism right, you
can at session start negotiate the "lang" attribute for the human
readable text associated with a response code.  This doesn't affect
the charset which SHOULD be UTF-8 unless a charset has been named.
(By the way, would this also affect things like the human readable
text in a statusValue?).
	The other mechanism would be charset related, and is described
in 2.3 (and again 2.4) of the contact draft:

  Individual and organizational names associated with a contact are
  represented using character strings.  These strings have a specified
  minimum length and a specified maximum length.  Individual and
  organizational names MAY be provided in both UTF-8 [RFC2279] and a
  subset of UTF-8 that can be represented in 7-bit ASCII depending on
  local needs.

	I read this to mean that they may be in *either*.  Does it in
fact mean that they will always be in in UTF-8 and may also be in the
subset of UTF-8 that can be represented in 7-bit ASCII?  If so, I
didn't see how which to present was negotiated in epp when both are
present.  Do you always send both when both are present?
			regards,
				Ted