Subject: [Ietf-not43] Appendix B. Outstanding Issues

From: [email-masked] (Andrew Newton)
Date: Wed, 05 Feb 2003 11:12:21 -0500

Now that the draft has been in the repository for nearly 5 hours, I know 
everybody has read it, right?

Anyway, please note the addition of:
   > Appendix B. Outstanding Issues

After re-reading the notes and going back through the list and other 
email, these are the items that I think are still outstanding.  To be 
specific, they are not items I personally think are outstanding, they 
are items other group participants have mentioned for which I cannot 
even find proposed text (hint! hint!).

Also, please comment on any of the other text you feel is incorrect or 
needs to be fixed.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 05 Feb 2003 12:28:56 -0600

>From appendix B:

 | o  Internationalization - Because of Internationalized Domain Names
 |    (IDN's), it has been suggested that the requirements surrounding
 |    the support for them be further defined and more specific.

Actually my ambiguities aren't with domain names, they are with protocol
data in general. We haven't really discussed these issues, but we need to
reach some kind of group consensus on exactly what kind of localization
and internationalization support is needed. Note that RFC 2277 doesn't
really define strict policy on some of these issues.

>From my POV, these are some of the l10n/i18n issues that need to be
discussed in the requirements document:

 1) Attribute identifiers need to capable of being converted into
    a language/charset of the client user's choosing. EG, something
    like the "abuse contact" output identifier should be able to be
    converted into something other than English, as should search
    input. I don't think this is a problem with either of the
    current proposals -- both of them should allow the client to
    convert attribute identifiers locally without imposing
    additional protocol overhead or without breaking subsequent
    queries -- but I strongly believe that this should be a formal
    requirement anyway.

 2) Certain units of measure in attribute data needs to allow
    for client-side localization (dates and timestamps are the
    obvious elements). As with attribute identifiers, I believe
    this should also be spelled out with a formal requirement,
    but I'm not sure of the degree (see the following items).

 3) Attribute data in general should probably support non-ASCII
    characters and data. This is tricky stuff though. It would
    certainly be very nice if contact data allowed folks to
    actually spell their names, but how useful would it be for
    the service in general to allow this? I mean, I'm all for
    letting an admin in China actually spell their name and
    mailing address in the language of their choosing, but how
    how useful would it be to an IPR lawyer in Mexico?

    Is a reasonable compromise position that things like
    contact information MUST be provided in a format which is
    compliant with international postal regulations? Would
    that be sufficient? Does anybody know what they are?

    What about other kinds of data, like Comments data? Should
    that be unencumbered?

    In those places where we allow free data, should we require
    language and charset identifiers so that user-side translation
    agents can be used? Note that this is an absolute requirement
    of RFC 2277, section 4.2.

 4) Issues with certain kinds of structured data are also a
    concern (domain names, email addresses, etc), but since
    those attributes are structured they are a lot easier to
    deal with and have pretty much been figured out. However,
    there is still a need for a requirement for proposals to
    explicitly spell out how and where these attribute values
    will be transformed.

I think we really need to have a discussion on point 3 before we can come
to any kind of reasonable conclusion on the issue of l10n/i18n support in
general. What do you folks want to see, and what's reasonable?

Points 1, 2 and 4 fall under the structured data rule, although it may
require enumeration of specific attribute "classes" and their disposition.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 05 Feb 2003 14:50:15 -0600

>     that be sufficient? Does anybody know what they are?

Couple of useful links:

  http://www.upu.int/post_code/en/international_addressing.shtml

  http://www.columbia.edu/kermit/postal.html

General consensus is that all elements of an address should be used in the
native language/script of the recipient (the contact person), while the
destination country and zone information should also be provided in a form
which the originator country can handle.

In general then, I would think that the proper policy would be for contact
information to allow any language/charset, with two clarifications. First
is that country data must be tokenized, and second is that the remaining
elements MUST have language identifiers and MUST also pass the necessary
charset information (note that ~"MUST be provided in UTF-8" is a suitable
instance of this). This should allow for localization on the client side.

---

From: [email-masked] (Rick Wesson)
Date: Wed, 5 Feb 2003 12:59:16 -0800 (PST)

Eric,

Our requirements don't contain anything about formatting for delivery. We
do tag the elements though the description centric to the USA. While the
UPU encourages that a postal address be in local script AND roman scripts
the UPU only publishes 8bit ASCII data.

I propose that we have a 7bit ascii representation and a UTF-8
representation that MAY be used, butf the 7bit ascii representation is
REQUIRED.

kinda like we did in EPP.

-rick

On Wed, 5 Feb 2003, Eric A. Hall wrote:

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>

---

From: [email-masked] (Andrew Newton)
Date: Wed, 05 Feb 2003 17:23:27 -0500

> kinda like we did in EPP.

I think requiring 7bit ASCII isn't gonna work.  If the server doesn't 
have a 7bit ASCII form, having it make one up on the fly or withholding 
the info because it isn't 7bit ASCII is no better.

This is also true with the postal address format.  If the server doesn't 
have that data in the UPU form, then no amount of MUST language is gonna 
put it that way.

Plus, what if a particular registry doesn't want to support 7bit ASCII? 
  Or UPU formats?

My suggestion:
   The requirement should be that contact information should have a 
language identifier and a character set identifier (noting and accepting 
Eric's UTF-8 comment).  The protocol should also support multiple 
instances of the contact information with differing language/charset 
identifiers (such as, here is Yoshi's info in Japanese and here it is in 
Spanish).
   In addition, postal information should have a format identifier.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Wed, 05 Feb 2003 17:44:43 -0500

>     queries -- but I strongly believe that this should be a formal

I'd like to add this to 3.1.3 to make it clearer:

   The client-to-server protocol must define a standard set of
   data structures or schemas to be used when exchanging information.
   It must also posses the ability to allow for the use of newer
   data structures that are currently nor foreseen by this specification.
   In both cases, the description and specification of both types of
   data structures or schemas must be done in the same way (i.e. the
   same schema language).

   The schemas must also be capable of "tagging" data with a unique
   idenitifier.  This identifier can then be used to localize the name
   of that type of data.  For instance, a piece of data may have the
   value "Bob" and its type identified with the number "5.1".  Client
   software could use this to display "Name: Bob" in an English
   locale or "Nombre: Bob" in a Spanish locale.

Note that 3.1.3 already has some MUST/SHOULD language... this would just 
be in addition to what is there.

>     but I'm not sure of the degree (see the following items).

Anything much beyond dates and timestamps would probably be a big time 
pit.  Plus, I don't think we need to do anything beyond that anyway. 
Everything else should just fall back to the support of the schema language.

>     explicitly spell out how and where these attribute values

What do you mean by "transformed"?  I'm not sure why an email address 
would need to be transformed.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 05 Feb 2003 17:07:49 -0600

> identifiers (such as, here is Yoshi's info in Japanese and here it is in 

Just to raise the point. Multi-sourced data either introduces complexity
to the underlying protocol or adds to the transfer requirements. Either
the protocol has to support some kind of negotiation in the query (give me
the English version), or all of the data has to be transferred with the
client being the one who figures out which version to display.

I'm not saying that these aren't livable costs, just raising the point.

>    In addition, postal information should have a format identifier.

I'm not sure I understand what you mean here. If you mean what I think you
mean, then I'm not really sure its necessary since the individual elements
of the address data are provided as discrete units -- street address,
city, state or province, etc -- and their "format" ordering could
theoretically be handled with localization.

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 05 Feb 2003 17:17:06 -0600

> would need to be transformed.

For example, if the user enters an email address in its i18n form (perhaps
it got the email address in that form from a web page copy-n-paste), the
client may have to do the transformation into IDNA before the query is
actually submitted.

That specific process does not have to be specified in the requirements
document. What does need to be required is for proposals to describe when
and where any such codec transformations may occur.

---

From: [email-masked] (Andrew Newton)
Date: Wed, 05 Feb 2003 18:38:24 -0500

> I'm not saying that these aren't livable costs, just raising the point.

It's my guess that this will actually be a corner case and not the norm. 
  However, I don't think it is right to stipulate 7bit ASCII as a must, 
as this seems like a policy decision.

> theoretically be handled with localization.

I'm not sure why you want to tokenize or transform any of the components 
then.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Wed, 05 Feb 2003 18:43:05 -0500

> and where any such codec transformations may occur.

This doesn't sound like a protocol requirement.  It sounds like an 
implementation note.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 06 Feb 2003 10:29:02 -0600

on 2/6/2003 6:15 AM Hollenbeck, Scott wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt
>
> Section 3.1.2 and 3.2.1.

Thanks.

This is essentially identical to what Andy suggested:

on 2/5/2003 4:23 PM Andrew Newton wrote:

> identifiers (such as, here is Yoshi's info in Japanese and here it is
> in Spanish).

In both cases, multiple instances of contact data are provided together.
There isn't any negotiation, just identification.

The major problem that this introduces for me is that I can no longer
simply reuse the inetOrgPerson schema. This is okay from a work POV but
its undesirable from an LDAP directory POV.

---

From: [email-masked] (Andrew Newton)
Date: Thu, 06 Feb 2003 13:16:50 -0500

> its undesirable from an LDAP directory POV.

I take this to mean that it is doable but just not the purist approach. 
  Correct?

Some proposed text:

The schema for the contact data set MUST be able to contain an 
identifier indicating the language used for the contact data.  The 
protocol MUST allow multiple representations of a contact specified by 
the language identifier.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 06 Feb 2003 13:56:54 -0600

> I take this to mean that it is doable but just not the purist approach. 

Sort of. The underlying long-term value benefit to the LDAP-WHOIS model is
that it provides a baseline directory of Internet resources that other
applications can build on. But if the service itself can't use (and
therefore cannot provide) the inetOrgPerson schema for other applications
to leverage, then this is a huge gap in the benefit. That's a bit worse
than just sacrificing purity.

One potential workaround is to continue using inetOrgPerson for the
internationalized data, and provide an auxillary object class for the
ASCII contact data. That would allow other applications to use
inetOrgPerson in its pure form, while also satisfying the CRISP
requirement that seems to be developing. However, these two interests
don't necessarily mesh cleanly, so this wouldn't be a great solution for
either of them. For example, an LDAP focus would favor the
internationalized contact data over the ASCII data (we'd want to ensure
that inetOrgPerson tended to have the data), while a CRISP focus would
reverse the weighting (the word MUST has been used...).

There are also some issues with satisfying language tagging requirements
in this kind of model.

> protocol MUST allow multiple representations of a contact specified by 

I think we need to itemize a lot of different areas, and even in this
particular instance we are really talking about unstructured free text in
general (these rules also need to apply to comment blocks, for example),
and a particular subset of contact data.

Also, the 2277 MUST rules apply to charset and language equally.

Maybe something like:

Z.n The service MUST conform to RFC 2277 rules regarding textual data. In
particular, the protocol and/or schema MUST be able to indicate the
charset and language in use with unstructured textual data.

Z.m The service MUST be able to support multiple representations of
contact data, with these representations complying with the requirements
in section Z.n. The service SHOULD be able to provide non-ASCII contact
data in its natural form as well as in US-ASCII.

---

From: [email-masked] (Andrew Newton)
Date: Thu, 06 Feb 2003 15:58:17 -0500

> data in its natural form as well as in US-ASCII.

My stab:

   The schema defining domain related resources MUST conform to RFC 2277
   regarding textual data.  In particular, the schema MUST be able to
   indicate the charset and language in use with unstructured textual
   data.

   The protocol MUST be able to support multiple representations of
   contact data, with these representations complying with the
   requirements in Section XX.  The protocol MUST be able to provide
   contact data in UTF-8 and SHOULD be able to provide contact data in
   US-ASCII and other character sets.

After just re-reading 2277, it says that UTF-8 is a MUST unless a 
variance is provided.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 06 Feb 2003 15:07:11 -0600

>    US-ASCII and other character sets.

Add something about language tagging to the last part and I'm happy.

Can the MUST-use-ASCII camp can live with it?