Page History

GNSO/SSAC
International Registration Data Working Group
TRANSCRIPTION
Monday 07 December at 14:00 UTC

Note: The following is the output of transcribing from an audio recording of the GNSO/SSAC
International Registration Data Workign Group on 07 December 2009, at 14:00 UTC. Although the
transcription is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages
or transcription errors. It is posted as an aid to understanding the proceedings at the meeting, but
should not be treated as an authoritative record. The audio is also available at:
http://gnso.icann.org/calendar/index.html#dec
http://audio.icann.org/gnso/gnso-ird-wg-20091207.mp3

All recordings and transcriptions are posted on the GNSO calendar page:
http://gnso.icann.org/calendar/

Present for the teleconference:
Edmon Chung -- GNSO Registry Stakeholder Group, .ASIA
Steve Crocker, Chair, SSAC, Shinkuro
Rafik Dammak -- GNSO Non-Commercial Users Stakeholder Group
Bob Hutchinson, GNSO Commercial Stakeholder Group
Yao Jiankang, GNSO Registry Stakeholder Group, CNNIC
Mark Kosters – SSAC, ARIN
Steven Metalitz -- GNSO Intellectual Property Interests Constituency, Commercial Stakeholder Group
June Seo, GNSO Registry Stakeholder Group, VeriSign

ICANN Staff
Francisco Arias
Glen de Saint- Géry
Gisella Gruber-White
Julie Hedlund
Dave Piscitello
Steve Sheng

Absent apologies:
Jeremy Hitchcock
Avri Doria

Gisella Gruber-White: Good morning, good afternoon to everyone. On today’s IRD call Monday the 7th of December, we have Rafik Dammak, Edmund Chong,(June Seo Steve Crocker, Robert Hutchinson Yao Jiankang Mark Kosters, Steve Metalitz.

From staff we have Julie Hedlund, Steve Sheng, Dave Piscitello, Francisco Arias, and myself Gisella Gruber-White.

We have apologies from Jeremy Hitchcock. And I hope I haven't left anyone’s name out. And if I could also please just remind everyone to state their names for transcript purposes. Thank you.

Julie Hedlund: Thank you Gisella. That was excellent. I appreciate it.

Edmund, shall I go ahead and go through the agenda?

Edmund Chong: Please go ahead.

Julie Hedlund: Great. So for the agenda today, first item of business is that Jeremy Hitchcock has volunteered to be the co-chair from (AFAC). And we can discuss his candidacy and hopefully accept his volunteering, discuss the scope of the work group and that’s related to the discussion last week of the scope of the work group and if you perhaps expand on that discussion, discuss a draft of the work plan and deliverables.

And I added an item to the agenda which I had neglected in the one that I sent out. And that is to discuss timings of future meetings and to see if we can arrive at a regular meeting time.

And that was all I had on the agenda. But I'm happy to add anything else that any anyone else wants to suggest.

Thank you. So our first item of business is that Jeremy Hitchcock has volunteered to be the co-chair representing the (AFAC).

As you may recall the charter, draft charter has - is set with co-chairs, one from GNSO. And Edmund Chong has graciously volunteered and then accepted to be the co-chair from GNSO. And the other co-chair is to be from the (AFAC).

Are there any questions or objections to Jeremy becoming the co-chair of this work group?

Mark Kosters: This is Mark Kosters. I’m very supportive.

Julie Hedlund: Wonderful. Well hearing no objections, and hearing support then I will record that Jeremy Hitchcock is now the co-chair of the work group from (AFAC).

Edmund Chong: This is Edmund and I'm really happy that somebody from (AFAC) has volunteered. And I welcome Jeremy on board.

I understand that he couldn't join us today but that’s a great relief for me at least more people, you know, someone from (AFAC) is taking part of the load for bringing this important group forward.

Julie Hedlund: Great. Thank you Edmund.

Next item of business was to get back into that discussion of the scope of work. And I should note that some - there were - the staff provided a couple of helpful items on the list.

And one was Dave Piscitello had sent around a memo summarizing the work that he had done in looking at some alternative schemes.

And Steve Sheng sent around also a summarizing of the related work on the Whois studies.

But if you recall in the discussion that we had last week the work group scope mission and goals, we were wondering whether or not, there was some discussion as to whether or not there should be maybe a slightly different approach or a fresh approach a little bit perhaps standard or different from what’s in the charter.

But there also were concerns that for instance, for example, that determining the content was not in the scope of the work group. And it said that the work group should focus on the suitability of display (specificity).

And just remind us - and the charter is up and linked from the wiki by the way -- the - in the scope of the work written in the draft charter as it stands now -- and of course we can alter this, it talks about how the goal is sort of taking off from the recently published (AFAC) Fact 37 which examines how the use of characters from local scripts effects the Internet user’s experience with respect to the main name registration data submission usage and display.

There was a Webinar scheduled in September on this issue. And also a presentation was made at the ICANN meeting in Seoul. And that presentation also is linked on our wiki.

And following these already, you know, produced events, the IRD in the charter says shall produce the study of the feasibility and suitability of introducing display specifications to deal with the internationalization of registration data.

So that is the base scope. And we as I mentioned, had some discussion around that. And I'd like to see if we can get that discussion going again. Is there somebody who would like to begin?

Okay perhaps I could begin us by asking a question. There was some discussion last week about the scope and whether or not for example, we wanted to - whether or not the group should take a fresh approach of looking at the current requirements and future needs and the handling of various forms of tiered access.

Should the workgroup look at for example, the design of a prototype and should we only focus on existing tools but should we look at new tools?

And do we - are we looking at both the content or do we feel that that’s not in the scope of the workgroup and so then focusing specifically on feasibility of display specification types and kinds of data?

And do we want to - my question is does the workgroup want to rewrite or make more specific the scope of the work as it’s written in the charter? And, you know, how do we want to define this scope because that obviously is going to drive our deliverables and our work plan.

Edmund Chong: This is Edmund. Hello?

Julie Hedlund: Hello Edmund. Please go ahead.

Edmund Chong: Hello? Oh, okay. I realize I was on mute earlier on. Just a couple things, one, I think last time we talked about having Dave’s paper. I'm not sure whether it was that - I did see the link to the presentation. I'm not sure whether the - a paper was actually produced. That’s one.

And then the other part, I really think it’s I guess my personal opinion, I'd like to hear more from others.

I think that the higher priority with this group is probably the requirements and to a certain degree your specification for allowing internationalized registration data.

Well then all the other stuff I understand that when we talk about the actual implementation it has implications. But we should probably start with a set of, you know, requirements with the internationalized registration data.

That’s sort of my personal view at this point. But I'd like to share more what other people think and in terms of prioritizing for immediate goals and things to discuss.

Julie Hedlund: Thank you Edmund. Actually Dave Piscitello did send around a memo to the group last week I believe it was or I sent it around...I should say. And Dave, did you want to speak to that at all?

Dave Piscitello: You know, the paper essentially summarizes three, you know, there’s three areas that the, you know, that staff and some (AFAC), you know, members had investigated, you know, in terms of trying to understand other areas where - other communication forms where it was necessary to consider both the local language and the language of the recipient of either correspondence or of information that might be visually displayed or shared.

And we use the Universal Postal Union standards and formats for addressing letters as an example of, you know, of how this problem is dealt with in the postal delivery of mail crossing country borders.

There was also, you know, the work that (Aaron) has been doing in terms of the Whois RWS service that’s described in that menu. And it’s relatively short. It’s only about three pages. It’s not particularly heavy reading.

But mostly - and the third area was a very, very informal poll conducted among ccTLD operators regarding their current, you know, collection and usage and display beyond the US ASCII-7 that was traditionally used for Whois services.

And in that particular anecdotal study we only obtained information from about 16 ccTLD operators. And the summary of those of what was reported to us is included in that paper.

So and essentially one of the things that you can observe from all three of those is that, you know, and especially in the context of the Internet, one of the things that you could conclude -- and this is not necessarily the only conclusion -- but that perhaps there’s a - there’s something appropriate in considering having a continued mandatory obligation to collect data in US ASCII-7 but, you know, have as a second, you know, source of information collection collection in a local language and script.

And that’s essentially the way that the UPU actually, you know, actually does this. You know, there is a standard in using, you know, using “English characters” as the format for the delivery address.

But for the, you know, for the recipient you can also include information in the characters for the, you know, to facilitate the delivery in a country where perhaps some of the postal delivery staff aren't familiar with English.

So if you’re going from California to, you know, to some city in China it’s actually sort of the convenience of the - of perhaps the Chinese postal delivery staff that you in addition to putting the English representation of the delivery address, you put the Chinese character equivalent as well.

And so you can easily envision how that might, you know, might work with Whois instead of simply collecting the registration data in US ASCII alone. You can also and alternatively collect it in a second, you know, second, you know, set of characters from a local language.

And it appears that some of the ccTLD operators, I think ten of the 16, actually have adopted a variant or a very similar style of usage and display and collection to that model.

You know, if you look at some of the countries that I'm mentioned in that paper you'll see that they collected US ASCII-7 but they also allow for the collection and display in UTF-8 or UTF-16.

Julie Hedlund: Thanks Dave. That’s very helpful. So...

Robert Hutchinson: Dave, I have a question. This is Bob Hutchinson.

Dave Piscitello: Sure.

Robert Hutchinson: In the scripts where they’re currently doing this, did they have difficulty representing the addresses in US characters as well?

I would think if I were Chinese and, you know, just trying to sign up for a domain name, having the obstacle of having to represent my address in English characters, who gets the burden of actually doing that?

I'm just trying to clarify, you know, who we might be asking to do this in the future.

Dave Piscitello: And that’s a good question. And that’s not one of the questions that we actually managed to, you know, to get clear answers for.

What we essentially asked was do you do this? And the answers were more or less yes and no. The degree of difficulty in doing it wasn't something that we explored.

And the other alteration I’ll make is that the languages where this was done were languages where the root character set, you know, is UTF-8, not UTF-16.

And it’s usually the languages where it would be the extension of the - let me get this right, Latin characters that are represent - represent English plus those that complement for Spanish in South American countries or complement for Swedish or German or one of the other languages where it’s an extended ASCII as opposed to an entirely new set of glyphs.

Robert Hutchinson: So to clarify, you’re saying that that ten of the 16 who are doing this are using extended Roman, not in general for both sides they would be using the (standard) Roman in one side and short in the other or is it something different? Are you saying that...

Dave Piscitello: Well that’s a better characterization. It's, you know, it’s the languages like German where you would have a dieresis or like Spanish where you would have a tilde...

Robert Hutchinson: Right.

Dave Piscitello: ...in addition to what we would consider a regular N in, you know, as English-speaking Whois users.

I would have to go back and take a careful look at the list to, you know, to confirm that though Bob.

Robert Hutchinson: Yes.

Dave Piscitello: As I said, it was only 16 countries. It wasn't meant to be anything definitive. And it was...

Robert Hutchinson: No. I'm just trying to get a characterization of what you actually are presenting. And that’s very helpful. Thanks Dave.

Dave Piscitello: Yes I think it's, you know, and in the paper one of the things I mentioned is that it might actually be very useful to try to get - to agree on a formal set of questions and a formal survey that we might be able to impose on the ccNSO staff to conduct as long as it’s not a huge number of questions where we could answer precisely what you’re, you know, what you’re asking.

Because, you know, the devil is in the details in a lot of this. It’s relatively simple to say let’s keep on US ASCII and let’s complement it with a set of second registration data.

But the mechanics of how you do that, you know, is still going to be a persistent problem for people who don't, you know, aren't familiar with Roman characters as you said.

Robert Hutchinson: Okay. Thanks for clarifying that.

Julie Hedlund: Thanks Dave and thanks Bob. Other questions for Dave? That’s an interesting suggestion Dave of doing maybe a more formal survey with a limited set of questions that perhaps could be conducted with the ccNSO staff.

What do other people think about that as a way of maybe gathering some more information to assist the group?

Edmund Chong: This is Edmund. I think the - a survey would still be with broader context is definitely a good idea.

But one of the things about the study - well first of all sorry Dave. I - for some reason I didn't get the notes earlier on, probably fell into my spam or whatever.

But - and part of it is that even though they’re providing that by Whois in a sense, the question might be that or the study might need to look into a reverse - the perspective whereas tools where - who tools are not IDN aware in a sense or, you know, internationalized data aware, how they respond to receiving that data when they’re, you know, when they’re presented with that data needs to be also studied. Not just from the supplier or how should I say it, from the registry point of view presenting the data and sending out the data, but also the tools and applications that receive the data and how they react or not react to it.

Dave Piscitello: This is Dave Piscitello again. I think it might be worthwhile if Mark Kosters wouldn't mind to sort of, you know, describe the utility of having a formal data schema and being able to actually automate in a, you know, in a world. As opposed to relying on, you know, what has essentially been freeform ASCII submission and storage, you know, as we have for so many years.

Mark Kosters: Well Dave is kind of leading on that what you want to do is you want to be able to have people say hey, I want to have this query be uniform in terms of what I'm asking for and what I can - I actually expect to see back from the server itself.

So it doesn't mean - so what it means is that you don't have to go to each server and say well this guy has this little peculiarity here so I need to create it this way. And it becomes something that’s actually easier to actually get information from for all.

Dave Piscitello: So as an example -- this is Dave Piscitello again -- if you look at the way that many applications process Whois today, they essentially have to look for what’s called, you know, delimiters or whitespace, you know, essentially spaces that don't contain characters.

And they have to understand the order in which the registrar is collecting, you know, collecting and storing each of the individual pieces of information that are acquired by the RAA that compose a registration record.

If you, you know that’s, you know, a very, very antiquated form of, you know, collecting and storing data because you don't know anything about the data.

You only know that it’s - yes, that when you encounter a space you are now - you’ve now reached the conclusion of one piece of data and then the next character that’s not a space is the beginning of another piece of data.

So if you think about a different way doing that where what you have is something of a tag that tells you not only what the data are that you’re encountering but what it’s supposed to look like, whether it’s supposed to be a number, whether it’s supposed to be a glyph from a character set that’s used by Chinese, whether it’s supposed to be a glyph from a character set that’s used by Koreans, whether it’s supposed to be a name, whether it’s supposed to be an address, whether it’s supposed to be an IP address - if you have all those little tags in what’s called a data schema, each of the data objects can be, you know, can be placed in whatever order you want.

And automation can simply say I'm looking for the IP address. And it’s going to go and it’s going to sort through the registration data for the IP address.

So I’m looking for the domain name. And it’s going to go and it’s going to sort through the domain name.

And you can even break it down, say I'm looking for the domain name in the unit code or the Unicode format.

And so the value of looking at the way that you store data in parallel with looking at the, you know, the issues surrounding internationalized registration data is reasonably compelling.

And it’s not that we have to actually define new data, but one of the things we might want to, you know, to consider very carefully is that it would be relatively easy to envision.

And if you go and you look at the RN implementation, it’s fairly simple and straightforward to see that there’s this whole set of data that are collected and every piece is tagged.

And so if we want to have an exact duplicate of that that says here’s the Roman version, Roman character set version and here is the Unicode encoded version of, you know, of that same information in whatever language the operator chooses to accept and, you know, and display, you've got a head up because now automation falls directly in line with whatever recommendation you have.

Julie Hedlund: Thanks Dave. This is Julie. That was helpful. Other comments on that?

So let me try to understand. So you’re talking about whether the group should consider having each piece of data tagged for easy identification?

Dave Piscitello: I’m saying that that’s one of the observations from looking at what (Aaron) has done with the Whois RWS service is that what makes that real nice in addition to the extension that, you know, the other extension is that you can really see the utility in having a formal structure to the data. And that’s absent in the current, you know, in many of the current implementations.

Now if you look at some of the registry agreements you'll see that they actually have extended meta-language, XML data structures defined for their registration data.

And perhaps that’s something that the committee ought to look at carefully and say, you know, should this be what, you know, what all registries should, you know, strive to, you know, to implement? And what - if they all were to have that, how much more would automation be facilitated?

And then as a successor to those two questions, if it’s facilitated significantly, would it - would this also help us with dealing with the international registration data?

Julie Hedlund: Dave, this is Julie. Thank you for that. Are there other - do others have some comments now on this - these suggestions by - that Dave’s put forward?

Mark Kosters: So Dave this is Mark. I do have a question. I totally get the uniform schema. I'm - where houses relate to like a uniform postal code and in terms of that’s really defining what the schema is, is that in scope or out of scope of this requirement stock?

Dave Piscitello: Well I mean that’s really up to the committee, not staff. I mean if you’re asking for a personal speculation, and again, you know, I think Bob Hutchinson’s comment is really important.

Because from a technology standpoint, you know, supporting a set of registration data in Roman characters and supporting an alternative for a complementary set of registration data in whatever the local user might feel comfortable submitting and displaying is a relatively simple thing.

Instrumenting that so that there’s not an undue burden on the registrant or the Whois user or the registrar or registry is kind of a tricky thing.

And that’s where my, you know, my limited knowledge and utility of languages that don't involve Roman characters is, you know, making it much more difficult for me to understand or extrapolate.

So I think, you know, Edmund or Steve Sheng or some of the other members might be able to weigh in, you know, on exactly - well not exactly but on, you know, speculate on just how hard that might be.

Julie Hedlund: Mark, does that - did that help address your question?

And then just to emphasize too as Dave said that the -- and this is Julie -- that the scope right now is in the draft charter of the scope of the work of this team.

But it is up to this working group to decide, you know, how to set the scope for this work. And, you know, to decide whether or not to expand it or to be more precise with it other than how it’s currently written. It’s currently fairly open in the charter.

Mark Kosters: Well I'm sorry, I must be a little bit dense. But I am a little bit - I'm still a little bit confused but please others please weigh in.

Dave Piscitello: Okay so Mark, this is Dave again, just maybe one more clarification.

I think that there are two ways to look at whether we’re going to suggest changing the data.

One is by - one is what I previously said. Instead of keeping one registration record containing all the exact same elements that we currently collect today, we keep two. One in the base accepted language like US ASCII-7 or accepted characters at US ASCII-7 and a second in a local language.

I think that’s substantially different from saying while we’re studying internationalized registration data we think it’s no longer useful to collect facts, numbers. So let’s just strip that out or we think that it'd be useful to have some sort of indicator of, you know, of the reseller that’s associated with the sponsoring registrar. Let’s add that.

So I think that those are two different issues. I would caution the committee in going down the path of let’s change the data that are collected today in terms of each individual field.

I think it’s a different thing to say. It’s really useful especially from the sake of automation to have more format to the data and think about having both the traditional US ASCII 7 encoding plus a second encoding where useful.

Mark Kosters: Okay that’s cool. I was just making sure that we weren't saying well we should mandate the use of internationalized postal codes and everybody needs to have a country a street or whatever, you know, and names -- that sort of thing.

Dave Piscitello: No, no I'm sorry. If that was the confusion yes no, it’s certainly not going down and looking into the syntactic and, you know, and semantic detail of everything that the UPO collects.

It was simply that the observation that they would display the Roman characters and then display it in another character set for the convenience and utility of the recipient country.

Mark Kosters: Good, good. Thank you. Thank you very much.

Julie Hedlund: Yes Dave this is Julie. Thank you for that. So not - so the working group would not mandate, you know, mandate collecting two types of data, one in English and one in, you know, a local language but could suggest an additional format, you know, in addition to what is currently being collected. Does that sound right?

Dave Piscitello: Well what we would want to be careful about is going in and rewriting what a registration record looks like which is I think what Mark’s concern is.

So we’re not going to go change any individual information that is currently collected today.

If you think of it in terms of instead of having one registration record having a registration record that is - and that where all the fields are captured and stored in ASCII-7 and then where it’s beneficial all the fields would be - accepted and stored in a local language. Conceptually that’s the model that the UPU uses.

Edmund Chong: This is Edmund. I - hello?

Julie Hedlund: Go ahead Edmund.

Dave Piscitello: Yes?

Edmund Chong: Yes, I just want to sort of add to the point that was made earlier on in terms of not changing the existing ones.

I guess that that also, I'm not sure, you know, what other people think. But I guess that also goes to not only the collection of the data but also the presentation in a way of that data.

We can probably talk about how we collect internationalized registration data and also how we should present that data back to the user but, you know, even including, you know, whether it’s structured or not.

But the existing ones as much as, you know, I think it’s great to have the structure, we do understand that the current system does not have that structure is I wonder whether, you know, it is within the scope with for us to make a recommendation to add that, you know, those tags and for the existing data as well as to, you know, that’s sort of my question. I’m hoping to hear more from others in a way.

Julie Hedlund: Thank you Edmund. This is Julie. Do others have comments on the question that Edmund just asked?

Edmund Chong: If I can make it - try to make it more clear is that, you know, we went down the path of saying that the Whois data, it’s great to have it tagged when we receive it.

And, you know, when it’s presented by for example, the registry or the registrar. But I - I'm curious as to, you know, if we say the internationalized data should be structured, that is probably within the scope.

The question is whether, you know, other general or the existing part of data are we - is it within the scope of our discussion that we could recommend whether or not that that also should be somewhat tagged or structured?

Dave Piscitello: I - this is Dave again. I - Edmund I think what you’re asking is could the working group go back to the GNSO with a recommendation that they RRA, yes RRA consider the RRD’s suggestion that future versions of the RRA should establish a standard data structure for registration, your registration data as opposed to simply saying these are the fields that you collect.

Man: Sort of. And also not just the international voice part but also the existing part.

Dave Piscitello: Yes, I - yes. I think that recommendation is or at least a discussion of the issues related to that are going to be addressed in a Whois service requirements study that Steve Sheng and I are preparing for the GNSO.

And so knowing what’s going on in that particular work area and, you know, and the direction that staffs is probably going to, you know, to comment on to the GNSO in Nairobi, I don't think it’s necessary for the RRD to do that.

Because I think I'm fairly confident that (Steve) and I are going to recommend that in the Whois service requirements work that we’re doing at the request of the council.

Man: Okay.

Edmund Chong: So it seems to me, you know, it’s sort of the discussion brings back to that I think probably the important few party stuff would be to try to figure out the requirements for, you know, some sort of a checklist of requirements for receiving these international - internationalized registration data, at least for this workgroup. And, you know, how - what types of data we need and how we want it, you know, the format we wanted in and also the format we would be presenting, you know, registry or registrar’s would be presenting them in. Am I categorizing it in a sensible way?

Dave Piscitello: I think so. Again that’s Dave.

Julie Hedlund: Do others have comment on what Edmund has suggested as a priority to for this working group to figure out the requirements for receiving the internationalized registration data, what types of data are needed on and the format that the data are presented in? Did I say that correctly Edmund, capture that?

Edmund Chong: Yes I think so.

Julie Hedlund: Other comments on that? Mark from your point of view do you think that would be something that would be a good place to start for this working group?

Mark Kosters: Sure.

Julie Hedlund: Bob what do you think? Does that - would that, I mean as far as our isolating our first step, you know, something that we could start work on to help sort of frame our deliverables starting with a set of requirements or a list of requirements?

Anybody else have any thoughts on this?

Edmund how do you think would be a useful way...

Robert Hutchinson: Sorry I was mute.

Julie Hedlund: Oh I'm sorry Bob. What did you think? I'm sorry?

Robert Hutchinson: I said I don't know whether we have a - there’s many different levels to this problem. And I don't know whether we have consensus today or we’ll have consensus shortly about using a tagged data format.

I don't - personally I'm supportive of that. I think that we need to pursue that particular structure for the foundation. And on top of that, the rules for what data need to go in that for a particular language are subject to the form of the uniform postal addressing schemes and so on and so forth.

There’s a significant amount of work necessary to figure out from this group’s standpoint where you’re going to divide, where you’re going to draw the line as to what you’re going to put in a specification.

And, you know, so to me that’s going to be the hard - one of the harder things to sort out.

I heard Steve Metalitz last meeting say that he would like to see this group concentrate on just the technical standard and not the meta standards above that in terms of the actual content itself that goes into the Whois.

And I don't know whether we have consensus about that as a charter yet. So those I think are the biggest problems we have in front of us is to try to figure out how to draw lines at this early stage. Maybe it’s not possible.

Maybe what we’re going to have to do is we’re going to have to do a little more inquiry and a little more examples, you know. I guess the chair will have to sort of figure out what that what (unintelligible).

Julie Hedlund: Bob thank you. This is Julie. Thank you very much. Your last point I think is interesting to whether or not it might be useful to have more examples.

And we talked earlier about the possibility of doing a survey among, you know, within the CTS ccNSO.

Edmund, what do you think about starting with a survey to try to gather a little bit more information to help us figure out what we think the requirements might be?

Edmund Chong: As I mentioned earlier on, yes I think having a survey is a good idea. But I also think we probably shouldn't be too much predisposed with that from - this is really just from personal experience. You know, having ccTLDs, having worked with ccTLDs about this specific issue.

With no disrespect there’s the goals of which might not be the same as ccTLDs for an example, in the adherence to standards and the adherence to certain principles. It may, certain local situations might trump those considerations.

So whereas I think it’s good too, you know, do the survey I also, you know, I think we should, we would need to, I guess the group needs to take the information from the survey with a bit of a grain of salt in terms of what we find.

Julie Hedlund: This is Julie, Edmund. Thank you. That’s very helpful. That leads me to another question.

Could it be possible for us to, I mean and the staff of course can assist, but to for the working group to come up with some, you know, list of requirements that then the working group could consider and say yes, we think this is, you know, in scope or, you know, we think this is not in scope, just as a way to help us move forward to a consensus?

Because I, you know, I understand too, you know, what Bob has said. And that is that, you know, while there might be - it might be useful and there might be some agreement on whether or not there should be a, you know, a requirement for a tagged format, there’s also, you know, a significant amount of work involved and, you know, where we draw the line between sort of the content and the technical specification.

Do we - my question is I guess, do we feel that we have an understanding of where that line is or would it help us to help define, you know, what we can agree on in this working group by coming up with say a set of draft requirements?

Edmund Chong: Yes. I think I would sort of call that stock taking in a way, you know, just listing out all the items and sort of like, you know, that were discussed and let the group discuss whether that's, you know, out of scope or within scope. That’s probably good idea. That’s definitely a good idea to get started.

And on top of that also, you know, I guess we can also start, because of the information that both the initial 16 or so ccTLDs were surveyed. And probably, you know, doing a few more, if we could also from there have a checklist or a stock - and a stock taking list of the types or fields of data that needs to be internationalized or would, you know, would be included in terms of internationalized data, that might also be useful.

Julie Hedlund: This is Julie. Thank you Edmund. Bob what do you think about that as a starting point? Just sort of come up with a list of items using sort of as a starting point some of the information that we’ve gathered from the 16 ccTLDs in the survey, maybe putting this in the form of a checklist and the types of fields of data that need to be included in internationalized registration data?

And just as a - and then, you know, for the working group to look through that list and say yes, we think that this is in scope or, you know, no we think this is out of scope, do you think that would be a useful place to start?

Robert Hutchinson: Yes. I think that I'm - I guess I'm not pro-driving in the rearview mirror so much. I'd like to like not spend a whole lot of, you know, like months of time digging through what other people have done in this area.

But I think that Dave's, you know, two page white paper pretty much lays out the scope of the problem and some possible ways forward.

The areas that I’m not, you know, I guess I need to re-educate myself more is in the uniform postal - the universal postal union formats.

Are those formats expressed in a way that easily map into the kind of tag data structures that we’re talking about or is that something that if we walked down that particular avenue, do we have to enumerate for each format of the UPU address forms, what tag data we’re talking about?

If that’s the case then we've got a, you know, essentially a database of address forms and so and so forth which is a possibility. But I'm saying, you know, if that becomes the scope of, you know, in scope or of this working group, this working group’s going be permanent and it’s going to be around for five years.

So, you know, it...

Dave Piscitello: Bob this is Dave again.

Robert Hutchinson: Yes.

Dave Piscitello: I actually don't think we need to go into looking at the specific format of, you know, the UPU address standard.

As I tried to make clear to Mark earlier, all I really wanted to draw from that analogy is that the address in its entirety irrespective of what, you know, what fields you consider is presented in Roman characters.

And then if it - you know, if the sender believes it would be convenient to the destination country postal handlers, you would also put as much information as you could transliterate or transcribe into another set of characters so that you would make - you would facilitate the delivery of the letter or the package. That’s really the principle on which the UPU standard is written.

So we wouldn't have to go and actually say there are all these different conventions of what we currently today set call the contact information. We could leave that the way we have it.

What we wouldn't want to try to do is say that or what we might want to do is say that we’re going to collect what we collect today in Roman characters because that’s the way we've done it before and because there’s, you know, there’s a good reason to believe that many people continue to do that today.

In addition to that there’s this whole other set of data that we could collect for the convenience of local users in, you know, who are either registering domain names or want to be able to view Whois in a convenient local language.

Julie Hedlund: Dave this is Julie. That’s helpful. Bob, does that help sort of narrow the scope a little bit what Dave has said, that we’re really not necessarily looking at saying we’re going to take the UP standard and let’s just move it on over.

But there’s a principle of, you know, collect what you’re collecting now and then where it’s beneficial you can collect these, you know, these other things in local language?

Robert Hutchinson: Yes. So I guess what I don't understand Dave and maybe, you know, somebody with more expertise in international postal or international addressing, you know, when I read this stuff that I've read about this is in the case of European postal systems, mostly what we’re talking about is UTF-8 with different forms if you will, of the address.

But I'm not sure when I get into China or the Philippines or, you know, some of the other more exotic localities of the world, how close it, you know, how close to addresses map in those native languages to the kind of problem that we’re looking at, you know, relative to say a US address versus a Netherlands address or a French address.

You know, are we talking the order of the same kind of magnitude in terms of data representation shift or are you talking about something like totally different, okay?

And, you know, I don't - I just don't have the expertise to know how to answer that question today. So I'm not a native Chinese speaker. Maybe somebody on the phone could address that or has better understanding of that.

(Steve): Hi this is (Steve).

Robert Hutchinson: Yes.

(Steve): I am a native Chinese speaker. And so I think Edmund and particularly (Dean Confrancinic) can provide us with more information on that.

In my personal opinion I think translating, so from native Chinese to English, particularly the address is not that difficult.

What you have to do is, you know you translate their corresponding like their street into Chinese, street into Chinese. And then the rest is very similar to like they call it (Pein).

So I don't think that translation process is that difficult. But I don't know what it, you know, when it goes to - when it comes to like Hong Kong, you know, specific road names have different English, you know, corresponding English. And that might be more difficult. So maybe, you know, (Eyo Jung Kong) can comment on that?

Edmund Chong: Sure this is Edmund. Definitely for Hong Kong that translation wouldn't work as well as the mainland China.

There are, well because of the history, there are many roads where, you know, like Waterloo Road or Nathan Road where it’s really the reverse, that the Chinese version of which is a somewhat of a transliteration of the English version. So...

Man: Oh interesting.

Edmund Chong: ...it’s probably more challenging.

Yao Jiankang This is Yao Jiankang Actually in China translator from English name to Chinese address or Chinese address for (user name) and sometimes he goes with (unintelligible), sometimes he goes with (English) and sometimes a little combination of English (unintelligible) so it’s a little difficult.

But for my opinion about the uniform address, I think maybe because some of the address are - there are two form of address. One is the ASCII address, the US ASCII address. Another kind of is the local language address. It’s just (a Chinese) address.

The English address maybe can be uniform (uniform). But a local language address is not a (user AP) uniform.

Man: So (Jinc) I’ll ask one quick question.

Yao Jiankang Okay.

Man: So for example like a registrant in China, you know, they go to a register in China and they register a domain name.

Yao Jiankang Yes.

Man: Do they put their Chinese contact address down or they put, you know, or they have to translate that, you know, like into English or does someone else translate for them?

Yao Jiankang (Unintelligible) I’ll try (translate) in both or you will provide both English and Chinese address.

Man: Okay thank you.

Julie Hedlund: Okay this is Julie. And I have noted that it’s about four minutes after the hour. I think this has been a very helpful discussion which I will summarize and send around to the list.

And we can decide then perhaps how to move forward perhaps as I said of requirements, a checklist. And perhaps something like that could even come out of the summary that Dave has done.

But I'll get these notes summarized and get them out. And we can also have this discussion on the list as well.

I do have a question as far as when our next meeting should be. I can do it another Doodle although ideally it would be best if we could come up with a regular meeting time and day of the week.

I was wondering if we wanted to meet in two weeks time for example, two weeks from now is the 21 December on that - and then if we chose this same time, those who are on the call, does that - would that work?

Edmund Chong: For me that that definitely works. This is Edmund. I'm just wondering if Jeremy, you know, is I forgot whether he said is this one time issue that he couldn't join or it would be...

Julie Hedlund: Yes it’s a onetime issue I believe. But what I'll do is let me follow-up with a call. And when I send the notes around too, I will ask people to respond as to the suitability of doing a call at this time in two weeks time on the 21st.

And depending on the response, if it looks like that’s not going to work we can do a Doodle. But ideally we should pick a regular time.

So and I'll check separately with Jeremy on that as well. Thank you Edmund. Do others have comments?

Edmund Chong: And I guess, you know, if it works with Jeremy at least it seems like most, you know, we did do a Doodle earlier on and it does seem like this particular time slot works with most people so...

Julie Hedlund: It does in a way. I mean...

((Crosstalk))

Julie Hedlund: ...some of the people who responded that they thought they would make it today couldn't make it. And of course that's, you know, that does happen.

But I had ten responses and ten people saying they could probably, you know, be on the call. So I think you’re right there.

Okay then I will tentatively set it for two weeks from today for the 21st. And I will check also with Jeremy on that as well.

Thank you everyone.

Anything else, any other questions people have? Like I said, I'll summarize what we've discussed here today and send it around. And I hope that we’ll - we can have some further discussion on the list prior to the next meeting.

Man: (Unintelligible).

Julie Hedlund: Great...

Man: Thank you.

Julie Hedlund: Thank you...

Man: Thank you.

Julie Hedlund: ...everyone for joining us today. And have a good evening or good morning depending on your time. And we'll look forward to speaking to you in two weeks.

Man: Thanks.

Man: Thank you.

Man: Thank you.

END