# Datenobjekt Contact

Inhalt des Datenobjekts

Das Datenobjekt "Contact" enthält die relevanten Daten zu Kontakten des Typs

PERSON und ORG

mit den Kontaktdaten:

- eindeutiges Handle,

- Domaininhabern,

- Adresse,

- E-Mail,

- Telefonnummer,

- Verifikationsinformationen,

REQUEST

mit den Kontaktdaten (für General Request oder Abuse Contact):

- eindeutiges Handle,

- URI-Template.

Bearbeitungsmöglichkeiten

Mit Hilfe der Auftragsformen Contact CREATE und Contact UPDATE kannst du einen neuen Contact anlegen, oder einen bereits vorhandenen ändern.

Aufbau und Regeln für Contacts der Typen 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.

Aufbau und Regeln für den Verifikationsinformationsblock bei Contacts der Typen PERSON und ORG

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.

Aufbau und Regeln zur Bearbeitungin Aufträgen für den Contact des Typs 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.