I would be broadly supportive of a cross-RIR database/registry
conversation. I think its long overdue.
It's not an easy conversation, but I think it's a necessary one.
it is also off-topic. So I won't say more, but having opened the door,
I strongly urge you to continue opening this door.
I beli
Hi,
On Mon, Jul 13, 2020 at 04:49:16PM +, ripedenis--- via db-wg wrote:
> This is why I believe we should go for a simple Punycode option now and then
> start to consider the bigger picture and finally address difficult questions
> that have been brushed under the carpet for many years.
I t
Hi Nick, George
"fundamentally yeah - it's a bit colonial to continue ignoring the reality that
us-ascii is inappropriate for large chunks of the world."
I totally agree with the drive to disengage with the colonial past and move on
in all areas of life. However, the RIR Databases reflect a publ
On Mon, 13 Jul 2020 at 14:12, ripedenis--- via db-wg wrote:
> Do we, therefore, have support to introduce Puny code now and then consider
> how to move forward with UTF-8?
+1 for a brief technical summarization (or impact analysis) of the
effort required to implement the technical change.
--
C
Hello Peter, WG,
> On 13 Jul 2020, at 15:03, Peter Koch via db-wg wrote:
>
> On Mon, Jul 13, 2020 at 12:12:42PM +, ripedenis--- via db-wg wrote:
>
>> Do we therefore have support to introduce Puny code now and then consider
>> how to move forward with UTF-8?
>
> I'm not sure I understand
Peter Koch via db-wg wrote:
>
> I'm not sure I understand the proposal.
Me too :-)
> "punycode" is primarily IDNA2003 speak
AFAIK IDNA2008 uses punycode in exactly the same way as IDNA2003.
One of the major changes was to get rid of stringprep.
> How would that system deal with conversion fail
George Michaelson via db-wg wrote on 10/07/2020 01:15:
Raw UTF-8 would work better here. It would permit the model to be
extended naturally into multiple script models. I understand its
inherently more complex than uplift to punycode of the domain elements
in things, but the underlying problem in
On Mon, Jul 13, 2020 at 12:12:42PM +, ripedenis--- via db-wg wrote:
> Do we therefore have support to introduce Puny code now and then consider how
> to move forward with UTF-8?
I'm not sure I understand the proposal. "punycode" is primarily IDNA2003
speak - and the initial suggestion by Ed
ripedenis--- via db-wg wrote on 13/07/2020 13:12:
There has been support shown to introduce Puny code as a first step
towards internationalisation of the data, which can be done quickly by
the RIPE NCC.
Do we therefore have support to introduce Puny code now and then
consider how to move forw
hi,
On Mon, Jul 13, 2020 at 12:12:42PM +, ripedenis--- via db-wg wrote:
> Do we therefore have support to introduce Puny code now and then consider how
> to move forward with UTF-8?
Works for me.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG
Hi Denis,
> Do we therefore have support to introduce Puny code now and then consider
how to move forward with UTF-8?
I think this is probably the best solution.
- Cynthia
On Mon, Jul 13, 2020 at 2:13 PM ripedenis--- via db-wg
wrote:
> Colleagues
>
> After the recent discussion it seems their
Colleagues
After the recent discussion it seems their is support for the idea of UTF-8,
whilst there is also support for Puny code as an interim step.
To implement UTF-8 in the RIPE Database requires much more detailed
discussions, including non technical aspects of the change. This is not likely
12 matches
Mail list logo
