Re: [EPP-discuss] IDN domains registration?

From: Jonas B. Nielsen <jonasbn_at_dk-hostmaster.dk>
Date: Thu, 7 Nov 2013 13:39:15 +0100

Hi Peter,

Please see below:

On 07/11/2013, at 10.17, Peter Larsen <peter.larsen_at_larsendata.dk> wrote:

>
> On 07 Nov 2013, at 09:42, Jonas B. Nielsen <jonasbn_at_dk-hostmaster.dk> wrote:
>
>> Hi Peter,
>>
>> The issue is that you reusing your clTRID (client transaction identifier). This has to be unique if your want a response from us. We are aware that the EPP specification is a bit unclear on this topic, but we regard transactional integrity as important in this particular case.
>
>
> unique for me or unique for all?
>

Unique for your client id (clID).

>
> howcome it be an issue after doing
>
> login
> create contact
> host info (5 times)
> create domain (here it fails)
>
>
> if you want it unique for every "session", why am i able to login (but then restricted in commands) ?

Please note that this is not a session id, it is a transaction id.

>
> if you want it unique for every command, why can i do 7 commands with the same clTRID ?
>

We only serialize it for create domain.

clTRID is the client tool and we do not want to dictate how you go about your transactional architecture, but in order to keep proper transaction integrity we serialize clID and clTRID so we can identify these more easily later.

Whether this should have more fine grained control in order to accomodate different transactional models on the client side, could be argued, but we did not anticipate this and the examples in the RFCs for EPP seem to demonstrate a use of clTRID to be unique per command, in order to match commands and responses accordingly. We do not police this aspect at this time, since the emphasis on the clTRID in the EPP specification is somewhat underplayed IMHO.

There are a lot of grey areas in the EPP specifications and we hade to make some assumptions and interpretations on the parts that are not explicitly defined or seem to be written between the lines.

We could police the clTRIDs dictating transactional models, but I am not sure that is what clients want?

I will clarify our use and interpretation of clTRID in the specification and await more feedback.

> Or is it just the domain create that fails due to it making an order and that haves to be unique (i can see my clTRID was not working properly, but i don't like the idea that an order can fail if i reuse an id by accident)
>
>>
>> As for punycode notation for domain names, this should not be necessary since we support UTF-8, I am reluctant to implementing this, but if there are a overweight of EPP users requesting this, I will look into supporting this.
>
> i'm just adding an ascii2idn($domain) so i really don't care, but for sake of being sane, i only do ascii locally, so +1 for allowing it
>
>
>
> regards, Peter Larsen - ICANN Accredited registrar
>
> My info: http://larsen.tel
> Company info: http://larsendata.tel
>

--
Med venlig hilsen/Best Regards
Jonas B. Nielsen	
Software udvikler/Softwaredeveloper
DK Hostmaster A/S
Kalvebod Brygge 45, 3. sal
1560 København V
Tlf.      +45 33 64 60 60
Mobil:   +45 31 54 60 56
Fax.:     +45 33 64 60 66
Email:    jonasbn_at_dk-hostmaster.dk
Homepage: https://www.dk-hostmaster.dk
.dk Danmarks plads på Internettet
-------------------------------------------------------------------------
Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan indeholde
fortrolig information, som kun er til brug for den tiltænkte modtager.
Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst straks
give afsenderen besked om dette og slette e-mailen fra dit system uden
at offentliggøre, videresende eller tage kopi af meddelelsen.
This is an email from DK Hostmaster A/S. This message may contain
confidential information and is intended solely for the use of the
intended addressee. If you are not the intended addressee please notify
the sender immediately and delete this e-mail from your system. You are
not permitted to disclose, distribute or copy the information in this
e-mail.
--------------------------------------------------------------------------
Received on Thu Nov 07 2013 - 13:39:15 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 06 2015 - 11:39:18 CET