Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response

From: Francisco Arias <[email-masked]>
Date: Mon, 5 Nov 2012 14:20:10 -0800

Hi Andy, and Scott,

I have the following comments/questions on the
draft-ietf-weirds-json-response draft.

- 3.  Common Data Types: shouldn't we have a standard format for phone
numbers as in EPP?

- 4.2.  The DNR Entity Object Class, 5.  The Nameserver Object Class, and
6.2.  The DNR Domain Object Class: why do we need the port43 element?

- 6.2.  The DNR Domain Object Class: the description for the element
'sponsoredBy' seems to imply that there are "IANA approved registrars"; it
should be changes to say that there is an IANA registry for
ICANN-accredited registrars for gTLDs or something like that.

- 6.2.  The DNR Domain Object Class: the variants also need an status. It
is quite common to have a "base" domain name that could active in the DNS
that has a number of variants that are blocked or whitheld (i.e., not
active in the DNS).

- 6.2. The DNR Domain Object Class: you may want to add the element(s)
'roles' to the entity example.

- 6.2. The DNR Domain Object Class: is missing the U-label element and
possibly IDNA version.

- Appendix A.  Suggested Values: why not to simply reference EPP and other
applicable standards?

- Appendix C.  IDN Query and Response Model: I think the portrait of IDN
variants is not correct, I'd suggest deleting this. There is an
interesting discussion of variants at
http://www.icann.org/en/topics/idn/idn-vip-integrated-issues-final-clean-20
feb12-en.pdf if you are interested, but I don't think this Appendix is
needed.

Regards,

__

Francisco.

---

From: Francisco Arias <[email-masked]>
Date: Mon, 5 Nov 2012 14:29:18 -0800

>that has a number of variants that are blocked or whitheld (i.e., not

Forgot to mention the need for an URI to the Label Generation Rules (aka
IDN tables) for the registry that resulted in the variants.

__

Francisco.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Nov 2012 22:53:21 +0000

> - 3.  Common Data Types: shouldn't we have a standard format for phone

The standard formats for phone numbers are in E.123

Good luck trying to get end users to supply them in that format, though...

Ray

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2012 01:56:44 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ray Bellis
> Sent: Monday, November 05, 2012 5:53 PM
> To: Francisco Arias
> Cc: [email-masked] Group
> Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response
> 
> 

EPP references E.164. ITU spec consistency aside, it's a good question. While this seems like a Good Thing, the practical issue is that doing so would require formatting that (as Ray noted) might require validation or translation on the back end. I'm inclined to allow a server operator to return this in the whatever format they have archived.

Scott

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 06 Nov 2012 08:42:16 +0100

E.123 defines "Notation for national and international telephone
numbers, e-mail addresses and Web addresses". It is really about
how one prints these things on paper. The forma is ill-suited for
anything else.

I'll dig up some old mail I wrote about this subject some time ago
later to day.

	jaap

---

From: Alex Sergeyev <[email-masked]>
Date: Wed, 14 Nov 2012 09:16:06 -0500

I'd like to add my opinion on the  draft-ietf-weirds-json-response-00

We plan to change our (Dyn Inc) implementation to follow this document
soon, it's a solid document. Few notes:

* I agree with previously stated point on telephone numbers, at least
better examples (not 999-999-999-99) and some recommendations could be made
in WEIRDS.

* "variants" element has no example and it might be something that needs an
URI sub-elements too (some variants could have information that is not
represented by another variant, some might be "reserved" vs "active" and so
on).

* I think it's confusing to have "status" property to be used as "array or
string", section 5 example has "string" and page before - "array". I would
suggest to make it consistent.

* I also would suggest some synonym for field "names" (in entity object).
Some long_key would also work better. Right now it is not really easy to
make mistake but replacing it could add some error-resiliency.

* My other personal wish as a consumer of that document is to have IPv6
examples whenever IP addresses are mentioned.

* I'm wondering why RIR class got DNSSEC elements and DNR did not.

* I wonder if postal address as a list of strings might have negative
consequences, some people who parse WEIRDS may want to find "cities where
administrators of these domains reside", this might be painful when some
foreign weirds server will mix stuff up and show city first, street address
last in that list.

Appreciate your work and hope my comments could be useful.

Alex Sergeyev
Sr. Engineer of Dyn Labs

---

From: Andy Newton <[email-masked]>
Date: Wed, 14 Nov 2012 14:32:27 +0000

>better examples (not 999-999-999-99) and some recommendations could be
>made in WEIRDS.

Sounds good. We could recommend servers use E.123 format if possible, but
that clients should accept any format.

>* "variants" element has no example and it might be something that needs
>an URI sub-elements too (some variants could have information that is not
>represented by another variant, some might be "reserved" vs "active" and
>so on).

I touched on this at the IETF, and basically pointed out the same issue.
There were no objections, so I'll be changing the format to accommodate
this information.

>* I think it's confusing to have "status" property to be used as "array
>or string", section 5 example has "string" and page before - "array". I
>would suggest to make it consistent.

Yup. The example is a mistake. Though the intent is to have status as an
array of strings. Objects can have multiple statuses.

>make mistake but replacing it could add some error-resiliency.

I don't think I understand. Can you provide an example?

>examples whenever IP addresses are mentioned.

Will do.

>* I'm wondering why RIR class got DNSSEC elements and DNR did not.

Both classes have it as the DNR class inherits everything from the RIR
class. If everybody finds this inheritance things confusing, we can
collapse all the classes into one. That was done to show how the RIR and
DNR models were being "unified".

>foreign weirds server will mix stuff up
> and show city first, street address last in that list.

Just like phone numbers, the data registries have is the data registries
have. If addresses are not in a structured format in the registry, it
would be difficult for them to use a format that does enforce structure.

-andy

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 14 Nov 2012 19:24:16 +0100

The E.123 format is really a presentation for mat and "apply
specifically to the printing of national and international telephone
numbers, electronic mail addresses and Web addresses on letterheads,
business cards, bills, etc." and is less suited for weird. It
actually has multiple formats.

It might be more prudent to stick with E.164, something that EPP
does as well.

	jaap

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Nov 2012 14:12:34 -0500

>would be difficult for them to use a format that does enforce structure.

For some reason I don't fully accept that reason.  The registries 
willing to expose that information will have that information and can 
write code to add some structure to the data.

Contact addresses are not free-form prose.  By their nature they have 
a pretty fixed grammar.  I'd recommend spec'ing out a more strict 
format until someone complains they can't support it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Arturo Servin <[email-masked]>
Date: Wed, 14 Nov 2012 19:37:03 -0200

On 14 Nov 2012, at 17:12, Edward Lewis wrote:

> For some reason I don't fully accept that reason.  The registries willing to expose that information will have that information and can write code to add some structure to the data.

	No, we cannot. At least not in 100% of cases.

	We can change our systems to try to enforce that new/updated data will comply with the format. However there would be some legacy data that will never comply.

> 
> Contact addresses are not free-form prose.  

> By their nature they have a pretty fixed grammar.  I'd recommend spec'ing out a more strict format until someone complains they can't support it.

But sometimes it is difficult to know what is a city, a street. etc. The current data in the whois have some structure, but you are asking too much.

	And probably, I would complain.

Regards.
as

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Alex Sergeyev <[email-masked]>
Date: Wed, 14 Nov 2012 17:04:08 -0500

Andy,

Thank you for answers,

> I don't think I understand. Can you provide an example?

it's truly just a gut feeling "something might be wrong there in future"
might be paranoia

Right now there is:
"name": "domain.com"
and
"names": ["John Doe"]

I think that even simple typos made by client developers could be annoying.
Also,
when someone would go and extend WEIRDS, say with the object "reseller",
that
might be identified by some abstract "name" and by company name.

It would be tempting for them to reuse "names" field and I think people
might be making wrong decisions here.

Sincerely,

Alex.

---

From: Byron Ellacott <[email-masked]>
Date: Thu, 15 Nov 2012 10:02:12 +1000

Hi Edward,

On 15/11/2012, at 5:12 AM, Edward Lewis <[email-masked]> wrote:

> Contact addresses are not free-form prose.  By their nature they have a pretty fixed grammar.  I'd recommend spec'ing out a more strict format until someone complains they can't support it.

Let me give you some real examples from actual data.

address:        Phnom Penh

address:        Level 25, 41 George Street

address:        Mostofa Center Road#27, Plot#59, Banani, Dhaka-1213

address:        PLDT Building , Pasig City

address:        Level 7 141 St Georges Terrace
address:        Perth
address:        WA 6000

address:        Jl. Jimerto 25-27 Gedung Pemkot Surabaya
address:        Surabaya

address:        Greater Noida, UP.

address:        Schwarzenbergstra<C3 83 C2 9F>eŸŸ 13/14a, Wien  1010

Addresses pretty much are free-form prose in the data I have in front of me.  I cannot support a more structured format.

  Byron

---

From: Kaveh Ranjbar <[email-masked]>
Date: Thu, 15 Nov 2012 10:25:35 +0100

Hi,

> Addresses pretty much are free-form prose in the data I have in front of me.  I cannot support a more structured format.

+1, I can not agree more with Byron.

Kaveh.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 15 Nov 2012 11:30:56 -0500

>address:        Schwarzenbergstra<C3 83 C2 9F>eŸŸ 13/14a, Wien  1010

First I'm shocked that registries would be so sloppy in collecting data.

Phnom Penh is obviously not enough detail to locate a registrant.

So I tried to pick apart the "Level 25, 41 George 
Street."  It's pretty straightforward to tie this 
to a (civilian) government agency probably in 
Brisbane Australia - only a few searches are 
needed.  But - "only a few searches" to find one 
full address does not scale.  (And I have to 
admit that I am not 100% certain the city 
involved is Brisbane.)  Neither the APNIC whois 
(which has the address above) nor the AU registry 
whois (looking up the mail domain listed at 
APNIC) had the city - in fact the latter didn't 
include any postal address information.

(I'm surprised that a public agency would be so 
well hidden - that's not in the protocol's scope.)

The Perth address is pretty complete to me...yes 
that "WA" is Western Australia and not (State of) 
Washington in the US.  I'll admit that I have 
travelled a lot and can fill in the fields not 
supplied in most cases even without resorting to 
a few web searches.

There are three perspectives here.  One is the 
registry operator, who isn't inclined to flesh 
out the addresses.  One is the registrant who 
also isn't inclined to supply more than is asked 
for and is more inclined to try to hide as much a 
possible.  The third perspective is the relying 
party who is inclined to want details - because 
they are probably looking up this address because 
they have a problem with the object on the 
network.

The specification should encourage the server to 
provide as much structured information as it can 
while also letting a server give back what it can.

PS - I hope no one wants to see the last address 
"translated (in English)" to Black Mountain 
Street in Vienna, Austria ... ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 16 Nov 2012 11:50:27 +1000

Hi Edward,

On 16/11/2012, at 2:30 AM, Edward Lewis <[email-masked]> wrote:

> [...]
> But - "only a few searches" to find one 
> involved is Brisbane.)
> [...]

Right, it doesn't scale.  A human can figure out most of these addresses.  This is probably good news for consumers of the data - there's enough information provided that they can still send snail-mail, though they might need to have some Google-fu to do so. It doesn't scale to overhaul the data, and it doesn't scale to do it as the data arrives - the cost of registration would increase to manage that workload.

> well hidden - that's not in the protocol's scope.)

I'm concerned you think the quality or right of access to data is within a protocol's scope at all.  It's policy, and the IETF is simply unable to make those decisions: choices made here won't be binding.  The IETF doesn't even trump ICANN policy, let alone the varying regional privacy laws.

Also, the address attribute quoted here is associated with a person, not an organisation - this data set does not expose organisations' addresses, and only so much of a person's (or role's) address as they're *willing* to provide for public consumption.  Other data sets will have other policy or legal constraints on them.  Other views of *this* data set will have different policy or legal constraints on it.

> while also letting a server give back what it can.

This notion I can get behind.  There's a happy ground between the perfect representation of ideal information and the unstructured glom of bytes that is port 43 output, and that's what weirds will give us.

I'd be very interested to see a proposal from you for an address data structure that can accommodate all the examples I gave you.  (So long as you also include pseudocode for how I might map from what I have to what I would need! :-)

> Street in Vienna, Austria ... ;)

I think the working group has reached an agreement that any translation or transliteration done will be done by the client, after the weirds protocol's part in the story is done and dusted, or it will be done because the registry in question has that as part of their own processes and policies, before the weirds protocol's part in the story even begins.  A process servicing a weirds request will do neither.

  Byron

---

From: "John Levine" <[email-masked]>
Date: 16 Nov 2012 04:20:11 -0000

>First I'm shocked that registries would be so sloppy in collecting data.

You shouldn't be.  There's some pretty funky registrations in .BIZ, too.

>while also letting a server give back what it can.

Sure, but this is an insoluble problem.  Some countries like the US
and UK have address standards and it's easy to check an address against
the post office's master list.   Some countries don't even have street
addresses.  In Costa Rica, for example, addresses are things like "
Calle Foo, 50 meters past the corner of Calle Bar."

Given that we're not doing a research project here, I'd say that
servers SHOULD use return standardized addresses when possible, but
clients have to be prepared for whatever crud the server has.

R's,
John

---

From: Don Blumenthal <[email-masked]>
Date: Fri, 16 Nov 2012 00:50:43 -0500

>Calle Foo, 50 meters past the corner of Calle Bar."

Accuracy isn't so easy to determine even in the US. Postal address
registries were based, at least in part and maybe entirely, on addresses
as laid out in initial maps. Structures don't necessarily go up according
to original plans, so the USPS system may show an address where none
exists. 

The situation has improved over the last five years. I just checked the
neighborhood where I grew up, which I used to demonstrate the problem when
I taught classes where the mismatch was relevant. A street number that I
know is bad used to show up as valid. It now carries the message "The
address you provided is not recognized by the US Postal Service as an
address we serve. Mail sent to this address may be returned." I still
wouldn't trust the system until I see assurances that all of it has been
cleaned up.

Don

---

From: Andy Newton <[email-masked]>
Date: Fri, 16 Nov 2012 12:33:32 +0000

>You shouldn't be.  There's some pretty funky registrations in .BIZ, too.

:)

>clients have to be prepared for whatever crud the server has.

I agree with this. And to summarize Byron's suggestion for those desiring
the structure, "send text."

-andy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 16 Nov 2012 08:54:10 -0500

>clients have to be prepared for whatever crud the server has.

In summary to what I wrote - that's exactly the point I was trying to make.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 16 Nov 2012 09:23:30 -0500

At 11:50 +1000 11/16/12, Byron Ellacott wrote:

>I'm concerned you think the quality or right of access to data is within a
>protocol's scope at all.  It's policy, and the IETF is simply unable to make
>those decisions: choices made here won't be binding.  The IETF doesn't even
>trump ICANN policy, let alone the varying regional privacy laws.

http://www.ietf.org/mail-archive/web/weirds/current/msg01802.html

It would be good to have a requirements document so we don't have to 
keep referring to the mail list archives and/or so we don't keep 
recycling threads.

>I'd be very interested to see a proposal from you for an address data
>structure that can accommodate all the examples I gave you.  (So long as you
>also include pseudocode for how I might map from what I have to what I would
>need! :-)

UPU.int is one source.  (Previously covered on this list.) 
Previously written, most of the examples have too little detail and 
missing elements to fill this out.  That shouldn't be an excuse for 
the protocol to be flat and weak, whether or not the protocol's 
existence influences policy.

I know that "the IETF does not trump ICANN."  But I also know that 
operators will tend to be guided by the standards under which they 
work.  E.g., there is a standard in DNS that says, for a certain 
field, 'pick a low number under 150' and there is an operator using 
150.  Why?  Guessing (as I haven't talked to that operator) that 150 
was the number 'in print.'  I've worked with places whose attitude is 
'we will work up to the requirements' meaning that if the requirement 
asked for one more thing, they'd do it, if the requirement doesn't 
ask for the thing, they don't.  And this leads up to - the protocol 
we are developing isn't just for the registries and registrants, its 
for the relying parties that want more than the current status quo of 
WhoIs.

>I think the working group has reached an agreement that any translation or
>transliteration done will be done by the client, after the weirds protocol's
>part in the story is done and dusted, or it will be done because the registry
>in question has that as part of their own processes and policies, before the
>weirds protocol's part in the story even begins.  A process servicing a
>weirds request will do neither.

Such an agreement ought to be in the requirements/goals document. ;) 
The reason I mentioned the example was to underscore that 
(undocumented?) agreement.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 16 Nov 2012 18:01:46 +0100

I got a similar experience while working for the .nl registry. We did a sanity
check against the official postal code database <http://http://www.postcode.nl>,
We ended up finding quite some inaccuracies in the database and therefore contemplated
that reason to stop that practice. (I Don't remember we actually did give up or what the
curret situation is).

	jaap

PS. The URL mentioned has pointers of similar sites in various countries:
    <http://www.postcode.nl/index/36/1/0/buitenlandse-postcodes.html>

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 19 Nov 2012 10:46:53 +1000

On 17/11/2012, at 12:23 AM, Edward Lewis <[email-masked]> wrote:

> It would be good to have a requirements document so we don't have to keep referring to the mail list archives and/or so we don't keep recycling threads.

I may be misunderstanding you, since what you linked to appears to have very little bearing to your expressed concern over the amount of information visible in a particular address field.  Are we in oblique agreement that the protocol covers representation of data, and policy covers contents of data?

> UPU.int is one source.  (Previously covered on this list.) Previously written, most of the examples have too little detail and missing elements to fill this out.  That shouldn't be an excuse for the protocol to be flat and weak, whether or not the protocol's existence influences policy.

UPU.int was passingly referred to, not covered; UPU.int do not seem to offer a single data structure to best represent a postal address, but if they do, feel free to link to it, or describe a JSON data structure that would best encapsulate it, and let's talk about whether it's possible to use that structure in the face of the several decades' worth of existing data many operators have.

I agree with you completely that having a structure would be preferable.  vCard has one [1], which is a specification I can point to, as opposed to what UPU.int offers publicly.  We could even adopt vCard's format, slightly changed to suit JSON, but given the existing data and the impracticality of converting free-form text into a structured address, all the data I have would wind up looking like this:

	"address": { "value": ";;;;;;", "label": "Level 25, 41 George Street" }

I don't believe it is practical or reasonable to mandate a structured format.  If a structured format is specified, an unstructured alternative must also be specified to allow existing data to be presented, or relying parties will see something more like this:

	"address": ";;;;;;"

So the question to me is whether address looks better as:

	"address": [
		"Jl. Jimerto 25-27 Gedung Pemkot Surabaya",
		"Surabaya",
	]

or:

	"address: { "value": ";;;;;;", "label": "Jl. Jimerto 25-27 Gedung Pemkot Surabaya\nSurabaya" }

Of those, I favour the former, which is what is in the existing draft.

  Byron

[1] http://tools.ietf.org/html/rfc6350#section-6.3.1