<<<
Chronological Index
>>> <<<
Thread Index
>>>
[ssac-gnso-irdwg] Discussion topics for IRD
- To: "ssac-gnso-irdwg@xxxxxxxxx" <ssac-gnso-irdwg@xxxxxxxxx>
- Subject: [ssac-gnso-irdwg] Discussion topics for IRD
- From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
- Date: Tue, 22 Dec 2009 07:51:47 -0800
As requested, here is a list of discussion topics that have been raised
during the past several meetings. I've tried to group some sub-topics under
these that seem related, and I've tried to use "simple" language along with
the technical to get us focused on big picture early on.
My interpretation of the notes and prior work is that three topic area seem
to surface repeatedly. I hope you find this accurate and sufficient for our
initial needs.
At this time, the topics on this list are presented for discussion purposes
only. The list is also limited to allow the group to focus and gain some
traction. Other topics may not be present. This does not mean they are not
relevant or necessary. Please do add to the list if something you feel is
important is missing.
1) What do we require from internationalized registration data?
a) that a user can submit or have a domain name displayed in
the IDN A-label (xn--) format or U-label (local language
readable) format?
b) that registration data be extensible to accommodate users
who would benefit from the ability to submit and have registration
information displayed in "familiar" characters from local
languages and scripts?
c) Does (b) imply several representations of the same registration
data, but in different languages or scripts?
i) Related to c), and to avert a possible Babel effect,
is it desirable to adopt a "must be present"
representation with optional collection/display of
registration data for the convenience of "local users"?
ii) Related to i), should we consider adopting a
"format for civic address information that's reasonably
functional around the globe"?
(cf. Thomas Roeffler, in his reply to Steve Crocker)
iii) Related to c), is it possible to adopt an ICANN policy
that both meets the expectations and needs of internet
users around the globe and has a high probability of
adoption by ccTLD operators as well?
d) that registration data be collected and displayed (or returned
via a whois/port 43 or successor protocol) *uniformely*, in manners
that would allow applications to process the data efficiently? In
particular, should applications that do not involve
humans (automation) not be complicated by variations across
display/collection practices/policies by registries and registrars?
e) that some filtering or processing be considered to reduce the
opportunity for deception/misuse when characters from
multiple scripts are used in the composition of certain
registration data? While perhaps not a perfect fit, are the
prohibitions of mixed-scripts in the IDN guidelines that
applied to labels of a domain name representative of
the opportunities we might attempt to define?.
2) What should the registration data look like?
a) some form of tagging of the data to identify the piece (object),
i.e., "this is a contact address"
Using XML, for example, such a tag and the data might look like
<contact-address>3 Myrtle Bank Lane</contact>
b) alternatively, tagging of blocks of data where a group of objects
such as an administrative contact would be tagged
Using XML, for example, such a tag and the data might look like
<admin-contact>
David Piscitello
3 Myrtle Bank Lane
Hilton Head SC 29926
...
</contact>
c) some means to identify the language or script that the characters
in the data "belong to"
d) should some elements of registration data always be represented
in US-ASCII7 (e.g., sponsoring registrar)?
3) What methods of delivery (protocol) are needed to support IRD?
How does internationalizing registration data effect existing protocols?
a) IRIS/CRISP are suggested in SSAC recommendations
b) XML over HTTP are used by ARIN/RIR's RWS service
c) Impact to EPP?
d) Complexity to Whois/port 43, web-based interfaces?
e) Is IETF vcard work relevant?
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|