Auftrag: Contact CREATE

Funktion

Der Auftrag dient dazu, einen neuen Contact anzulegen.

Voraussetzungen

Der Contact darf noch nicht existieren.

Verifikation

Verifikationsinformationen werden für einen Kontakt vom Typ PERSON oder ORG erstellt.
Die Angabe von Verifikationsinformationen ist optional.
Die Angabe einer Telefonnummer ist verpflichtend.

Auftragsparameter

Ein Auftrag setzt sich zusammen aus den Feldern des Datenobjekts "Contact" und weiteren Parametern, die nachfolgend beschrieben werden:

K/V-Schlüsselwort	XML-Namensraum und Element	Vorkommen min - max	Typ / Länge	Wertebereich	Beschreibung
Action	contact:create	1	enumeration	create-erule	Auftragstyp
Version	-	1	enumeration	version-erule	Version, nur für Aufträge im Key/Value-Format relevant.
CtId	ctid	0 - 1	token 3 - 64	Jedes sichtbare Unicode-Zeichen (nach Unicode Version 3.1)	Eindeutige Transaktions-ID vom Client

Häufige Fehler

Das im Auftrag angegebene Contact-Handle existiert bereits, siehe Fehlermeldungen bei Contact-Aufträgen.

Beispiele

Beispielaufträge PERSON oder ORG

Kopieren

Response K/V Contact CREATE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Action: CREATE
Version: 5.0
Handle: DENIC-1000002-MAX
Type: Person
Name: Max Mustermann
Address: Business Services
Address: Theodor-Stern-Kai 1
Address: The maximum number of
Address: address lines is five and
Address: one line may be 255 characters long.
PostalCode: 60596
City: Frankfurt am Main
CountryCode: DE
eMail: email-1@denic.de
eMail: email-2@denic.de
eMail: email-3@denic.de
eMail: email-4@denic.de
eMail: email-5@denic.de
eMail: email-6@denic.de
Phone: +49.6927235x290

[VerificationInformation]
VerifiedClaim: name
VerifiedClaim: address
VerificationResult: success
VerificationReference: ABC123/45GHT
VerificationTimestamp: 2023-11-11T15:36:21+02:00
VerificationEvidence: idcard
VerificationMethod: auth
TrustFramework: de_denic

[VerificationInformation]
VerifiedClaim: email
VerificationResult: failed
VerificationReference: 354546TZQ
VerificationTimestamp: 2023-10-04T12:22:19+02:00
VerificationEvidence: transaction_log
VerificationMethod: auth
TrustFramework: de_denic

Kopieren

Response XML Contact CREATE

1
2
3
4
<registry-request xmlns="http://registry.denic.de/global/5.0" xmlns:contact="http://registry.denic.de/contact/5.0" xmlns:verification="http://registry.denic.de/verification/5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <contact:create>
    <contact:handle>DENIC-1000002-MAX</contact:handle>
    <contact:type>PERSON</contact:type>

Die Struktur im XML-Dokument nach PERSON ist identisch zur Struktur eines Auftrags mit dem RRI-Protokoll 4.0 und kann von dort übernommen werden.

Kopieren

Response XML Contact CREATE

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">
       <verification:verifiedClaims>
        <verification:claim>name</verification:claim>
        <verification:claim>address</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>success</verification:verificationResult>
      <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
      <verification:verificationTimestamp>2023-11-11T15:36:21+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>idcard</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_denic</verification:trustFramework>
    </verification:verificationInformation>
    <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">             
      <verification:verifiedClaims>
         <verification:claim>email</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>failed</verification:verificationResult>
      <verification:verificationReference>354546TZQ</verification:verificationReference>
      <verification:verificationTimestamp>2023-10-04T12:22:19+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_denic</verification:trustFramework>
    </verification:verificationInformation>
  </contact:create>
  <ctid>cba-987654321</ctid>
</registry-request>

Datenobjekte PERSON oder ORG

K/V-Schlüsselwort	XML-Namensraum und Element	Vorkommen min - max	Typ / Länge	Wertebereich	Beschreibung	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	Eindeutige ID des Contacts, Syntax: <RegAccId>-<ID vom Mitglied>	Das Handle eines Contacts muss immer mit der eigenen RegAccId des verwaltenden RegAccs beginnen.
Type	contact:type	1	enumeration	role-erule	Typ des Contacts: PERSON = natürliche Person, ORG = eine juristische Person (Firma, Verein, Inhabergemeinschaft, Organisation etc.	Der Typ des Contacts kann nachträglich geändert werden. Für Holder ist der Typ PERSON oder ORG.
Name	contact:name	1	normalizedString 1 - 255	name-rule	Name des Contacts	Der Name kann nach dem Anlegen nicht mehr geändert werden
Organisation	contact:organisation	0 - *	normalizedString 1 - 255	organisation-rule	Organisation, für die der Contact tätig ist	nur erlaubt bei Type PERSON nicht änderbar, sofern die Domain mit einem DISPUTE belegt ist. Der Domaininhaber muss immer im Feld „Name:“ angegeben werden. Der Wert von „Organisation“ hat keine Rechte an der Domain und kann zum Beispiel auch keine AuthInfo bzw. keinen Providerwechsel beantragen.
Address	contact:address	1 - *	normalizedString 1 - 255	address-rule	Straße und die Hausnummer des Contacts	Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
PostalCode	contact:postalCode	1	token 1 - 20	postalcode-rule	Postleitzahl der Anschrift des Contacts	Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
City	contact:city	1	normalizedString 1 - 80	city-rule	Wohnort des Contacts	Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
CountryCode	contact:countryCode	1	Enumeration 2	country-erule	Countrycode des Landes, in dem der Wohnort des Contacts liegt.	Erlaubt sind nur Countrycodes aus der ISO-3166-1 alpha-2 Liste Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
Email	contact:email	1 - *	normalizedString 3 - 255	email-rule (siehe RFC5322 - Internet Message Format)	E-Mail-Adresse des Contacts	„email“ ist ein Pflichtfeld und muss bei Contact CREATE- und Contact UPDATE-Aufträgen für die Typen PERSON und ORG mindestens einmal angegeben werden.

K/V-Schlüsselwort	XML-Namensraum und Elemente	1. Verschachtelung	2. Verschachtelung	Vorkommen min - max pro Verifizierungsinformations-Block	Typ / Länge	Wertebereich	Beschreibung
[VerificationInformation]	<verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType"> <verification:verifiedClaims> <verification:verificationResult> <verification:verificationReference> <verification:verificationTimestamp> <verification:verificationEvidence> <verification:verificationMethod> </verification:verificationInformation>	-	-	Einmal pro Verifikationsdatensatz	-	-	Bei K/V: Kopfzeile, die dem Verifikationsdatensatz voran steht
-	-	<verification:verifiedClaims> <verification:claim> </verification:verifiedClaims>	-	-	-	-	-
VerifiedClaim	-	-	<verification:claim> ... <verification:claim>	1 - 3	normalizedString / feste Länge durch vordefinierte Werte	claim-rule	"claims" sind Daten, die verifiziert wurden. Besonderheit bei E-Mail Der komplette Verifizierungsinformations-Block mit allen Schlüsselwörten bzw. XML-Elementen und Werten muss bei einer E-Mail-Prüfung angegeben werden, wenn das Ergebnis der Prüfung negativ war, also den Wert "failed" hat. Eine nachfolgendes Update mit dem positiven Wert "success" muss ebenfalls mitgeteilt werden. War bei der Prüfung von Anfang der Wert "success" vorhanden kann der Verifizierungsinformations-Block mitgeteilt werden.
VerificationResult	-	<verification:verificationResult> ... </verification:verificationResult>	-	1	normalizedString / feste Länge durch vordefinierte Werte	result-rule	Mitteilung über das Ergebnis der Verifikation
VerificationReference	-	<verification:verificationReference> ... /verification:verificationReference>	-	1	normalizedString / Länge wird vom Mitglied festgelegt	reference-rule	Der Inhalt ist ein Freitext für eine Referenz auf eine Auftragsnummer, Bestellnummer, Kundennummer etc.
VerificationTimestamp	-	<verification:verificationTimestamp> ... </verification:verificationTimestamp>	-	1	date-time	timestamp-rule	Zeitpunkt, zu dem die Verifikation durchgeführt wurde.
VerificationEvidence	-	<verification:verificationEvidence> ... </verification:verificationEvidence>	-	1	normalizedString / feste Länge durch vordefinierte Werte	evidence-rule	Nachweis, der bei der Verifikation geprüft wurde (z.B. für den Wert "idcard", was dem Personalausweis entspricht)
VerificationMethod	-	<verification:verificationMethod> ... </verification:verificationMethod>	-	1	normalizedString / feste Länge durch vordefinierte Werte	method-rule	Methode, mit der die Verifikation durchgeführt wurde (z.B. für den Wert "pvr", was der Nachweis über die Methode "Video-Identifikation" wäre
TrustFramework	-	<verification:trustFramework> ... </verification:trustFramework>	-	1	normalizedString / feste Länge durch vordefinierte Werte	framework-rule	Framework, das zu Verifikation herangezogen wurde. Bisher gibt es nur den Wert "de_denic", ggfs. folgen später weitere.

Datenobjekte REQUEST

K/V-Schlüsselwort	XML-Namensraum und Element	Vorkommen min - max	Typ / Länge	Wertebereich	Beschreibung	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	Eindeutige ID des Contacts. Syntax: <RegAccId>-<ID vom Mitglied>	Das Handle eines Contacts muss immer mit der eigenen RegAccId des verwaltenden RegAccs beginnen.
Type	contact:type	1	enumeration	role-erule	REQUEST = eine E-Mail oder eine URL im URI-Template-Format.	Für General Request und Abuse Contact darf Type nur REQUEST sein.
URI-Template	contact:uri-template	1	normalizedString 8 - 1024	Aufbau siehe gemäß RFC 6570 - URI Template	Die Variablen "Ulabel" und "Alabel" im URI-Template werden bei Domainabfrage (Web-whois) mit der Domain ersetzt.	Der Inhalt des URI-Templates wird bei einem CREATE-Auftrag als Test in eine URL oder E-Mail umgewandelt (Für "Alabel" und "Ulabel" wird eine Beispieldomain verwendet.) um die syntaktische Korrektheit zu überprüfen.

Auftrag: Contact CREATE

Beispiele

Vielen Dank!

Danke für Ihre Rückmeldung.