Draft on IDN Tables in XML

[Shawn Steele]

> I imagine if the table changed on which the registry based its policy, it would need its own procedures for dealing with that, but that would be outside the scope of the specification. Some may opt to only use the changed set on new registrations and grandfather in the old ones, depending on the reason why the maintain variants.

That's I guess what I was getting at.  Eventually someone's going to change their mind on what's appropriate. They can then grandfather in existing ones or figure out how to deprecate them, but, at that time, it seems the actual DNS entries won't match the file here.  Additionally there could be errors.  Presumably the DNS records are authoratative, however if they don't match it could confuse consumers.

So, as a 3rd party, I'm not sure how this information is very helpful to me?  I mean, it'd tell me what the registry hoped to do for it's zone, but that may or may not match the DNS entries.  I can discover valid domains by querying the DNS itself, I don't need to access the list.

I can see how this information might be helpful for tools that help people manage their zones, however any tools that talked to themselves wouldn't necessarily need this format (though it'd help to be able to import/export the data this way, and maybe interoperate better with other tools).

I guess what I'm getting at is:  What kinds of applications are expected to consume this data?  What's the target?

-Shawn