Re: [EPP-discuss] contact-create issues

From: Morten Møller Riis <>
Date: Wed, 5 Jun 2013 14:42:16 +1000


I'm aware that my example phone number fails because of the whitespace. But it was just to illustrate the issue.

Even though the XML fails XSD validation it is still valid XML and as such I think the cltrid should be extracted. In worst case simply by regex.

Regarding specifying a manual id I guess I can see the reason for this. IMHO the auto keyword is a good idea, but isn't EPP standard and as such different registrars have different ways of solving this. I think the current solution is ok, but the documentation should be updated to reflect this. It also makes the check-contact action unnecessary.

Regarding the password. I guess it is send to the user on domain-create then. Some registrars, like nominet, don't use pw either. The documentation should be updated to reflect this.

Mvh / Best regards
Morten Møller Riis
Gigahost ApS

On Jun 4, 2013, at 10:03 PM, Erik Johansen <> wrote:

> Let me just comment a bit on this one:
> On 04-06-2013 03:47, Morten Møller Riis wrote:
>> Hi guys
>> A few issues with contact-create.
>> Specifying password for contact at contact-create doesn't seem to work, e.g.:
>> <contact:authInfo>
>> <contact:pw>m75zy_at_fI</contact:pw>
>> </contact:authInfo>
> Currently it does not appear to have any purpose to have a password, for accessing a customers details, since the customer will get a password sent to them on creation. The two passwords have different purposes anyway, but registrar access using this password is not planned.
>> Manually specifying an id doesn't seem to work:
>> The documentation suggests this should be possible as per RFC5733.
>> Request:
>> <contact:id>GH342342-DK</contact:id>
>> <result code="1000">
>> <msg>Contact created.</msg>
>> </result>
>> <resData>
>> <contact:creData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>> <contact:id>GH5590-DK</contact:id>
> This got changed just before putting out the last version of EPP.
> The possibility of having customers pick their own contact-ID conflicts with some internal allocation schemes.
> The number-part is assigned in serial order. The letter prefix is usually picked from the initials, although I think you are allowed to specify something else.
> Anyway, there is a strong urge to reuse contact handles, so if you pass in contact details matching an existing contact, you may have that contact-id returned instead.
>> clTRID is discarded if validation fails, even just for certain field
>> IMHO Especially problematic when we are working async.
>> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
>> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
>> <response>
>> <result code="2001">
>> <msg>XSD Validation failed Element &apos;{urn:ietf:params:xml:ns:contact-1.0}voice&apos;: &apos;+45 12345678&apos; is not a valid value of the atomic type &apos;{urn:ietf:params:xml:ns:contact-1.0}e164StringType&apos;.</msg>
>> </result>
>> <trID>
>> <clTRID>missing</clTRID>
>> <svTRID>6EBB7AB6-CCB7-11E2-ACC0-D1A1A4F3F658</svTRID>
>> </trID>
>> </response>
>> </epp>
> The more technical description, is that the XML is being parsed, and failing that leaves no trust in the XML structure itself. This is where the clTRID is extracted from. When parsing fails, we are currently falling back to a more limited attempt to extract the clTRID. This is something that we should improve.
> (Phone numbers needs a "." like in "+45.12345678")
>> Mvh / Best regards
>> Morten Møller Riis
>> Gigahost ApS
> --
> Med venlig hilsen/Best Regards
> Erik Johansen
> Titel: Udvikler/Developer
> DK Hostmaster A/S
> Kalvebod Brygge 45, 3. sal
> 1560 København V
> Tlf. 33 64 60 60
> Mobil: 40 13 60 57
> Fax.: 33 64 60 66
> Email:
> Homepage:
> .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 Wed Jun 05 2013 - 06:42:16 CEST

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