Auftrag Contact INFO

Funktion

Der Auftrag dient dazu, die Daten eines Contacts abzufragen.

Voraussetzungen

Der Contact muss existieren.

Besonderheiten

Sie können nur Daten von eigene Contacts abfragen.

Auftragsparameter

Ein Auftrag enthält die nachfolgend beschriebenen Parameter:

K/V-Schlüsselwort	XML-Namensraum und Element	Vorkommen min - max	Typ / Länge	Wertebereich	Beschreibung
Action	contact info	1	enumeration	Info-erule	Auftragstyp
Version	-	1	enumeration	version-erule	Version, nur für Aufträge im Key/Value-Format relevant.
Handle	contact:handle	1	token 9 - 32	contact-rule	Eindeutige ID des Contacts. Syntax: <RegAccId>-<ID vom Mitglied>

Häufige Fehler

Das im Auftrag angegebene Contact-Handle existiert nicht

Beispiele

Beispielaufträge PERSON oder ORG

Kopieren

Response K/V Contact INFO

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
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

Contact INFO XML

38
39
40
41
42
43
44
45
46
47

<?xml version="1.0" encoding="UTF-8"?>
<registry-response xmlns="http://registry.denic.de/global/5.0"xmlns:tr="http://registry.denic.de/transaction/5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tr:transaction>
  <tr:stid>2e6d8093-9f12-11df-996c-33039fab005f</tr:stid>
  <tr:result>success</tr:result>
  <tr:data>
    <contact:infoData xmlns:contact="http://registry.denic.de/contact/5.0">
      <contact:handle>DENIC-99995-JOHNDOE</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

Contact INFO XML

48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
      <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">
        <verification:verifiedClaims>
          <verification:claim>address</verification:claim>
          <verification:claim>name</verification:claim>
        </verification:verifiedClaims>
        <verification:verificationResult>success</verification:verificationResult>
        <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
        <verification:verificationTimestamp>2023-10-04T12:22:19+02:00</verification:verificationTimestamp>
        <verification:verificationEvidence>idcard</verification:verificationEvidence>
        <verification:verificationMethod>auth</verification:verificationMethod>
        <verification:trustFramework>de_denic</verification:trustFramework>
      </verification:verificationInformation>
      <verification:verificationInformation>
        <verification:verifiedClaims>
          <verification:claim>address</verification:claim>
          <verification:claim>name</verification:claim>
        </verification:verifiedClaims>
        <verification:verificationResult>success</verification:verificationResult>
        <verification:verificationReference>354546TZQ</verification:verificationReference>
        <verification:verificationTimestamp>2023-10-04T12:22:19+02:00</verification:verificationTimestamp>
        <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
        <verification:verificationMethod>auth</verification:verificationMethod>
        <verification:trustFramework>de_denic</verification:trustFramework>
      </verification:verificationInformation>

Die Struktur im XML-Dokument vor "contact:infoData" ist identisch zur Struktur eines Auftrags mit dem RRI-Protokoll 4.0 und kann von dort übernommen werden.

Kopieren

Contact INFO XML

72
73
74
75
    </contact:infoData>
  </tr:data>
</tr:transaction>
</registry-response>

Datenobjekte PERSON und 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.

Datenobjekt 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 INFO

Beispiele

Vielen Dank!

Danke für Ihre Rückmeldung.