idnits 2.17.1 draft-gould-regext-dataset-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document defines a Data Set File (DSF) format that can be used to define and pass bulk data between a client and a server. The client and server MAY leverage a provisioning protocol like EPP, as defined in [RFC5730], to provision individual objects, but the provisioning protocol MAY NOT handle all provisioning use cases. This document defines a format for bulk provisioning requests that can be generated by authorized third parties, can be generated by clients that choose not to leverage the provisioning protocol, and can be supported by servers to process bulk requests in a controlled manner that throttles the processing against the provisioning database. Bulk requests can include court orders, out-of-band client requests to fix data, the backfill of data like contact or verification code data, and a large set of ad-hoc needs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Routing is most applicable to objects like a Contact Object (Section 4.3) and a Host Object (Section 4.2), where the keys ( for the Contact Object and for the Host Object) MAY NOT be enough to uniqually identify a target domain registry service. An example of using the field for routing is provided with the "contact.create.routing" DSF in Section 4.3. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 1yzz: Positive result. The file or record was processed by the system successfully. Partial successful results MAY be included. 2yzz: Negative result. The file or record was not processed successfully. Partial successful results MAY NOT be included. -- The document date (September 5, 2018) is 2057 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5910' is defined on line 3195, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track September 5, 2018 5 Expires: March 9, 2019 7 Data Set File Format 8 draft-gould-regext-dataset-02 10 Abstract 12 This document defines a Data Set File (DSF) format that can be used 13 to define and pass bulk data between a client and a server. This 14 format is extensible to pass any set of simple data types in a set of 15 records contained in the body of the file. The file format also 16 supports storing the result of processing the data set that MAY be 17 generated by the server and returned to the client. The file format 18 consists of an XML definition header and a Comma-Separated Values 19 (CSV) data section delimited by "-----BEGIN DATA SET-----" and "----- 20 END DATA SET-----" lines. The XML definition header defines the 21 format of the CSV data section, contains additional meta-data, and 22 optionally includes a digital signature to identify the source and 23 ensure that the data has not been tampered with between the parties 24 (source, client, and server). The interface (manual or automated) 25 that is used to submit the file and receive the result file is not 26 defined within this document. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 9, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 64 2. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Type and Subtype . . . . . . . . . . . . . . . . . . . . 5 68 2.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4.1. Base Field Types . . . . . . . . . . . . . . . . . . 6 70 2.4.2. Data Set Field Elements . . . . . . . . . . . . . . . 8 71 2.4.2.1. Field Element Extensibility . . . . . . . . . . . 8 72 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3. Data Set File (DSF) Format . . . . . . . . . . . . . . . . . 11 74 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 12 75 3.1.1. element . . . . . . . . . . . . . . 12 76 3.1.2. element . . . . . . . 13 77 3.1.2.1. Signed Definition Data . . . . . . . . . . . . . 13 78 3.1.3. element . . . . . . . . . . . . 15 79 3.2. Body Format . . . . . . . . . . . . . . . . . . . . . . . 18 80 4. Object Description . . . . . . . . . . . . . . . . . . . . . 18 81 4.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 18 82 4.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 25 83 4.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 31 84 4.4. Verification Code Object . . . . . . . . . . . . . . . . 39 85 5. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . 41 86 6. Example Data Set File (DSF) Result Files . . . . . . . . . . 44 87 6.1. Example Data Set File (DSF) with Result Data . . . . . . 44 88 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 47 89 7.1. Data Set Schema . . . . . . . . . . . . . . . . . . . . . 47 90 7.2. Domain Name Schema . . . . . . . . . . . . . . . . . . . 56 91 7.3. Host Schema . . . . . . . . . . . . . . . . . . . . . . . 60 92 7.4. Contact Schema . . . . . . . . . . . . . . . . . . . . . 62 93 7.5. Verification Code Schema . . . . . . . . . . . . . . . . 67 94 7.6. Routing Schema . . . . . . . . . . . . . . . . . . . . . 69 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 96 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 69 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 71 98 10. Normative References . . . . . . . . . . . . . . . . . . . . 72 99 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 73 100 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 74 101 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 74 102 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 74 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 74 105 1. Introduction 107 This document defines a Data Set File (DSF) format that can be used 108 to define and pass bulk data between a client and a server. The 109 client and server MAY leverage a provisioning protocol like EPP, as 110 defined in [RFC5730], to provision individual objects, but the 111 provisioning protocol MAY NOT handle all provisioning use cases. 112 This document defines a format for bulk provisioning requests that 113 can be generated by authorized third parties, can be generated by 114 clients that choose not to leverage the provisioning protocol, and 115 can be supported by servers to process bulk requests in a controlled 116 manner that throttles the processing against the provisioning 117 database. Bulk requests can include court orders, out-of-band client 118 requests to fix data, the backfill of data like contact or 119 verification code data, and a large set of ad-hoc needs. 121 This format is extensible to pass any set of simple data types in a 122 set of records contained in the body of the file. The file format 123 also supports storing the result of processing the data set that MAY 124 be generated by the server and returned to the client. The file 125 format consists of an XML definition header and a Comma-Separated 126 Values (CSV) data section delimited by "-----BEGIN DATA SET-----" and 127 "-----END DATA SET-----" lines. The XML definition header defines 128 the format of the CSV data section, contains additional meta-data, 129 and optionally includes a digital signature to identify the source 130 and ensure that the data has not been tampered with between the 131 parties (source, client, and server) using XML Signature 132 [W3C.CR-xmldsig-core2-20120124]. All XML Signature 133 [W3C.CR-xmldsig-core2-20120124] data is "base64" encoded, in 134 conformance with [RFC2045], by default to mitigate any validation 135 errors due to whitespace formatting. The interface (manual or 136 automated) that is used to submit the file and receive the result 137 file is not defined within this document and must be documented 138 independently. Please see Section 9 for a description of the issues 139 associated with transport security. 141 1.1. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 XML is case sensitive. Unless stated otherwise, XML specifications 148 and examples provided in this document MUST be interpreted in the 149 character case presented in order to develop a conforming 150 implementation. 152 The following XML abbreviations are used: 154 "eppcom" XML namespace prefix refers to 155 "urn:ietf:params:xml:ns:eppcom-1.0" XML namespace in [RFC5730]. 156 "domain" XML namespace prefix refers to 157 "urn:ietf:params:xml:ns:domain-1.0" XML namespace in [RFC5731]. 158 "host" XML namespace prefix refers to 159 "urn:ietf:params:xml:ns:host-1.0" XML namespace in [RFC5732]. 160 "contact" XML namespace prefix refers to 161 "urn:ietf:params:xml:ns:contact-1.0" XML namespace in [RFC5733]. 162 "dataSet-1.0" is used as an abbreviation for 163 "urn:ietf:params:xml:ns:dataSet-1.0". 164 "dataSet" XML namespace prefix refers to 165 "urn:ietf:params:xml:ns:dataSet-1.0" XML namespace. 166 "dsfDomain-1.0" is used as an abbreviation for 167 "urn:ietf:params:xml:ns:dsfDomain-1.0". 168 "dsfDomain" XML namespace prefix refers to 169 "urn:ietf:params:xml:ns:dsfDomain-1.0" XML namespace. 170 "dsfHost-1.0" is used as an abbreviation for 171 "urn:ietf:params:xml:ns:dsfHost-1.0". 172 "dsfHost" XML namespace prefix refers to 173 "urn:ietf:params:xml:ns:dsfHost-1.0" XML namespace. 174 "dsfContact-1.0" is used as an abbreviation for 175 "urn:ietf:params:xml:ns:dsfContact-1.0". 176 "dsfContact" XML namespace prefix refers to 177 "urn:ietf:params:xml:ns:dsfContact-1.0" XML namespace. 178 "dsfVerificationCode-1.0" is used as an abbreviation for 179 "urn:ietf:params:xml:ns:dsfVerificationCode-1.0". 180 "dsfVerificationCode" XML namespace prefix refers to 181 "urn:ietf:params:xml:ns:dsfVerificationCode-1.0" XML namespace. 182 "dsfRouting-1.0" is used as an abbreviation for 183 "urn:ietf:params:xml:ns:dsfRouting-1.0". 185 Implementations MUST NOT depend on the XML namespace prefix used in 186 this document and instead MUST employ a proper namespace-aware XML 187 parser and serializer to interpret and output the XML. 189 2. General Conventions 191 This document includes a general set of attributes and terms that are 192 described here. 194 2.1. Date and Time 196 Numerous fields indicate "dates", such as the creation date of the 197 DSF. These fields SHALL contain timestamps indicating the date and 198 time in UTC as specified in [RFC3339], with no offset from the zero 199 meridian. 201 2.2. Checksum 203 The checksum of the body of the file, as defined by the body rule of 204 the Data Set File (DSF) ABNF (Section 3), MUST use CRC32, that is the 205 algorithm used in the ISO 13239 standard [iso13239] and in section 206 8.1.1.6.2 of ITU-T recommendation V.42 [itu-t-V.42]. 208 2.3. Type and Subtype 210 There can be many different Data Set File (DSF) types supported based 211 on the objects, operations, and the specific scenarios. To make it 212 easier to negotiate the client's intent of the DSF with the server's 213 set of supported DSF files, the DSF supports the definition of a type 214 and an optional sub-type. The supported list of types and sub-types 215 is up to server policy. The server SHOULD provide the possible set 216 of supported DSF type and sub-type values to the parties generating 217 the DSF. The mechanism for providing the supported DSF type and sub- 218 type values is not defined in this document but MAY require 219 registration within an IANA registry. 221 The element formally defines the DSF type, which 222 indicates the expected set of fields defined under the 223 element and the expected operation to be taken. An 224 OPTIONAL "subType" attribute defines the sub-type that is used to 225 further refine the purpose of the DSF. 227 It is recommended that the server follows a consistent naming scheme 228 for the values. One option is to delimit the value 229 with a '.' and to include the object ("domain", "host", "contact, 230 "verificationCode", etc.), the operation ("create", "renew, 231 "transfer", "delete", "update", etc.), and the scoped name of the 232 DSF. For example, to support the bulk update of encoded signed 233 verification codes, the value can be set to 234 "verificationCode.update.encodedSignedCode". To further sub-divide 235 the "verificationCode.update.encodedSignedCode" type by locality, the 236 "subType" attribute can be set to the locality name. For example, 237 the "china" verification profile supports two verification codes of 238 type "domain" and "real-name", so the 239 "verificationCode.update.encodedSignedCode" DSF type can include 240 "china" for the "subType" attribute, as in verificationCode.update.encodedSignedCode. 243 2.4. Fields 245 The element, an element in the header (Section 3.1), 246 contains an ordered list of CSV fields used in the body of the file 247 delimited by the character defined by the OPTIONAL "sep" attribute, 248 with a default value of ",". A field child element substitutes for 249 the abstract element. Each element defines the 250 format of the CSV field contained in the body. The 251 elements support the "type" attribute that defines the XML schema 252 simple type of the field element. 254 The abstract element does not directly define any 255 attributes, but there are a couple attributes that a data set 256 processor SHOULD support including: 258 "isRequired": When the "isRequired" attribute is "true", it 259 indicates that the field MUST be non-empty in the body and when 260 set to "false", it indicates that the field MAY be empty in the 261 body. The "isRequired" attribute MAY be specifically set for the 262 field elements in the XML schema and MAY be overriden by 263 specifying the attribute in the fields under the 264 element. If no "isRequired" attribute is defined, the default 265 value is "false". 266 "isPrimaryKey": When the "isPrimaryKey" attribute is "true", it 267 indicates that the field is part of the primary key of the 268 records. The combination of the primary key fields MUST be 269 unique across the set of records in the file. The "isPrimaryKey" 270 attribute MAY be specifically set for the field elements in the 271 XML schema and MAY be overridden by specifying the attribute in 272 the fields under the element. If no 273 "isPrimaryKey" attribute is defined, the default value is 274 "false". 276 2.4.1. Base Field Types 278 New field types can be defined that reside in the CSV records. To 279 make the definition of new field types easier, a set of base field 280 types are defined in the dataSet-1.0 XML schema that include: 282 "dataSet:fieldOptionalType": The "dataSet:fieldOptionalType" type 283 can be extended by a field that can be empty ("isRequired" = 284 "false") and is not a member of the primary key ("isPrimaryKey" = 285 "false"). 286 "dataSet:fieldRequiredType": The "dataSet:fieldRequiredType" type 287 can be extended by a field that cannot be empty ("isRequired" = 288 "true") and is not a member of the primary key ("isPrimaryKey" = 289 "false"). 290 "dataSet:fieldPrimaryKeyType": The "dataSet:fieldPrimaryKeyType" 291 type can be extended by a field that cannot be empty 292 ("isRequired" = "true") and is a member of the primary key 293 ("isPrimaryKey" = "true"). 294 "dataSet:fListItemType": The "dataSet:fListItemType" type is an 295 extension of the "dataSet:fieldOptionalType" type that adds an 296 OPTIONAL "op" attribute that reflects the operation to apply for 297 the list item. The default "op" value is "replace". The list of 298 possible "op" values is include below. A "dataSet:fListItemType" 299 field with "op" set to "replace" MUST NOT be mixed with a 300 matching "dataSet:fListItemType" field with "op" set to either 301 "add" or "remove". 303 "replace": Specifies that the list item will replace what is 304 currently set for the object. The list of items provided 305 will replace the existing list of items set on the object. 306 The concrete "dataSet:fListItemType" field along with the DSF 307 type can determine what is the possible set of list item 308 values. 309 "add": Specifies that the list item will be added to the object 310 if it is not already set. 311 "rem": Specifies that the list item will be removed from the 312 object and expects it to already be set. 314 Example definition of the field element that extends 315 the "dataSet:fieldPrimaryKeyType" base field type with the XML type 316 dataSet:labelType and with the required "class" attribute: 318 321 322 323 324 325 327 329 330 331 333 2.4.2. Data Set Field Elements 335 The dataSet-1.0 XML schema predefines a set of field elements that 336 can be used as child elements of the element of the 337 header to define the CSV record fields. The dataSet-1.0 field 338 elements with the XML schema type value and the base type include: 340 : Field that represents the name of an object. This 341 field extends a "dataSet:fieldPrimaryKeyType", as defined in 342 Section 2.4.1, with the type="token". The required "class" 343 attribute defines the class of the object, like the use of 344 "domain" for a domain name. It is recommended to use an object 345 specific name field if available, like . 346 : Object authorization information with 347 type="eppcom:pwAuthInfoType". 348 : Field that represents the result of 349 processing an individual record using the codes defined in 350 Section 5. The field extends a "dataSet:fieldRequiredType", as 351 defined in Section 2.4.1, with the type="dataSet:resultCodeType". 352 : Field containing the human-readable 353 description of the result code. The field extends a 354 "dataSet:fieldOptionalType", as defined in Section 2.4.1, with 355 the type="normalizedString". The field includes the OPTIONAL 356 "lang" attribute with the default value of "en" (English). 357 : Field containing the human-readable message 358 that describes the reason for the error processing the record. 359 The field extends the "dataSet:fieldOptionalType", as defined in 360 Section 2.4.1, with the type="normalizedString". The language of 361 the reason is identified the OPTIONAL "lang" attribute. If not 362 specified, the default attribute value is "en" (English). 364 Example definition for a result file generated by a 365 server that includes a domain name with a result code, with an 366 OPTIONAL result message, and an OPTIONAL result reason: 368 369 370 371 372 373 375 2.4.2.1. Field Element Extensibility 377 New field elements MAY be defined in separate XML schemas and 378 referenced as child elements of the element. The 379 convention is to prefix all field elements with a lowercase "f", as 380 in for the object name or for 381 the result code. The following are the steps to define a new field 382 element: 384 1. Define a new XML schema or extend an existing XML schema to 385 include the definition of the field element. The XML schema will 386 have it's own XML namespace that will be referenced in the header 387 of the Data Set File (DSF). 388 2. Define a new XML schema complexType that is a direct or indirect 389 extension of the "dataSet:fieldType" complexType. The new 390 complexType MUST directly, or indirectly define through 391 extension, the following attibutes: 393 "type": Defines the XML schema data type of the CSV field. The 394 "default" value of the attribute is used to define the 395 default CSV field type using an XML schema simple data type. 396 Any XML namespaces MUST be escaped ("\:" instead of ":") so 397 the XML parser of the header can ignore the reference during 398 XML validation. The "type" attribute is used during CSV 399 validation leveraging the XML schema simple data type to 400 define the format. The "type" attribute can be overridden 401 when referencing the field element in the header. The "type" 402 attribute for the "dataSet:fResultCodeType" complexType is 403 defined as . When using the default 405 XML namespace, no escaping is necessary. For example for the 406 "dataSet:fResultMsg" complexType, the "type" attribute is 407 defined as . A validator of the Data Set 409 File (DSF) will apply the XML schema type to the CSV fields. 410 "isRequired": See the definition of the "isRequired" attribute 411 in Section 2.4. A required field can extend the 412 "dataSet:fieldRequiredType" complexType, as defined in 413 Section 2.4.1, or can explicitly specify the attribute. For 414 example, the "isRequired" attribute is set in the 415 "dataSet:fieldRequiredType" complexType as . 417 "isPrimaryKey": See the definition of the "isPrimaryKey" 418 attribute in Section 2.4. A primary key field can extend the 419 "dataSet:primaryKeyType" complexType, as defined in 420 Section 2.4.1, or can explicitly specify the attribute. For 421 example, the "isPrimaryKey" attribute is set in the 422 "dataSet:fieldPrimaryKeyType" complexType as . 424 3. Define the field element that uses the new complexType defined 425 above and that substitutes for the "dataSet:field" abstract 426 element. An example of defining the "dataSet:fResultCode" field 427 element is . 430 An example of defining the "dataSet:fResultReason" field element 431 is . 434 Example definition of the field element that is 435 required to be non-empty and with the CSV field type 436 "dataSet:resultCodeType": 438 442 443 444 445 446 448 449 450 452 Example definition of the field element that may 453 be empty (optional), with the CSV field type "normalizedString", and 454 with the additional optional "lang" attribute: 456 460 461 462 463 464 466 468 469 470 472 2.5. Routing 474 A Data Set File (DSF) MAY include data that targets multiple 475 independent backend services, but the object alone cannot be used to 476 determine the appropropriate backend service. An example is creating 477 a Contact Object (Section 4.3) in the .EXAMPLE1 domain registry 478 service and creating another Contact Object (Section 4.3) in the 479 .EXAMPLE2 domain registry service within a single DSF, where 480 .EXAMPLE1 and .EXAMPLE2 are independent domain registry services. 481 The Data Set File (DSF) processor MAY coordinate with the backend 482 services to process each of the DSF records, but it is dependent on 483 the client to specify the target backend service with each record. 485 The Data Set File (DSF) field element used for routing a record to a 486 specific backend service includes: 488 : Contains the unique sub-product name of a 489 backend service with type="token". It is up to server policy on 490 the valid list of sub-product values. An example of a sub- 491 product value is the Top Level Domain (TLD) of a domain registry 492 service. 494 Routing is most applicable to objects like a Contact Object 495 (Section 4.3) and a Host Object (Section 4.2), where the keys 496 ( for the Contact Object and for the 497 Host Object) MAY NOT be enough to uniqually identify a target domain 498 registry service. An example of using the 499 field for routing is provided with the "contact.create.routing" DSF 500 in Section 4.3. 502 3. Data Set File (DSF) Format 504 The Data Set File (DSF) format supports multiple types of requests 505 and response files. All of these types of files support a general 506 file format that includes a header that provides meta-data about the 507 data including the what, who, when, and optionally the digital 508 signature of the information, and the body containing the data. The 509 Data Set File (DSF) syntax is specified using Augmented Backus-Naur 510 Form (ABNF) grammar [RFC5234] as follows: 512 Data Set File (DSF) ABNF 514 file = header body 515 header = dataSet-1-0 LF 516 dataSet-1-0 = 1*(1*VCHAR LF) ; compliant to dataSet-1.0 517 body = start [data] end 518 start = "-----BEGIN DATA SET-----" LF 519 data = 1*VCHAR LF ; CSV compliant 520 end = "-----END DATA SET-----" *1LF 522 3.1. Header Format 524 The header of the Data Set File (DSF) is an XML document that 525 complies with the dataSet-1.0 XML schema. The purpose of the header 526 is to provide the meta-data about the data contained in the body. 527 The element is the root XML element of the 528 header and contains the following child element: 530 or or 531 : 533 : Provides meta-data about the body of the file 534 that is not digitally signed, as described in Section 3.1.1. 535 : Contains the encoded form of the 536 digitally signed element, as 537 described in in Section 3.1.2. 538 : Provides the high level result data with 539 the processing of a request Data Set File (DSF) by the 540 server, as described in Section 3.1.3. 542 3.1.1. element 544 The element contains the meta-data of the body of 545 the file that is not digitally signed. The element 546 contains the following child elements: 548 : The type value and OPTIONAL "subType" attribute 549 value of the Data Set File (DSF), as defined in Section 2.3. 550 : Ordered list of CSV fields as defined in 551 Section 2.4. 552 : OPTIONAL unique identifier of the Data Set File 553 (DSF). The client SHOULD assign a unique identifer when 554 generating the Data Set File (DSF) and set it in the 555 element. 556 : Contains the date and time of the Data Set File 557 (DSF) creation. 559 Example element for setting verification codes on a 560 domain name: 562 563 564 565 verificationCode.update.encodedSignedCode 566 567 568 569 570 571 abc-123 572 2016-04-03T22:00:00.0Z 573 575 3.1.2. element 577 The element contains the encoded form 578 of the digitally signed element, described in 579 Section 3.1.2.1, with the encoding defined by the "encoding" 580 attribute with the default "encoding" value of "base64". The 581 "base64" encoded text of the element MUST 582 conform to [RFC2045]. 584 Example element, where "..." 585 represents continuation of data for brevity: 587 588 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 589 ... 590 b25Db2RlOnNpZ25lZENvZGU+Cg== 591 593 3.1.2.1. Signed Definition Data 595 The Signed Definition Data, represented by the 596 element, is a signed extension of the 597 element, defined in Section 3.1.1. The 598 provides the meta-data about the body of the 599 file, that is a fragment of XML that is digitally signed using XML 600 Signature [W3C.CR-xmldsig-core2-20120124]. The 601 element includes a required "id" attribute of 602 type XSD ID for use with the IDREF URI from the Signature element. 603 Setting the "id" attribute value to "signedData" is recommended. The 604 certificate of the issuer MUST be included with the Signature so it 605 can be chained with the issuer's certificate by the validating 606 client. A checksum, as defined by the Section 2.2, of the body of 607 the file, as defined by the body rule of the Data Set File (DSF) 608 ABNF, is included in the digitally signed data to ensure that it's 609 covered by the Signature. The element 610 contains the following child elements: 612 : The type value and OPTIONAL "subType" attribute 613 value of the Data Set File (DSF), as defined in Section 2.3. 614 : Ordered list of CSV fields as defined in 615 Section 2.4. 616 OPTIONAL unique identifier of the data set. The 617 source SHOULD assign a unique identifer when generating the data 618 set and set it in the element. 619 : Contains the date and time of the data set 620 creation. 621 : Checksum of the body of the file, as defined by the 622 body rule of the Data Set File (DSF) ABNF, using the mechanism 623 defined by the Section 2.2. 624 : XML Signature [W3C.CR-xmldsig-core2-20120124] for the 625 . Use of a namespace prefix, like "dsig", 626 is recommended for the XML Signature 627 [W3C.CR-xmldsig-core2-20120124] elements. 629 Example element, where "..." represents 630 continuation of data for brevity: 632 640 641 verificationCode.update.encodedSignedCode 642 643 644 645 646 647 648 abc-123 649 2016-04-03T22:00:00.0Z 650 6F2B988F 651 652 653 655 657 658 659 661 662 664 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 665 666 667 668 669 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 670 ... 671 ipJsXNa6osTUw1CzA7jfwA== 672 673 674 675 676 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 677 ... 678 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 679 680 681 682 683 685 3.1.3. element 687 The element contains the high level result data 688 with the processing of a request Data Set File (DSF) by the server. 689 the "code" attribute describes the success or failure of the 690 processing using the code values defined in Section 5. The 691 element contains the following child elements: 693 : OPTIONAL type value and OPTIONAL "subType" attribute 694 value associaed with the request Data Set File (DSF), as defined 695 in Section 2.3. The element MUST be returned if 696 the request header is successfully parsed. 697 : OPTIONAL ordered list of CSV fields as defined in 698 Section 2.4. If the element is not defined, 699 then the data as defined by the data rule of the Data Set File 700 (DSF) ABNF MUST be empty. 701 : OPTIONAL identifier of the Data Set File (DSF) 702 formed using the element associated with the 703 request if supplied by the client and the request header is 704 successfully parsed. 705 : Human-readable description of the result code. The 706 language of the result is identified via an OPTIONAL "lang" 707 attribute. If not specified, the default attribute value is "en" 708 (English). 709 : OPTIONAL human-readable message that describes the 710 reason for the error. The language of the reason is identified 711 via an OPTIONAL "lang" attribute. If not specified, the default 712 attribute value is "en" (English). 713 : OPTIONAL summary record result data. The summary 714 data is associated with the count of the records (lines in 715 request data). The element contains the 716 following child elements: 718 : Total count of the records (lines in request 719 data) processed by the server. 720 : Total count of the records (lines in request 721 data) successfully processed by the server. 722 : Total count of the records (lines in request 723 data) that failed processing by the server. 725 Example successful element: 727 728 729 verificationCode.update.encodedSignedCode 730 731 732 733 734 735 736 737 abc-123 738 54322-XYZ 739 Code Set processed successfully. 740 741 2 742 2 743 0 744 745 746 Example element with some failures: 748 749 750 verificationCode.update.encodedSignedCode 751 752 753 754 755 756 757 758 abc-123 759 54322-XYZ 760 Success with failures 761 762 4 763 1 764 3 765 766 768 Example failed element based on malformed 769 request file: 771 772 54322-XYZ 773 File syntax error 774 Malformed request file 775 776 778 Example failed element based on header syntax 779 error: 781 782 54322-XYZ 783 Header syntax error 784 Header XML syntax error 785 786 787 Example failed element based on body syntax 788 error: 790 791 792 verificationCode.update.encodedSignedCode 793 794 abc-123 795 54322-XYZ 796 Body syntax error 797 Invalid with fields definition 798 799 801 3.2. Body Format 803 The body of the Data Set File (DSF) is a set of Comma-Separated 804 Values (CSV) data that includes a leading "-----BEGIN CODE SET-----" 805 line and a trailing "-----END CODE SET-----" line. The format of the 806 CSV data is defined by the element in the header 807 (Section 3.1), that includes the delimiter and the ordered set of 808 fields (Section 2.4) with their XML simple type and descriptor 809 attributes like "isRequired", "isPrimaryKey", "class", and 810 "codeType". 812 Example body for a result file generated by a server that includes a 813 success and a set of failed records with a mix of messages and 814 reasons.: 816 -----BEGIN DATA SET----- 817 domain1.example,1000,Success, 818 domain2.example,2303,Object does not exist, 819 domain3.example,2201,Authorization error, 820 domain4.example,2302,Object exists,domain code already 821 -----END DATA SET----- 823 4. Object Description 825 This section describes the base objects supported by this 826 specification: 828 4.1. Domain Name Object 830 The domain name object is based on the EPP domain name mapping 831 specified in [RFC5731]. 833 The Data Set File (DSF) field elements specific to the domain name 834 object include: 836 : Domain name field with type="eppcom:labelType" 837 and isRequired="true". 838 : Domain name initial or extension period of the 839 expiration date with type="domain:pLimitType". 840 : Domain name initial or extension period 841 unit of the expiration date with type="domain:pUnitType". 842 : Domain name server is an extension of the 843 "dataSet:fListItemType" field, described in Section 2.4.1, with 844 type="eppcom:labelType". 845 : Domain contact identifer with 846 type="eppcom:clIDType" and with required "role" attribute. The 847 possible values of the "role" attribute include "registrant", 848 "admin", "tech", and "billing". 849 : The status of the domain name is an extension 850 of the "dataSet:fListItemType" field, described in Section 2.4.1, 851 with type="domain:statusValueType". 852 : Contains the DS key tag value per [RFC5910] 853 with type="unsignedShort". 854 : Contains the DS algorithm value per [RFC5910] 855 with type="unsignedByte". 856 : Contains the DS digest type value per 857 [RFC5910] with type="unsignedByte". 858 : Contains the DS digest value per [RFC5910] with 859 type="hexBinary". 860 : Contains the flags field value per [RFC5910] 861 with type="unsignedShort". 862 : Contains the Key protocol value per [RFC5910] 863 with type="unsignedByte". 864 : Contains the Key algorithm value per [RFC5910] 865 with type="unsignedByte". 866 : Contains the public key value per [RFC5910] 867 with type="secDNS:keyType". 868 : Indicates a child's preference for the 869 number of seconds after signature generation when the parent's 870 signature on the DS information provided by the child will expire 871 with type="secDNS:maxSigLifeType" defined in [RFC5910]. 873 The following are example DSF files using the domain object fields. 874 The different forms of domain object DSF files is up to server 875 policy. 877 Example of a "domain.update.replaceClientStatuses" DSF that will set 878 the client statuses of a domain name to those specified in the DSF 879 record. The client statuses set will be replaced by the set of 880 client statuses specified. Empty statuses will result in the removal 881 of those statuses if previously set. Non-empty statuses will be 882 added if not previously set. Non-empty statuses will result in no 883 change if previously set. All five client statuses defined in 884 [RFC5731] are defined in the DSF in fixed order. 886 887 892 893 894 domain.update.replaceClientStatuses 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 abc-123 910 2016-04-03T22:00:00.0Z 911 912 913 -----BEGIN DATA SET----- 914 domain1.example,clientDeleteProhibited,,,,clientUpdateProhibited 915 domain2.example,,clientHold,,, 916 domain3.example,,,clientRenewProhibited,clientTransferProhibited, 917 domain4.example,,,,, 918 -----END DATA SET----- 919 Example of a "domain.update.addRemoveStatus" DSF that will add a 920 status and remove a status for each domain name. Any status can be 921 empty to indicate no action for that domain name. 923 924 929 930 931 domain.update.addRemoveNs 932 933 934 935 936 937 938 abc-123 939 2016-04-03T22:00:00.0Z 940 941 942 -----BEGIN DATA SET----- 943 domain1.example,ns1.domain1.example,n2.domain1.example 944 domain2.example,ns1.domain1.example, 945 domain3.example,,ns2.domain1.example 946 -----END DATA SET----- 947 Example of a "domain.update.replaceNs" DSF that will set the name 948 servers of a domain name to those specified in the DSF record. The 949 server supports setting up to 13 name servers to a domain name, so 950 there are 13 defined. All existing name servers set 951 will be replaced with the name servers specified. 953 954 959 960 961 domain.update.replaceNs 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 abc-123 980 2016-04-03T22:00:00.0Z 981 982 983 -----BEGIN DATA SET----- 984 domain1.example,ns1.domain1.example,n2.domain1.example,,,,,,,,,,, 985 domain2.example,ns1.domain1.example,,,,,,,,,,,, 986 domain3.example,,,,,,,,,,,,, 987 -----END DATA SET----- 988 Example of a "domain.update.addRemoveNs" DSF that will add a name 989 server and remove a name server for each domain name. Any name 990 server can be empty to indicate no action for that domain name. 992 993 998 999 1000 domain.update.addRemoveNs 1001 1002 1003 1004 1005 1006 1007 abc-123 1008 2016-04-03T22:00:00.0Z 1009 1010 1011 -----BEGIN DATA SET----- 1012 domain1.example,ns1.domain1.example,n2.domain1.example 1013 domain2.example,ns1.domain1.example, 1014 domain3.example,,ns2.domain1.example 1015 -----END DATA SET----- 1016 Example of a "domain.update.contacts" DSF that supports updating the 1017 contacts (registrant, admin, tech, and billing) for each domain name. 1018 All four contacts fields are set as required using the "isRequired" 1019 attribute and any existing contacts set for each domain name are 1020 replaced. 1022 1023 1028 1029 1030 domain.update.contacts 1031 1032 1033 1034 1035 1036 1037 1038 1039 abc-123 1040 2016-04-03T22:00:00.0Z 1041 1042 1043 -----BEGIN DATA SET----- 1044 domain1.example,jd1234,sh813,sh813,sh813 1045 domain2.example,jd1234,sh813,sh813, 1046 -----END DATA SET----- 1047 Example of a "domain.create.standard" DSF that supports creating each 1048 domain name record with a standard set of fields / attributes for a 1049 thick domain name. 1051 1052 1057 1058 1059 domain.create.standard 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 abc-123 1073 2016-04-03T22:00:00.0Z 1074 1075 1076 -----BEGIN DATA SET----- 1077 domain1.example,1,ns1.dom.example,,jd1234,sh813,sh813,sh813,2fooBAR 1078 domain2.example,1,,,jd1234,sh813,sh813,sh813,2fooBAR 1079 -----END DATA SET----- 1081 4.2. Host Object 1083 The host object is based on the EPP host mapping specified in 1084 [RFC5732]. 1086 The Data Set File (DSF) field elements specific to the host object 1087 include: 1089 : Host name field with type="eppcom:labelType" and 1090 isRequired="true". 1091 : Host new name field used to rename the host with 1092 type="eppcom:labelType". 1093 : The address version ("v4" or "v6") is an 1094 extension of the "dataSet:fListItemType" field, described in 1095 Section 2.4.1, with type="eppcom:addrStringType". The 1096 "dsfHost.fAddrVersion" field usually corresponds with a following 1097 "dsfHost:fAddr" field. The "dsfHost:fAddrVersion" and 1098 "dsfHost.fAddr" fields are included in pairs. 1099 : The address is an extension of the 1100 "dataSet:fListItemType" field, described in Section 2.4.1, with 1101 type="eppcom:addrStringType". The "dsfHost.fAddr" field usually 1102 corresponds with a previous "dsfHost:fAddrVersion" field that 1103 defines the type of address. The "dsfHost:fAddrVersion" and 1104 "dsfHost.fAddr" fields are included in pairs. 1105 : The status of the host is an extension of the 1106 "dataSet:fListItemType" field, described in Section 2.4.1, with 1107 type="host:statusValueType". 1109 The following are example DSF files using the host object fields. 1110 The different forms of host object DSF files is up to server policy. 1112 Example of a "host.update.replaceClientStatuses" DSF that will set 1113 the client statuses of a host to those specified in the DSF record. 1114 The client statuses set will be replaced by the set of client 1115 statuses specified. Empty statuses will result in the removal of 1116 those statuses if previously set. Non-empty statuses will be added 1117 if not previously set. Non-empty statuses will result in no change 1118 if previously set. All two client statuses defined in [RFC5732] are 1119 defined in the DSF in fixed order. 1121 1122 1127 1128 1129 host.update.replaceClientStatuses 1130 1131 1132 1133 1134 1135 1136 1137 1138 abc-123 1139 2016-04-03T22:00:00.0Z 1140 1141 1142 -----BEGIN DATA SET----- 1143 ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited 1144 ns2.domain.example,,clientUpdateProhibited 1145 ns3.domain.example,clientDeleteProhibited, 1146 ns4.domain.example,, 1147 -----END DATA SET----- 1148 Example of a "host.update.addRemoveStatus" DSF that will add a status 1149 and remove a status for each host. Any status can be empty to 1150 indicate no action for that host. 1152 1153 1158 1159 1160 host.update.addRemoveClientStatuses 1161 1162 1163 1164 1165 1166 1167 abc-123 1168 2016-04-03T22:00:00.0Z 1169 1170 1171 -----BEGIN DATA SET----- 1172 ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited 1173 ns2.domain.example,,clientUpdateProhibited 1174 ns3.domain.example,clientUpdateProhibited, 1175 -----END DATA SET----- 1176 Example of a "host.update.replaceAddr" DSF that will set the 1177 addresses of a host to those specified in the DSF record. The server 1178 supports setting up to 6 addresses to a host, so there are 6 1179 and field pairs defined. All 1180 existing addresses set will be replaced with the addresses specified. 1182 1183 1188 1189 1190 host.update.replaceAddr 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 abc-123 1208 2016-04-03T22:00:00.0Z 1209 1210 1211 -----BEGIN DATA SET----- 1212 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29,,,,,,,, 1213 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,,,,,,,,,, 1214 ns3.domain.example,,,,,,,,,,,, 1215 -----END DATA SET----- 1216 Example of a "host.update.addRemoveAddr" DSF that will add an address 1217 and remove an address for each host. Any address can be empty to 1218 indicate no action for that host. The and 1219 field pairs are provided with matching list 1220 operations. 1222 1223 1228 1229 1230 host.update.addRemoveAddr 1231 1232 1233 1234 1235 1236 1237 1238 1239 abc-123 1240 2016-04-03T22:00:00.0Z 1241 1242 1243 -----BEGIN DATA SET----- 1244 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29 1245 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,, 1246 ns3.domain.example,,v4,192.0.2.29 1247 -----END DATA SET----- 1248 Example of a "host.create.standard" DSF that supports creating each 1249 host record with a standard set of fields / attributes for a host. 1250 There is an example of creating an internal host (ns1.domain.example 1251 and ns2.domain.example) with up to two addresses and an external host 1252 (ns1.domain.external) without addresses. 1254 1255 1260 1261 1262 host.create.standard 1263 1264 1265 1266 1267 1268 1269 1270 1271 abc-123 1272 2016-04-03T22:00:00.0Z 1273 1274 1275 -----BEGIN DATA SET----- 1276 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29 1277 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A, 1278 ns1.domain.external,,,, 1279 -----END DATA SET----- 1281 4.3. Contact Object 1283 The contact object is based on the EPP host mapping specified in 1284 [RFC5733]. 1286 Some elements MAY be provided in either internationalized form 1287 ("int") or provided in localized form ("loc"). Those elements use a 1288 field value or "isLoc" attribute to specify the form used. If an 1289 "isLoc" attribute is used, a value of "true" indicates the use of the 1290 localized form and a value of "false" indicates the use of the 1291 internationalized form. This MAY override the form specified for a 1292 parent element. A value of "int" is used to indicate the 1293 internationalized form and a value of "loc" is used to indicate the 1294 localized form. When the internalized form ("int") is provided, the 1295 field value MUST be represented in a subset of UTF-8 that can be 1296 represented in the 7-bit US-ASCII character set. When the localized 1297 form ("loc") is provided, the field value MAY be represented in 1298 unrestricted UTF-8. Some of the contact field elements specify the 1299 internationalized form with the isLoc="false" attribute. 1301 The Data Set File (DSF) field elements specific to the contact object 1302 include: 1304 : Contains the server-unique contact identifier with 1305 type="eppcom:clIDType" and isRequired="true". 1306 : Contains the contact's email address with 1307 type="eppcom:minTokenType" and isRequired="true". 1308 : Contains the contact's voice telephone number 1309 with type="contact:e164StringType". 1310 : Contains the contact's voice telephone 1311 number extension with type="token". 1312 : Contains the contact's facsimile telephone number 1313 with type="contact:e164StringType". 1314 : Contains the contact's facsimile telephone 1315 number extension with type="token". 1316 : Contains the contact's name of the individual or 1317 role represented by the contact with 1318 type="contact:postalLineType" and isRequired="true". An OPTIONAL 1319 "isLoc" attribute to used to indicate the localized or 1320 internationalized form. 1321 : Contains the contact's contact's street 1322 address line with type="contact:fPostalLineType". An index 1323 attribute is required to indicate which street address line the 1324 field represents with index "0" for the first line and index "2" 1325 for the last line. An OPTIONAL "isLoc" attribute to used to 1326 indicate the localized or internationalized form. 1327 : Contains the contact's city with 1328 type="contact:postalLineType" and isRequired="true". An OPTIONAL 1329 "isLoc" attribute to used to indicate the localized or 1330 internationalized form. 1331 : Contains the contact's country code with 1332 type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" 1333 attribute to used to indicate the localized or internationalized 1334 form. 1335 : Contains the form of the postal-address 1336 information with type="contact:postalLineType". This field 1337 specifies the form ("int" or "loc") of the , 1338 , , , 1339 , , fields. 1340 : Contains the name of the organization with which 1341 the contact is affiliated with type="contact:optPostalLineType". 1342 An OPTIONAL "isLoc" attribute to used to indicate the localized 1343 or internationalized form. 1345 : Contains the contact's state or province with 1346 type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute 1347 to used to indicate the localized or internationalized form. 1348 : Contains the contact's postal code with 1349 type="contact:pcType". An OPTIONAL "isLoc" attribute to used to 1350 indicate the localized or internationalized form. 1351 : Contains flag with a value of "true" or 1352 "1" (one) notes the preference to allow disclosure of the 1353 specified elements as an exception to the stated data-collection 1354 policy. A value of "false" or "0" (zero) notes a client 1355 preference to not allow disclosure of the specified elements as 1356 an exception to the stated data-collection policy with 1357 type="boolean". The additional fields define specific 1358 exceptional disclosure preferences based on the 1359 field. 1360 : Exceptional disclosure preference 1361 flag for the localized form of the contact name with 1362 type="boolean". 1363 : Exceptional disclosure preference 1364 flag for the internationalized form of the contact name with 1365 type="boolean". 1366 : Exceptional disclosure preference flag 1367 for the localized form of the contact organization with 1368 type="boolean". with type="boolean". 1369 : Exceptional disclosure preference flag 1370 for the internationalized form of the contact organization with 1371 type="boolean". with type="boolean". 1372 : Exceptional disclosure preference 1373 flag for the localized form of the contact address with 1374 type="boolean". 1375 : Exceptional disclosure preference 1376 flag for the internationalized form of the contact address with 1377 type="boolean". 1378 : Exceptional disclosure preference flag 1379 of the contact voice telephone number with type="boolean". 1380 : Exceptional disclosure preference flag of 1381 the contact facsimile telephone number with type="boolean". 1382 : Exceptional disclosure preference flag 1383 of the contact email address with type="boolean". 1384 : Exceptional disclosure preference flag of 1385 all of the supported disclose fields with type="boolean". This 1386 single field represents the field 1387 value for all of the disclose fields, that include 1388 , , 1389 , , 1390 , , 1391 , , and 1392 . 1394 The following are example DSF files using the contact object fields. 1395 The different forms of contact object DSF files is up to server 1396 policy. 1398 Example of a "contact.update.replaceClientStatuses" DSF that will set 1399 the client statuses of a contact to those specified in the DSF 1400 record. The client statuses set will be replaced by the set of 1401 client statuses specified. Empty statuses will result in the removal 1402 of those statuses if previously set. Non-empty statuses will be 1403 added if not previously set. Non-empty statuses will result in no 1404 change if previously set. All three client statuses defined in 1405 [RFC5733] are defined in the DSF in fixed order. 1407 1408 1413 1414 1415 contact.update.replaceClientStatuses 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 abc-123 1427 2016-04-03T22:00:00.0Z 1428 1429 1430 -----BEGIN DATA SET----- 1431 sh1111,clientDeleteProhibited,,clientUpdateProhibited 1432 sh2222,,clientUpdateProhibited 1433 sh3333,,clientTransferProhibited, 1434 sh4444,,, 1435 -----END DATA SET----- 1436 Example of a "contact.update.addRemoveStatus" DSF that will add a 1437 status and remove a status for each contact. Any status can be empty 1438 to indicate no action for that contact. 1440 1441 1446 1447 1448 contact.update.addRemoveClientStatuses 1449 1450 1451 1452 1453 1454 1455 abc-123 1456 2016-04-03T22:00:00.0Z 1457 1458 1459 -----BEGIN DATA SET----- 1460 sh1111,clientDeleteProhibited,clientUpdateProhibited 1461 sh2222,,clientUpdateProhibited 1462 sh3333,clientUpdateProhibited, 1463 sh4444,clientTransferProhibited, 1464 -----END DATA SET----- 1466 Example of a "contact.create.standard" DSF that supports creating 1467 each contact record with a standard set of fields / attributes for a 1468 contact. A "|" character is used as a separator to minimize 1469 conflicting with the contact data. This is an example of creating 1470 two contacts, where indented data set lines are a continuation from 1471 the prior line. 1473 1474 1479 1480 1481 contact.create.standard 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 abc-123 1503 2016-04-03T22:00:00.0Z 1504 1505 1506 -----BEGIN DATA SET----- 1507 sh1111|int|John Doe|Example Inc.| 1508 123 Example Dr.|||Dulles|VA|20166-6503|US| 1509 +1.7035555555|1234|+1.7035555556|| 1510 johndoe@example.com|2fooBAR 1511 sh2222|int|Jane Doe|Example Inc.| 1512 123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US| 1513 +1.7035555555|||| 1514 janedoe@example.com|2fooBAR 1515 -----END DATA SET----- 1517 Example of a "contact.create.routing" DSF that extends the 1518 "contact.create.standard" DSF with the field 1519 (Section 2.5) to route the create to the appropriate Top Level Domain 1520 (TLD) or group of TLDs. A "|" character is used as a separator to 1521 minimize conflicting with the contact data. This is an example of 1522 creating two contacts, where indented data set lines are a 1523 continuation from the prior line. 1525 1526 1533 1534 1535 contact.create.routing 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 abc-123 1558 2016-04-03T22:00:00.0Z 1559 1560 1561 -----BEGIN DATA SET----- 1562 EXAMPLE|sh1111|int|John Doe|Example Inc.| 1563 123 Example Dr.|||Dulles|VA|20166-6503|US| 1564 +1.7035555555|1234|+1.7035555556|| 1565 johndoe@example.com|2fooBAR 1566 EXAMPLE|sh2222|int|Jane Doe|Example Inc.| 1567 123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US| 1568 +1.7035555555|||| 1569 janedoe@example.com|2fooBAR 1570 -----END DATA SET----- 1572 4.4. Verification Code Object 1574 The Verification Code Object is defined in the Verification Code 1575 Extension for the Extensible Provisioning Protocol 1576 [I-D.gould-eppext-verificationcode]. This section defines the 1577 Verification Code specific Data Set File (DSF) field elements and 1578 sample DSF files used to set verification codes with a bulk update. 1580 The Verification Service Provider (VSP) is a certified party to 1581 verify that data is in compliance with the policies of a locality. A 1582 locality MAY require the client to have data verified in accordance 1583 with local regulations or laws utilizing data sources not available 1584 to the server. The VSP has access to the local data sources and is 1585 authorized to verify the data. Examples include verifying that the 1586 domain name is not prohibited and verifying that the domain name 1587 registrant is a valid individual, organization, or business in the 1588 locality. The data verified, and the objects and operations that 1589 require the verification code to be passed to the server is up to the 1590 policies of the locality. The verification code represents a marker 1591 that the verification was completed. The data verified by the VSP 1592 MUST be stored by the VSP along with the generated verification codes 1593 in order to address any compliance issues. The signer certificate 1594 and the digital signature of the verification code MUST be verified 1595 by the server. 1597 The Data Set File (DSF) field elements specific to the Verification 1598 Code Object include: 1600 : Field that represents a Verification 1601 Code Token value. The field extends a 1602 "dataSet:fieldOptionalType", as defined in Section 2.4.1, with 1603 the type="dataSet:verificationCodeValueType". The field includes 1604 the required "codeType" attribute that represents the type of 1605 verification code, as defined by the "type" attribute of the 1606 element in 1607 [I-D.gould-eppext-verificationcode]. The verification code field 1608 can be empty since it is a "dataSet:fieldOptionalType". 1609 : Field that represents a 1610 Encoded Signed Code. The field extends a 1611 "dataSet:fieldOptionalType", as defined in Section 2.4.1, with 1612 the type="token". The field includes the OPTIONAL "encoding" 1613 attribute with the default value of "base64". The line breaks, 1614 defined in [RFC2045], MUST NOT be used with the "base64" Encoded 1615 Signed Code. 1617 The Data Set File (DSF) used for setting of the verification codes 1618 MAY include fields from other objects and the fields specific to the 1619 Verification Code Object. There are two scenarios in passing the 1620 verification codes based on who generates the DSF file, which 1621 includes: 1623 VSP Generated DSF: The VSP generates the Verification Code Token 1624 values, represented with the field, 1625 and digitally signs the DSF file by referencing the 1626 element in the DSF header. 1627 Client Generated DSF: The client generates the DSF file with a set 1628 of encoded signed codes, represented with the 1629 field, collected from 1630 the VSP to bulk submit them to the server. The 1631 element, described in Section 3.1.1, is referenced in the DSF 1632 header. 1634 The following examples reference verification codes supported by the 1635 China Locality, which includes the Domain Name Verification Code 1636 (DNVC) and the Real Name Verification Code (RNVC). Both China 1637 Locality verification codes are set on a domain name with the 1638 verification code type of "domain" used for the DNVC and the 1639 verification code type of "real-name" used for the RNVC. Other 1640 localities MAY include a different set of verification codes. 1642 Example VSP Generated DSF that includes a domain name primary key 1643 field, a "domain" code token value field, and a "real-name" token 1644 value field. The "base64" value includes "..." representing 1645 continuation of data for brevity: 1647 1648 1651 1652 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 1653 ... 1654 b25Db2RlOnNpZ25lZENvZGU+Cg== 1655 1656 1657 -----BEGIN DATA SET----- 1658 domain1.example,0-abc111,0-abc222 1659 domain2.example,0-abc333,0-abc444 1660 domain3.example,0-abc555, 1661 domain3.example,,0-abc666 1662 -----END DATA SET----- 1663 Example Client Generated Data Set File (DSF) that includes a domain 1664 name primary key field, a "domain" encoded signed code field, and a 1665 "real-name" encoded signed code field. The "base64" values include 1666 no line breaks and include "..." representing continuation of data 1667 for brevity: 1669 1670 1678 1679 1680 verificationCode.update.encodedSignedCode 1681 1682 1683 1684 1685 1686 1687 abc-123 1688 2016-04-03T22:00:00.0Z 1689 1690 1691 -----BEGIN DATA SET----- 1692 domain1.example,ICAg...GlvbkN,CAgICA...uOmlldG 1693 domain2.example,YW1zOb2R...GlvbkNvZGU6c2ln, 1694 domain3.example,,CAgICAnZ...htbDpZmljYXMCIKI 1695 -----END DATA SET----- 1697 5. Result Codes 1699 The result codes are based on and not equal to the reply codes 1700 defined in the EPP result codes of [RFC5730]. Four decimal digits 1701 are used to describe the success or failure of the processing of the 1702 Data Set File (DSF) or the processing of an individual record. Each 1703 digit of the result code has specific significance. 1705 The first digit denotes success or failure. The second digit denotes 1706 the result category, such as request syntax or security. The third 1707 and fourth digits provide explicit response detail within each result 1708 category. 1710 There are two values for the first digit of the result code: 1712 1yzz: Positive result. The file or record was processed by the 1713 system successfully. Partial successful results MAY be included. 1714 2yzz: Negative result. The file or record was not processed 1715 successfully. Partial successful results MAY NOT be included. 1717 The second digit groups responses into one of five specific 1718 categories: 1720 x0zz: File or record syntax 1721 x1zz: Implementation-specific rules 1722 x2zz: Security 1723 x3zz: Data Management 1724 x4zz: Server System 1726 Successful result codes: 1728 1000 "Success": 1729 This is the result for a successfully processed file when all 1730 records are processed successfully or the result for an 1731 individual record that is successfully processed. 1733 1001 "Success with failures": 1734 This is the result for a successfully processed file when some 1735 records are processed successfully and some records failed. 1737 1002 "Success with all failures": 1738 This is the result for a successfully processed file when all 1739 of the records failed. 1741 Error result codes: 1743 2000 "File syntax error": 1744 This result code occurs when the overall file is syntactically 1745 incorrect. 1747 2001 "Header syntax error": 1748 This result code occurs when the header is syntactically 1749 incorrect. 1751 2002 "Body syntax error": 1752 This result code occurs when the body is syntactically 1753 incorrect. 1755 2003 "Required parameter missing": 1756 This result code occurs when a server receives a request for 1757 which a required parameter has not been provided. 1759 2004 "Parameter value range error": 1760 This result code occurs when a server receives a request whose 1761 value is outside the range of values specified in the protocol. 1763 2005 "Parameter value syntax error": 1764 This result code occurs when a server receives a request whose 1765 value is improperly formed. 1767 2100 "Unimplemented protocol version": 1768 This result code occurs when a server receives a request 1769 version, as defined by the XML namespace of the header, that is 1770 not implemented by the server. 1772 2102 "Unimplemented option": 1773 This result code occurs when a server receives a request that 1774 contains a protocol option that is not implemented by the 1775 server. 1777 2103 "Unimplemented extension": 1778 This result code occurs when a server receives a request that 1779 contains an extension, as defined by the XML namespace used by 1780 a field element extension, that is not implemented by the 1781 server. 1783 2104 "Billing failure": 1784 This result code occurs when a server receives a request that 1785 cannot be completed due to a client-billing failure. 1787 2201 "Authorization error": 1788 This result code occurs when a server receives a request cannot 1789 be execute due to a client-authorization error. 1791 2202 "Invalid authorization information": 1792 This result code occurs when a server receives invalid 1793 authorization information to execute a request. 1795 2302 "Object exists": 1796 This result code occurs when a server receives a request to 1797 create an object that already exists in the repository. 1799 2303 "Object does not exist": 1800 This result code occurs when a server receives a request to 1801 transform an object that does not exist in the repository. 1803 2304 "Object status prohibits operation": 1804 This result code occurs when a server receives a request to 1805 transform an object that cannot be completed due to server 1806 policy or business practices. 1808 2305 "Object association prohibits operation": 1809 This result code occurs when a server receives a request to 1810 transform an object that cannot be completed due to 1811 dependencies to other objects that are associated with the 1812 target object. 1814 2306 "Parameter value policy error": 1815 This result code occurs when a server receives a request that 1816 contains a parameter value that is syntactically valid but 1817 semantically invalid due to local policy. 1819 2307 "Unimplemented object service": 1820 This result code occurs when a server receives a request to 1821 operate on an object that is not supported by the server. 1823 2308 "Data management policy violation": 1824 This result code occurs when a server receives a request whose 1825 execution results in a violation of server data management 1826 policies. 1828 2400 "Request failed": 1829 This result code occurs when a server receives a request that 1830 cannot be executed due to an internal server error that is not 1831 related to the protocol. 1833 The error result codes include some overlap that will require the 1834 server to decide which one to return based on server policy. For 1835 example, a "Header syntax error", represented by the error result 1836 code 2001, may have occured for multiple reasons including a 2003 1837 "Required parameter missing", a 2004 "Parameter value range error", 1838 or a 2005 "Parameter value syntax error". The overlapping reasons 1839 also apply at the record level, where an object may be syntactically 1840 incorrect with a 2005 "Parameter value syntax error", and also be 1841 against server policy with a 2306 "Parameter value policy error". 1842 The server SHOULD attempt to provide the most accurate error result 1843 code to match the error. For example, a syntax error defined by the 1844 protocol SHOULD take precedence over a server policy error. 1846 6. Example Data Set File (DSF) Result Files 1848 This section includes a set of Data Set File (DSF) result examples. 1850 6.1. Example Data Set File (DSF) with Result Data 1852 This section includes example Data Set File (DSF) files that 1853 reference the element, described in 1854 Section 3.1.3, for providing the meta-data about the result file, 1855 along with a set of fields that reference the 1856 field element, described in Section 2.4.2, for including the result 1857 code in processing the domain name record in the request. 1859 Example Data Set File (DSF) for a succesful result by the server: 1861 1862 1867 1868 1869 1870 1871 1872 1873 1874 abc-123 1875 54322-XYZ 1876 Code Set processed successfully. 1877 1878 2 1879 2 1880 0 1881 1882 1883 1884 -----BEGIN DATA SET----- 1885 domain1.example,1000,, 1886 domain2.example,1000,, 1887 -----END DATA SET----- 1888 Example Data Set File (DSF) for a partially successful result by the 1889 server: 1891 1892 1897 1898 1899 1900 1901 1902 1903 1904 abc-123 1905 54322-XYZ 1906 Success with failures 1907 1908 4 1909 1 1910 3 1911 1912 1913 1914 -----BEGIN DATA SET----- 1915 domain1.example,1000,Success, 1916 domain2.example,2303,Object does not exist, 1917 domain3.example,2201,Authorization error, 1918 domain4.example,2302,Object exists,domain code already set 1919 -----END DATA SET----- 1920 Example Data Set File (DSF) for a failure result by the server: 1922 1923 1926 1927 abc-123 1928 54322-XYZ 1929 File syntax error 1930 Malformed request file 1931 1932 1933 1934 -----BEGIN DATA SET----- 1935 -----END DATA SET----- 1937 7. Formal Syntax 1939 Each schema is included in a sub-section, starting with the Data Set 1940 schema and followed by each object schema. 1942 The formal syntax presented here is a complete schema representation 1943 of the object mapping suitable for automated validation of EPP XML 1944 instances. The BEGIN and END tags are not part of the schema; they 1945 are used to note the beginning and ending of the schema for URI 1946 registration purposes. 1948 7.1. Data Set Schema 1950 Data Set schema that represents the base XML schema for the Data Set 1951 File (DSF). 1953 BEGIN 1954 1955 1964 1965 1966 Data Set XML Schema 1967 1969 1971 1974 1977 1978 1979 1980 1982 1984 1986 1987 1988 1990 1991 1992 1993 1994 1995 1996 1998 1999 2000 2001 2002 2003 2004 2006 2007 2008 2009 2011 2013 2015 2018 2019 2021 2022 2023 2024 2025 2026 2027 2028 2030 2031 2034 2035 2036 2037 2038 2040 2041 2042 2043 2044 2045 2047 2048 2049 2050 2053 2056 2059 2061 2063 2067 2070 2071 2073 2075 2076 2077 2078 2079 2080 2081 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2134 2135 2136 2137 2138 2139 2141 2142 2143 2144 2146 2147 2148 2150 2151 2154 2155 2156 2157 2159 2160 2161 2162 2163 2166 2167 2168 2170 2171 2172 2173 2174 2175 2177 2179 2180 2181 2183 2184 2185 2186 2187 2188 2190 2192 2193 2194 2196 2197 2198 2199 2200 2201 2203 2205 2206 2207 2209 2210 2211 2212 2213 2214 2217 2218 2219 2221 2222 2223 2224 2225 2226 2227 2228 2230 2231 2232 2233 2234 2236 2237 2238 2240 2243 2244 2245 2246 2247 2249 2251 2252 2253 2255 2256 2259 2260 2261 2262 2263 2265 2266 2267 2269 2270 2271 2272 2273 2274 2276 2277 2278 2280 2281 2282 2283 2284 2285 2287 2288 2289 2291 2292 2295 2296 2297 2298 2299 2301 2302 2303 2305 2306 2309 2310 2311 2312 2313 2315 2317 2318 2319 2321 2322 2325 2326 2327 2328 2329 2331 2333 2334 2335 2337 2338 2339 2340 2341 2342 2344 2345 2346 2348 2349 2350 2351 2352 2353 2355 2356 2357 2359 2360 2361 2362 2363 2364 2366 2367 2368 2370 2371 END 2373 7.2. Domain Name Schema 2375 Domain Name Object XML schema that defines the fields specific to the 2376 Domain Name Object. 2378 BEGIN 2379 2381 2390 2393 2395 2397 2399 2402 2403 2404 Domain Name Data Set File (DSF) Object 2405 2406 2408 2409 2412 2413 2416 2417 2418 2419 2420 2422 2423 2424 2426 2427 2430 2431 2432 2433 2434 2436 2437 2438 2440 2441 2444 2445 2446 2447 2448 2451 2453 2454 2455 2457 2458 2459 2460 2461 2462 2463 2464 2466 2467 2470 2471 2472 2473 2474 2476 2477 2478 2480 2482 2483 2485 2486 2487 2488 2489 2491 2492 2493 2495 2496 2499 2500 2503 2504 2507 2508 2511 2512 2515 2516 2519 2520 2523 2524 2526 2527 2528 2529 2530 2532 2533 2534 2536 2537 2540 2541 2542 2543 2544 2545 2548 2549 2550 2552 2555 2556 END 2558 7.3. Host Schema 2560 Host Object XML schema that defines the fields specific to the Host 2561 Object. 2563 BEGIN 2564 2566 2574 2577 2579 2581 2584 2585 2586 Host Name Data Set File (DSF) Object 2587 2588 2590 2591 2594 2595 2598 2599 2600 2601 2602 2604 2605 2606 2608 2609 2612 2613 2614 2615 2616 2618 2619 2620 2622 2623 2625 2626 2627 2628 2629 2631 2632 2633 2635 2636 2639 2640 2641 2642 2643 2644 2646 2647 2648 2650 2653 2654 END 2656 7.4. Contact Schema 2658 Contact Object XML schema that defines the fields specific to the 2659 Contact Object. 2661 BEGIN 2662 2664 2672 2675 2677 2679 2682 2683 2684 Contact Data Set File (DSF) Object 2685 2686 2688 2689 2692 2693 2694 2695 2696 2698 2699 2700 2702 2703 2707 2708 2710 2712 2713 2714 2715 2716 2718 2719 2720 2722 2723 2725 2728 2729 2731 2732 2733 2734 2735 2737 2739 2740 2742 2746 2748 2749 2750 2751 2752 2754 2755 2756 2758 2759 2760 2761 2762 2763 2765 2766 2767 2768 2770 2771 2772 2773 2774 2775 2777 2778 2779 2780 2782 2783 2786 2787 2790 2791 2792 2794 2795 2796 2797 2798 2800 2801 2802 2804 2805 2808 2809 2812 2813 2815 2816 2817 2818 2819 2821 2822 2823 2824 2826 2827 2829 2830 2831 2832 2833 2835 2836 2837 2838 2840 2841 2843 2845 2847 2849 2851 2853 2855 2857 2859 2861 2863 2865 2867 2869 2871 2873 2875 2877 2879 2882 2883 2884 2885 2886 2888 2889 2890 2892 2893 2896 2897 2898 2899 2900 2901 2903 2904 2905 2907 2910 2911 END 2913 7.5. Verification Code Schema 2915 Verification Code Object XML schema that defines the fields specific 2916 to the Verification Code Object. 2918 BEGIN 2919 2920 2929 2930 2931 Verification Code Data Set File (DSF) Object 2932 2933 2935 2938 2939 2941 2942 2943 2944 2945 2947 2948 2949 2950 2952 2953 2954 2955 2956 2957 2959 2960 2963 2964 2965 2966 2967 2969 2971 2972 2973 2975 2976 END 2978 7.6. Routing Schema 2980 Routing XML schema that defines the fields specific to routing. 2982 BEGIN 2983 2984 2993 2994 2995 Routing Data Set File (DSF) Fields 2996 2997 2999 3002 3003 3005 3006 3007 3008 3009 3011 3012 3013 3015 3016 END 3018 8. IANA Considerations 3020 8.1. XML Namespace 3022 This document uses URNs to describe XML namespaces and XML schemas 3023 conforming to a registry mechanism described in [RFC3688]. 3025 Registration request for the dataSet namespace: 3027 URI: ietf:params:xml:ns:dataSet-1.0 3028 Registrant Contact: See the "Author's Address" section of this 3029 document. 3030 XML: None. Namespace URIs do not represent an XML specification. 3032 Registration request for the dataSet XML schema: 3034 URI: ietf:params:xml:schema:dataSet-1.0 3035 Registrant Contact: See the "Author's Address" section of this 3036 document. 3037 XML: See the "Formal Syntax" section of this document. 3039 Registration request for the dsfDomain namespace: 3041 URI: ietf:params:xml:ns:dsfDomain-1.0 3042 Registrant Contact: See the "Author's Address" section of this 3043 document. 3044 XML: None. Namespace URIs do not represent an XML specification. 3046 Registration request for the dsfDomain XML schema: 3048 URI: ietf:params:xml:schema:dsfDomain-1.0 3049 Registrant Contact: See the "Author's Address" section of this 3050 document. 3051 XML: See the "Formal Syntax" section of this document. 3053 Registration request for the dsfHost namespace: 3055 URI: ietf:params:xml:ns:dsfHost-1.0 3056 Registrant Contact: See the "Author's Address" section of this 3057 document. 3058 XML: None. Namespace URIs do not represent an XML specification. 3060 Registration request for the dsfHost XML schema: 3062 URI: ietf:params:xml:schema:dsfHost-1.0 3063 Registrant Contact: See the "Author's Address" section of this 3064 document. 3065 XML: See the "Formal Syntax" section of this document. 3067 Registration request for the dsfContact namespace: 3069 URI: ietf:params:xml:ns:dsfContact-1.0 3070 Registrant Contact: See the "Author's Address" section of this 3071 document. 3072 XML: None. Namespace URIs do not represent an XML specification. 3074 Registration request for the dsfContact XML schema: 3076 URI: ietf:params:xml:schema:dsfContact-1.0 3077 Registrant Contact: See the "Author's Address" section of this 3078 document. 3079 XML: See the "Formal Syntax" section of this document. 3081 Registration request for the dsfVerificationCode namespace: 3083 URI: ietf:params:xml:ns:dsfVerificationCode-1.0 3084 Registrant Contact: See the "Author's Address" section of this 3085 document. 3086 XML: None. Namespace URIs do not represent an XML specification. 3088 Registration request for the dsfVerificationCode XML schema: 3090 URI: ietf:params:xml:schema:dsfVerificationCode-1.0 3091 Registrant Contact: See the "Author's Address" section of this 3092 document. 3093 XML: See the "Formal Syntax" section of this document. 3095 Registration request for the dsfRouting namespace: 3097 URI: ietf:params:xml:ns:dsfRouting-1.0 3098 Registrant Contact: See the "Author's Address" section of this 3099 document. 3100 XML: None. Namespace URIs do not represent an XML specification. 3102 Registration request for the dsfRouting XML schema: 3104 URI: ietf:params:xml:schema:dsfRouting-1.0 3105 Registrant Contact: See the "Author's Address" section of this 3106 document. 3107 XML: See the "Formal Syntax" section of this document. 3109 9. Security Considerations 3111 The data supported by the Data Set File (DSF) format MAY include 3112 information that needs to be protected with the use of a secure 3113 transport. For example, the field provides 3114 object authorization information, and as described in [RFC5731], both 3115 the client and the server MUST ensure that it is stored and exchanged 3116 with high-grade encryption mechanisms. The transport leveraged to 3117 exchange the DSF containing sensitive or secure data MUST protect it 3118 from inadvertent disclosure. 3120 XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this 3121 document to verify that the Data Set originated from a trusted source 3122 and that it wasn't tampered with in transit from the source to the 3123 client to the server. To support multiple source keys, the source 3124 certificate chain MUST be included in the elements 3125 of the Signed Def Data (Section 3.1.2.1) and MUST chain up and be 3126 verified by the server against a set of trusted certificates. 3128 It is RECOMMENDED that signed definition data does not include white- 3129 spaces between the XML elements in order to mitigate risks of 3130 invalidating the digital signature when transferring of signed codes 3131 between applications takes place. 3133 Use of XML canonicalization SHOULD be used when generating the signed 3134 code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing. 3135 The size of the RSA key SHOULD be at least 2048 bits. 3137 10. Normative References 3139 [I-D.gould-eppext-verificationcode] 3140 Gould, J., "Verification Code Extension for the Extensible 3141 Provisioning Protocol (EPP)", draft-gould-eppext- 3142 verificationcode-04 (work in progress), September 2016. 3144 [iso13239] 3145 the International Organization for Standardization, "ISO 3146 13239", December 2007, 3147 . 3150 [itu-t-V.42] 3151 International Telecommunication Union, "ITU-T V.42 Series 3152 V: Data Communication Over the Telephone Network", March 3153 2002, . 3155 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3156 Extensions (MIME) Part One: Format of Internet Message 3157 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 3158 . 3160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3161 Requirement Levels", BCP 14, RFC 2119, 3162 DOI 10.17487/RFC2119, March 1997, . 3165 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3166 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3167 . 3169 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3170 DOI 10.17487/RFC3688, January 2004, . 3173 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3174 Specifications: ABNF", STD 68, RFC 5234, 3175 DOI 10.17487/RFC5234, January 2008, . 3178 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 3179 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 3180 . 3182 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3183 Domain Name Mapping", STD 69, RFC 5731, 3184 DOI 10.17487/RFC5731, August 2009, . 3187 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3188 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 3189 August 2009, . 3191 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3192 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 3193 August 2009, . 3195 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 3196 Security Extensions Mapping for the Extensible 3197 Provisioning Protocol (EPP)", RFC 5910, 3198 DOI 10.17487/RFC5910, May 2010, . 3201 [W3C.CR-xmldsig-core2-20120124] 3202 Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, 3203 J., Solo, D., Datta, P., and F. Hirsch, "XML Signature 3204 Syntax and Processing Version 2.0", World Wide Web 3205 Consortium CR CR-xmldsig-core2-20120124, January 2012, 3206 . 3208 Appendix A. Acknowledgements 3210 The author wishes to acknowledge the work done by Scott Hollenbeck in 3211 the EPP RFC 5730 for providing some of the concepts and text used in 3212 this document. 3214 Special suggestions that have been incorporated into this document 3215 were provided by John Colosi, Deepak Deshpande, Scott Hollenbeck, 3216 Suzy Strier, and Srikanth Veeramachaneni. 3218 Appendix B. Change History 3220 B.1. Change from 00 to 01 3222 1. Fixed the ABNF. 3223 2. Added support for the 1002 "Success with all failures" result 3224 code to indicate that the file was successfully processed but 3225 that all of the records failed. 3226 3. Updated the description for the 1000 "Success" and the 1001 3227 "Success with failures" result codes. 3229 B.2. Change from 01 to 02 3231 1. Made small editorial changes based upon a review. 3233 Author's Address 3235 James Gould 3236 VeriSign, Inc. 3237 12061 Bluemont Way 3238 Reston, VA 20190 3239 US 3241 Email: jgould@verisign.com 3242 URI: http://www.verisign.com