I would like us to alter the file and move IDN ccTLDs to their respective ccTLDs

[Jothan Frakes]

Hi-

I want to gauge if this is a good or bad idea to the group...

As I review the changes and edits that are coming in for ccTLDs, these often include IDN (or overlook them) when submitted by the authoritative administrator(s).

Back about a dozen years ago when we were initially adding these for the ccTLD testbed process, it was new, and we opted to add them all in one location alphabetically in one section, along with some testbed IDN (since removed).  We put them all in one place as we were adding and editing them and wanted to ensure that there was consistency with the additional elements of information that we were including in the comment line(s), as well as identification of where it was a variant as opposed to a delegated and root listed string.

It seems that the process of delegation for ccTLDs has expanded and has become more stable and predictable in the time since then.  It also appears that the majority of the country code IDN TLDs are administered by the same entities that operate the ISO3166 two letter ccTLD.

We would use the same existing format for IDN ccTLDs - where we include the additional associated details and comment structure that we have been using the IDNs ccTLDs.  This is just literally a move.

I would like to propose the following:

1] We relocate the IDN(s) for a given ccTLD into the same section as the non-IDN ccTLD for the country code, just below the two character and any sub-space defined within it, but just above the next country's entry.

2] We modify any documentation related to IDN ccTLDs that might list the former process or structure/location to reflect this change.

The benefit for this would be a better visual connection between the respective ccTLD and the associated ccTLD IDNs so that it is better recognized be the ccTLD administrator's edits when they occur, it will simplify the patch process for ccTLD administrators where the strings are maintained by the same entity/administrator.  It also demonstrates a nexus between the IDN/Non-IDN namespaces and the relationships between them.

I am willing to invest the time to make these edits, assuming there is not any dissent on it being a good idea.   It is not broken now, this is just an organizational move.  Before I would do this, I want to make sure that there are not use cases out in the wild that would be adversely impacted by the move, and there is some agreement that the effort would be worthwhile.

-Jothan

[Ryan Sleevi]

Sounds good to me.

Is the idea that ccTLD operators are reserving [example].ccTLD and [example].[idn-ccTLD] together at the same time, and should be adding both?

You mentioned "these often include IDN (or overlook them) when submitted by the authoritative administrator(s)." - I've got monitors set up on the changes, and I haven't seen such changes. Perhaps I've got my monitors setup wrong. Do you have some examples that might help provide context?

--
You received this message because you are subscribed to the Google Groups "psl-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publicsuffix-dis...@googlegroups.com.
To post to this group, send email to publicsuff...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/CAGrS0FJ%3Dw%2BcpR4VRtJfyUus05KnDZEhQrjWeB2epFMV226aMBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jothan Frakes]

Thread response below, but Universal Acceptance is among the key drivers.

Ona Sun, Jul 14, 2019, 14:32 'Ryan Sleevi' via psl-discuss <publicsuff...@googlegroups.com> wrote:

Sounds good to me.

Is the idea that ccTLD operators are reserving [example].ccTLD and [example].[idn-ccTLD] together at the same time, and should be adding both?

The idea is to place these near to each other to ensure that everything gets more opportunity to be considered when reviewing or providing edits.

Each are often distinct in their configuration, some have different languages and there may be other factors that cause these to be managed or configured differently than their two character ISO namespace.

I think having these together vs in separate sections will also simplify instructions for ccTLD operators on their self-maintenence efforts.

For all the different times that I have had an opportunity to explain PSL to admins at ICANN tech days, the room is filled with many of the people we hope to have updating their section(s), but they are also attending dozens of other sessions that day and mine is often 1 of dozens of presentations - so I want to keep it simple for instructions.

You mentioned "these often include IDN (or overlook them) when submitted by the authoritative administrator(s)." - I've got monitors set up on the changes, and I haven't seen such changes. Perhaps I've got my monitors setup wrong. Do yo5u have some examples that might help provide context?

This is not to correct any shortcoming on our part as maintainers.  Having to look in different places is a step we can reduce, and they may not know to also review their IDN.

The objective is to simplify things for TLDs to maintain their entries, and this change helps that.

I want to ensure that this does not break any automation, monitoring, publishing or any other processes that we are using as maintainers.

I circulated my initial message because I also want to have more of the larger public of users or maintainers of downstream libraries or processes that incorporate PSL to weigh in and identify if they perceive any adverse impact from this change.

[Ryan Sleevi]

On Mon, Jul 15, 2019 at 12:40 PM Jothan Frakes <jot...@jothan.com> wrote:

Thread response below, but Universal Acceptance is among the key drivers.

Ona Sun, Jul 14, 2019, 14:32 'Ryan Sleevi' via psl-discuss <publicsuff...@googlegroups.com> wrote:

Sounds good to me.

Is the idea that ccTLD operators are reserving [example].ccTLD and [example].[idn-ccTLD] together at the same time, and should be adding both?

The idea is to place these near to each other to ensure that everything gets more opportunity to be considered when reviewing or providing edits.

Each are often distinct in their configuration, some have different languages and there may be other factors that cause these to be managed or configured differently than their two character ISO namespace.

I think having these together vs in separate sections will also simplify instructions for ccTLD operators on their self-maintenence efforts.

For all the different times that I have had an opportunity to explain PSL to admins at ICANN tech days, the room is filled with many of the people we hope to have updating their section(s), but they are also attending dozens of other sessions that day and mine is often 1 of dozens of presentations - so I want to keep it simple for instructions.

You mentioned "these often include IDN (or overlook them) when submitted by the authoritative administrator(s)." - I've got monitors set up on the changes, and I haven't seen such changes. Perhaps I've got my monitors setup wrong. Do yo5u have some examples that might help provide context?

This is not to correct any shortcoming on our part as maintainers.  Having to look in different places is a step we can reduce, and they may not know to also review their IDN.

The objective is to simplify things for TLDs to maintain their entries, and this change helps that.

I want to ensure that this does not break any automation, monitoring, publishing or any other processes that we are using as maintainers.

I circulated my initial message because I also want to have more of the larger public of users or maintainers of downstream libraries or processes that incorporate PSL to weigh in and identify if they perceive any adverse impact from this change.

I guess I was trying to find examples of changes that you think demonstrate the problem, so that I could examine and make sure my tooling is functioning correctly. I'm not aware of any instances of the problem, which suggests my tooling may be broken. I'm not disagreeing with the change, but I'm surprised at some of the motivation, so wanting to understand more.

Right now, we don't have automation to manage the delegation (or un-delegation) of ccTLDs, only gTLDs. In the past, we'd previously sync'd by hand the root zone database (unioning both gTLDs and ccTLDs), and then looking for single-label omissions in either set. Such workflows would not break.

 

On Fri, Jul 12, 2019, 00:22 Jothan Frakes <jot...@jothan.com> wrote:

Hi-

I want to gauge if this is a good or bad idea to the group...

As I review the changes and edits that are coming in for ccTLDs, these often include IDN (or overlook them) when submitted by the authoritative administrator(s).

Back about a dozen years ago when we were initially adding these for the ccTLD testbed process, it was new, and we opted to add them all in one location alphabetically in one section, along with some testbed IDN (since removed).  We put them all in one place as we were adding and editing them and wanted to ensure that there was consistency with the additional elements of information that we were including in the comment line(s), as well as identification of where it was a variant as opposed to a delegated and root listed string.

It seems that the process of delegation for ccTLDs has expanded and has become more stable and predictable in the time since then.  It also appears that the majority of the country code IDN TLDs are administered by the same entities that operate the ISO3166 two letter ccTLD.

We would use the same existing format for IDN ccTLDs - where we include the additional associated details and comment structure that we have been using the IDNs ccTLDs.  This is just literally a move.

I would like to propose the following:

1] We relocate the IDN(s) for a given ccTLD into the same section as the non-IDN ccTLD for the country code, just below the two character and any sub-space defined within it, but just above the next country's entry.

2] We modify any documentation related to IDN ccTLDs that might list the former process or structure/location to reflect this change.

The benefit for this would be a better visual connection between the respective ccTLD and the associated ccTLD IDNs so that it is better recognized be the ccTLD administrator's edits when they occur, it will simplify the patch process for ccTLD administrators where the strings are maintained by the same entity/administrator.  It also demonstrates a nexus between the IDN/Non-IDN namespaces and the relationships between them.

I am willing to invest the time to make these edits, assuming there is not any dissent on it being a good idea.   It is not broken now, this is just an organizational move.  Before I would do this, I want to make sure that there are not use cases out in the wild that would be adversely impacted by the move, and there is some agreement that the effort would be worthwhile.

-Jothan

--
You received this message because you are subscribed to the Google Groups "psl-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publicsuffix-dis...@googlegroups.com.
To post to this group, send email to publicsuff...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/CAGrS0FJ8q6DHF%2B21nzW%2BGHwfhu2T9SNrNhs%3DAJzGFhd-B4wd5A%40mail.gmail.com.