idnits 2.17.1 draft-gould-regext-dataset-01.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 (March 30, 2017) is 2584 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 3193, 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 March 30, 2017 5 Expires: October 1, 2017 7 Data Set File Format 8 draft-gould-regext-dataset-01 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 October 1, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 74 104 1. Introduction 106 This document defines a Data Set File (DSF) format that can be used 107 to define and pass bulk data between a client and a server. The 108 client and server MAY leverage a provisioning protocol like EPP, as 109 defined in [RFC5730], to provision individual objects, but the 110 provisioning protocol MAY NOT handle all provisioning use cases. 111 This document defines a format for bulk provisioning requests that 112 can be generated by authorized third parties, can be generated by 113 clients that choose not to leverage the provisioning protocol, and 114 can be supported by servers to process bulk requests in a controlled 115 manner that throttles the processing against the provisioning 116 database. Bulk requests can include court orders, out-of-band client 117 requests to fix data, the backfill of data like contact or 118 verification code data, and a large set of ad-hoc needs. 120 This format is extensible to pass any set of simple data types in a 121 set of records contained in the body of the file. The file format 122 also supports storing the result of processing the data set that MAY 123 be generated by the server and returned to the client. The file 124 format consists of an XML definition header and a Comma-Separated 125 Values (CSV) data section delimited by "-----BEGIN DATA SET-----" and 126 "-----END DATA SET-----" lines. The XML definition header defines 127 the format of the CSV data section, contains additional meta-data, 128 and optionally includes a digital signature to identify the source 129 and ensure that the data has not been tampered with between the 130 parties (source, client, and server) using XML Signature 131 [W3C.CR-xmldsig-core2-20120124]. All XML Signature 132 [W3C.CR-xmldsig-core2-20120124] data is "base64" encoded, in 133 conformance with [RFC2045], by default to mitigate any validation 134 errors due to whitespace formatting. The interface (manual or 135 automated) that is used to submit the file and receive the result 136 file is not defined within this document and must be documented 137 independently. Please see Section 9 for a description of the issues 138 associated with transport security. 140 1.1. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 XML is case sensitive. Unless stated otherwise, XML specifications 147 and examples provided in this document MUST be interpreted in the 148 character case presented in order to develop a conforming 149 implementation. 151 The following XML abbreviations are used: 153 "eppcom" XML namespace prefix refers to 154 "urn:ietf:params:xml:ns:eppcom-1.0" XML namespace in [RFC5730]. 155 "domain" XML namespace prefix refers to 156 "urn:ietf:params:xml:ns:domain-1.0" XML namespace in [RFC5731]. 157 "host" XML namespace prefix refers to 158 "urn:ietf:params:xml:ns:host-1.0" XML namespace in [RFC5732]. 159 "contact" XML namespace prefix refers to 160 "urn:ietf:params:xml:ns:contact-1.0" XML namespace in [RFC5733]. 161 "dataSet-1.0" is used as an abbreviation for 162 "urn:ietf:params:xml:ns:dataSet-1.0". 163 "dataSet" XML namespace prefix refers to 164 "urn:ietf:params:xml:ns:dataSet-1.0" XML namespace. 165 "dsfDomain-1.0" is used as an abbreviation for 166 "urn:ietf:params:xml:ns:dsfDomain-1.0". 167 "dsfDomain" XML namespace prefix refers to 168 "urn:ietf:params:xml:ns:dsfDomain-1.0" XML namespace. 169 "dsfHost-1.0" is used as an abbreviation for 170 "urn:ietf:params:xml:ns:dsfHost-1.0". 171 "dsfHost" XML namespace prefix refers to 172 "urn:ietf:params:xml:ns:dsfHost-1.0" XML namespace. 173 "dsfContact-1.0" is used as an abbreviation for 174 "urn:ietf:params:xml:ns:dsfContact-1.0". 175 "dsfContact" XML namespace prefix refers to 176 "urn:ietf:params:xml:ns:dsfContact-1.0" XML namespace. 177 "dsfVerificationCode-1.0" is used as an abbreviation for 178 "urn:ietf:params:xml:ns:dsfVerificationCode-1.0". 179 "dsfVerificationCode" XML namespace prefix refers to 180 "urn:ietf:params:xml:ns:dsfVerificationCode-1.0" XML namespace. 181 "dsfRouting-1.0" is used as an abbreviation for 182 "urn:ietf:params:xml:ns:dsfRouting-1.0". 184 Implementations MUST NOT depend on the XML namespace prefix used in 185 this document and instead MUST employ a proper namespace-aware XML 186 parser and serializer to interpret and output the XML. 188 2. General Conventions 190 This document includes a general set of attributes and terms that are 191 described here. 193 2.1. Date and Time 195 Numerous fields indicate "dates", such as the creation date of the 196 DSF. These fields SHALL contain timestamps indicating the date and 197 time in UTC as specified in [RFC3339], with no offset from the zero 198 meridian. 200 2.2. Checksum 202 The checksum of the body of the file, as defined by the body rule of 203 the Data Set File (DSF) ABNF (Section 3), MUST use CRC32, that is the 204 algorithm used in the ISO 13239 standard [iso13239] and in section 205 8.1.1.6.2 of ITU-T recommendation V.42 [itu-t-V.42]. 207 2.3. Type and Subtype 209 There can be many different Data Set File (DSF) types supported based 210 on the objects, operations, and the specific scenarios. To make it 211 easier to negotiate the client's intent of the DSF with the server's 212 set of supported DSF files, the DSF supports the definition of a type 213 and an optional sub-type. The supported list of types and sub-types 214 is up to server policy. The server SHOULD provide the possible set 215 of supported DSF type and sub-type values to the parties generating 216 the DSF. The mechanism for providing the supported DSF type and sub- 217 type values is not defined in this document but MAY require 218 registration within an IANA registry. 220 The element formally defines the DSF type, which 221 indicates the expected set of fields defined under the 222 element and the expected operation to be taken. An 223 OPTIONAL "subType" attribute defines the sub-type that is used to 224 further refine the purpose of the DSF. 226 It is recommended that the server follows a consistent naming scheme 227 for the values. One option is to delimit the value 228 with a '.' and to include the object ("domain", "host", "contact, 229 "verificationCode", etc.), the operation ("create", "renew, 230 "transfer", "delete", "update", etc.), and the scoped name of the 231 DSF. For example, to support the bulk update of encoded signed 232 verification codes, the value can be set to 233 "verificationCode.update.encodedSignedCode". To further sub-divide 234 the "verificationCode.update.encodedSignedCode" type by locality, the 235 "subType" attribute can be set to the locality name. For example, 236 the "china" verification profile supports two verification codes of 237 type "domain" and "real-name", so the 238 "verificationCode.update.encodedSignedCode" DSF type can include 239 "china" for the "subType" attribute, as in verificationCode.update.encodedSignedCode. 242 2.4. Fields 244 The element, an element in the header (Section 3.1), 245 contains an ordered list of CSV fields used in the body of the file 246 delimited by the character defined by the OPTIONAL "sep" attribute, 247 with a default value of ",". A field child element substitutes for 248 the abstract element. Each element defines the 249 format of the CSV field contained in the body. The 250 elements support the "type" attribute that defines the XML schema 251 simple type of the field element. 253 The abstract element does not directly define any 254 attributes, but there are a couple attributes that a data set 255 processor SHOULD support including: 257 isRequired When the "isRequired" attribute is "true", it indicates 258 that the field MUST be non-empty in the body and when set to 259 "false", it indicates that the field MAY be empty in the body. 260 The "isRequired" attribute MAY be specifically set for the field 261 elements in the XML schema and MAY be overriden by specifying the 262 attribute in the fields under the element. If 263 no "isRequired" attribute is defined, the default value is 264 "false". 265 isPrimaryKey When the "isPrimaryKey" attribute is "true", it 266 indicates that the field is part of the primary key of the 267 records. The combination of the primary key fields MUST be 268 unique across the set of records in the file. The "isPrimaryKey" 269 attribute MAY be specifically set for the field elements in the 270 XML schema and MAY be overridden by specifying the attribute in 271 the fields under the element. If no 272 "isPrimaryKey" attribute is defined, the default value is 273 "false". 275 2.4.1. Base Field Types 277 New field types can be defined that reside in the CSV records. To 278 make the definition of new field types easier, a set of base field 279 types are defined in the dataSet-1.0 XML schema that include: 281 dataSet:fieldOptionalType The "dataSet:fieldOptionalType" type can 282 be extended by a field that can be empty ("isRequired" = "false") 283 and is not a member of the primary key ("isPrimaryKey" = 284 "false"). 285 dataSet:fieldRequiredType The "dataSet:fieldRequiredType" type can 286 be extended by a field that cannot be empty ("isRequired" = 287 "true") and is not a member of the primary key ("isPrimaryKey" = 288 "false"). 289 dataSet:fieldPrimaryKeyType The "dataSet:fieldPrimaryKeyType" type 290 can be extended by a field that cannot be empty ("isRequired" = 291 "true") and is a member of the primary key ("isPrimaryKey" = 292 "true"). 293 dataSet:fListItemType The "dataSet:fListItemType" type is an 294 extension of the "dataSet:fieldOptionalType" type that adds an 295 OPTIONAL "op" attribute that reflects the operation to apply for 296 the list item. The default "op" value is "replace". The list of 297 possible "op" values is include below. A "dataSet:fListItemType" 298 field with "op" set to "replace" MUST NOT be mixed with a 299 matching "dataSet:fListItemType" field with "op" set to either 300 "add" or "remove". 302 "replace" Specifies that the list item will replace was is 303 currently set for the object. The list of list items 304 provided will replace the existing list of items set on the 305 object. The concrete "dataSet:fListItemType" field along 306 with the DSF type can determine what is the possible set of 307 list item values. 308 "add" Specifies that the list item should be added to the object 309 if it is not already set. 310 "rem" Specifies that the list item should be removed from the 311 object and expects it to already be set. 313 Example definition of the field element that extends 314 the "dataSet:fieldPrimaryKeyType" base field type with the XML type 315 dataSet:labelType and with the required "class" attribute: 317 320 321 322 323 324 326 328 329 330 332 2.4.2. Data Set Field Elements 334 The dataSet-1.0 XML schema predefines a set of field elements that 335 can be used as child elements of the element of the 336 header to define the CSV record fields. The dataSet-1.0 field 337 elements with the XML schema type value and the base type include: 339 Field that represents the name of an object. This 340 field extends a "dataSet:fieldPrimaryKeyType", as defined in 341 Section 2.4.1, with the type="token". The required "class" 342 attribute defines the class of the object, like the use of 343 "domain" for a domain name. It is recommended to use an object 344 specific name field if available, like . 345 Object authorization information with 346 type="eppcom:pwAuthInfoType". 347 Field that represents the result of processing 348 an individual record using the codes defined in Section 5. The 349 field extends a "dataSet:fieldRequiredType", as defined in 350 Section 2.4.1, with the type="dataSet:resultCodeType". 351 Field containing the human-readable description 352 of the result code. The field extends a 353 "dataSet:fieldOptionalType", as defined in Section 2.4.1, with 354 the type="normalizedString". The field includes the OPTIONAL 355 "lang" attribute with the default value of "en" (English). 356 Field containing the human-readable message 357 that describes the reason for the error processing the record. 358 The field extends the "dataSet:fieldOptionalType", as defined in 359 Section 2.4.1, with the type="normalizedString". The language of 360 the reason is identified the OPTIONAL "lang" attribute. If not 361 specified, the default attribute value is "en" (English). 363 Example definition for a result file generated by a 364 server that includes a domain name with a result code, with an 365 OPTIONAL result message, and an OPTIONAL result reason: 367 368 369 370 371 372 374 2.4.2.1. Field Element Extensibility 376 New field elements MAY be defined in separate XML schemas and 377 referenced as child elements of the element. The 378 convention is to prefix all field elements with a lowercase "f", as 379 in for the object name or for 380 the result code. The following are the steps to define a new field 381 element: 383 1. Define a new XML schema or extend an existing XML schema to 384 include the definition of the field element. The XML schema will 385 have it's own XML namespace that will be referenced in the header 386 of the Data Set File (DSF). 387 2. Define a new XML schema complexType that is a direct or indirect 388 extension of the "dataSet:fieldType" complexType. The new 389 complexType MUST directly, or indirectly define through 390 extension, the following attibutes: 392 "type" Defines the XML schema data type of the CSV field. The 393 "default" value of the attribute is used to define the 394 default CSV field type using an XML schema simple data type. 395 Any XML namespaces MUST be escaped ("\:" instead of ":") so 396 the XML parser of the header can ignore the reference during 397 XML validation. The "type" attribute is used during CSV 398 validation leveraging the XML schema simple data type to 399 define the format. The "type" attribute can be overridden 400 when referencing the field element in the header. The "type" 401 attribute for the "dataSet:fResultCodeType" complexType is 402 defined as . When using the default 404 XML namespace, no escaping is necessary. For example for the 405 "dataSet:fResultMsg" complexType, the "type" attribute is 406 defined as . A validator of the Data Set 408 File (DSF) will apply the XML schema type to the CSV fields. 409 "isRequired" See the definition of the "isRequired" attribute in 410 Section 2.4. A required field can extend the 411 "dataSet:fieldRequiredType" complexType, as defined in 412 Section 2.4.1, or can explicitly specify the attribute. For 413 example, the "isRequired" attribute is set in the 414 "dataSet:fieldRequiredType" complexType as . 416 "isPrimaryKey" See the definition of the "isPrimaryKey" 417 attribute in Section 2.4. A primary key field can extend the 418 "dataSet:primaryKeyType" complexType, as defined in 419 Section 2.4.1, or can explicitly specify the attribute. For 420 example, the "isPrimaryKey" attribute is set in the 421 "dataSet:fieldPrimaryKeyType" complexType as . 423 3. Define the field element that uses the new complexType defined 424 above and that substitutes for the "dataSet:field" abstract 425 element. An example of defining the "dataSet:fResultCode" field 426 element is . 429 An example of defining the "dataSet:fResultReason" field element 430 is . 433 Example definition of the field element that is 434 required to be non-empty and with the CSV field type 435 "dataSet:resultCodeType": 437 441 442 443 444 445 447 448 449 451 Example definition of the field element that may 452 be empty (optional), with the CSV field type "normalizedString", and 453 with the additional optional "lang" attribute: 455 459 460 461 462 463 465 467 468 469 471 2.5. Routing 473 A Data Set File (DSF) MAY include data that targets multiple 474 independent backend services, but the object alone cannot be used to 475 determine the appropropriate backend service. An example is creating 476 a Contact Object (Section 4.3) in the .EXAMPLE1 domain registry 477 service and creating another Contact Object (Section 4.3) in the 478 .EXAMPLE2 domain registry service within a single DSF, where 479 .EXAMPLE1 and .EXAMPLE2 are independent domain registry services. 480 The Data Set File (DSF) processor MAY coordinate with the backend 481 services to process each of the DSF records, but it is dependent on 482 the client to specify the target backend service with each record. 484 The Data Set File (DSF) field element used for routing a record to a 485 specific backend service includes: 487 Contains the unique sub-product name of a 488 backend service with type="token". It is up to server policy on 489 the valid list of sub-product values. An example of a sub- 490 product value is the Top Level Domain (TLD) of a domain registry 491 service. 493 Routing is most applicable to objects like a Contact Object 494 (Section 4.3) and a Host Object (Section 4.2), where the keys 495 ( for the Contact Object and for the 496 Host Object) MAY NOT be enough to uniqually identify a target domain 497 registry service. An example of using the 498 field for routing is provided with the "contact.create.routing" DSF 499 in Section 4.3. 501 3. Data Set File (DSF) Format 503 The Data Set File (DSF) format supports multiple types of requests 504 and response files. All of these types of files support a general 505 file format that includes a header that provides meta-data about the 506 data including the what, who, when, and optionally the digital 507 signature of the information, and the body containing the data. The 508 Data Set File (DSF) syntax is specified using Augmented Backus-Naur 509 Form (ABNF) grammar [RFC5234] as follows: 511 Data Set File (DSF) ABNF 513 file = header body 514 header = dataSet-1-0 LF 515 dataSet-1-0 = 1*(1*VCHAR LF) ; compliant to dataSet-1.0 516 body = start [data] end 517 start = "-----BEGIN DATA SET-----" LF 518 data = 1*VCHAR LF ; CSV compliant 519 end = "-----END DATA SET-----" *1LF 521 3.1. Header Format 523 The header of the Data Set File (DSF) is an XML document that 524 complies with the dataSet-1.0 XML schema. The purpose of the header 525 is to provide the meta-data about the data contained in the body. 526 The element is the root XML element of the 527 header and contains the following child element: 529 ; or or 530 532 Provides meta-data about the body of the file 533 that is not digitally signed, as described in Section 3.1.1. 534 Contains the encoded form of the 535 digitally signed element, as 536 described in in Section 3.1.2. 537 Provides the high level result data with 538 the processing of a request Data Set File (DSF) by the 539 server, as described in Section 3.1.3. 541 3.1.1. element 543 The element contains the meta-data of the body of 544 the file that is not digitally signed. The element 545 contains the following child elements: 547 The type value and OPTIONAL "subType" attribute value 548 of the Data Set File (DSF), as defined in Section 2.3. 549 Ordered list of CSV fields as defined in 550 Section 2.4. 551 OPTIONAL unique identifier of the Data Set File 552 (DSF). The client SHOULD assign a unique identifer when 553 generating the Data Set File (DSF) and set it in the 554 element. 555 Contains the date and time of the Data Set File 556 (DSF) creation. 558 Example element for setting verification codes on a 559 domain name: 561 562 563 564 verificationCode.update.encodedSignedCode 565 566 567 568 569 570 abc-123 571 2016-04-03T22:00:00.0Z 572 574 3.1.2. element 576 The element contains the encoded form 577 of the digitally signed element, described in 578 Section 3.1.2.1, with the encoding defined by the "encoding" 579 attribute with the default "encoding" value of "base64". The 580 "base64" encoded text of the element MUST 581 conform to [RFC2045]. 583 Example element, where "..." 584 represents continuation of data for brevity: 586 587 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 588 ... 589 b25Db2RlOnNpZ25lZENvZGU+Cg== 590 592 3.1.2.1. Signed Definition Data 594 The Signed Definition Data, represented by the 595 element, is a signed extension of the 596 element, defined in Section 3.1.1. The 597 provides the meta-data about the body of the 598 file, that is a fragment of XML that is digitally signed using XML 599 Signature [W3C.CR-xmldsig-core2-20120124]. The 600 element includes a required "id" attribute of 601 type XSD ID for use with the IDREF URI from the Signature element. 602 Setting the "id" attribute value to "signedData" is recommended. The 603 certificate of the issuer MUST be included with the Signature so it 604 can be chained with the issuer's certificate by the validating 605 client. A checksum, as defined by the Section 2.2, of the body of 606 the file, as defined by the body rule of the Data Set File (DSF) 607 ABNF, is included in the digitally signed data to ensure that it's 608 covered by the Signature. The element 609 contains the following child elements: 611 The type value and OPTIONAL "subType" attribute value 612 of the Data Set File (DSF), as defined in Section 2.3. 613 Ordered list of CSV fields as defined in 614 Section 2.4. 615 OPTIONAL unique identifier of the data set. The 616 source SHOULD assign a unique identifer when generating the data 617 set and set it in the element. 618 Contains the date and time of the data set 619 creation. 620 Checksum of the body of the file, as defined by the 621 body rule of the Data Set File (DSF) ABNF, using the mechanism 622 defined by the Section 2.2. 623 XML Signature [W3C.CR-xmldsig-core2-20120124] for the 624 . Use of a namespace prefix, like "dsig", 625 is recommended for the XML Signature 626 [W3C.CR-xmldsig-core2-20120124] elements. 628 Example element, where "..." represents 629 continuation of data for brevity: 631 639 640 verificationCode.update.encodedSignedCode 641 642 643 644 645 646 647 abc-123 648 2016-04-03T22:00:00.0Z 649 6F2B988F 650 651 652 654 656 657 658 660 661 663 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 664 665 666 667 668 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 669 ... 670 ipJsXNa6osTUw1CzA7jfwA== 671 672 673 674 675 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 676 ... 677 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 678 679 680 681 682 684 3.1.3. element 686 The element contains the high level result data 687 with the processing of a request Data Set File (DSF) by the server. 688 the "code" attribute describes the success or failure of the 689 processing using the code values defined in Section 5. The 690 element contains the following child elements: 692 OPTIONAL type value and OPTIONAL "subType" attribute 693 value associaed with the request Data Set File (DSF), as defined 694 in Section 2.3. The element MUST be returned if 695 the request header is successfully parsed. 696 OPTIONAL ordered list of CSV fields as defined in 697 Section 2.4. If the element is not defined, 698 then the data as defined by the data rule of the Data Set File 699 (DSF) ABNF MUST be empty. 700 OPTIONAL identifier of the Data Set File (DSF) 701 formed using the element associated with the 702 request if supplied by the client and the request header is 703 successfully parsed. 704 Human-readable description of the result code. The 705 language of the result is identified via an OPTIONAL "lang" 706 attribute. If not specified, the default attribute value is "en" 707 (English). 708 OPTIONAL human-readable message that describes the 709 reason for the error. The language of the reason is identified 710 via an OPTIONAL "lang" attribute. If not specified, the default 711 attribute value is "en" (English). 712 OPTIONAL summary record result data. The summary 713 data is associated with the count of the records (lines in 714 request data). The element contains the 715 following child elements: 717 Total count of the records (lines in request 718 data) processed by the server. 719 Total count of the records (lines in request 720 data) successfully processed by the server. 721 Total count of the records (lines in request 722 data) that failed processing by the server. 724 Example successful element: 726 727 728 verificationCode.update.encodedSignedCode 729 730 731 732 733 734 735 736 abc-123 737 54322-XYZ 738 Code Set processed successfully. 739 740 2 741 2 742 0 743 744 745 Example element with some failures: 747 748 749 verificationCode.update.encodedSignedCode 750 751 752 753 754 755 756 757 abc-123 758 54322-XYZ 759 Success with failures 760 761 4 762 1 763 3 764 765 767 Example failed element based on malformed 768 request file: 770 771 54322-XYZ 772 File syntax error 773 Malformed request file 774 775 777 Example failed element based on header syntax 778 error: 780 781 54322-XYZ 782 Header syntax error 783 Header XML syntax error 784 785 786 Example failed element based on body syntax 787 error: 789 790 791 verificationCode.update.encodedSignedCode 792 793 abc-123 794 54322-XYZ 795 Body syntax error 796 Invalid with fields definition 797 798 800 3.2. Body Format 802 The body of the Data Set File (DSF) is a set of Comma-Separated 803 Values (CSV) data that includes a leading "-----BEGIN CODE SET-----" 804 line and a trailing "-----END CODE SET-----" line. The format of the 805 CSV data is defined by the element in the header 806 (Section 3.1), that includes the delimiter and the ordered set of 807 fields (Section 2.4) with their XML simple type and descriptor 808 attributes like "isRequired", "isPrimaryKey", "class", and 809 "codeType". 811 Example body for a result file generated by a server that includes a 812 success and a set of failed records with a mix of messages and 813 reasons.: 815 -----BEGIN DATA SET----- 816 domain1.example,1000,Success, 817 domain2.example,2303,Object does not exist, 818 domain3.example,2201,Authorization error, 819 domain4.example,2302,Object exists,domain code already 820 -----END DATA SET----- 822 4. Object Description 824 This section describes the base objects supported by this 825 specification: 827 4.1. Domain Name Object 829 The domain name object is based on the EPP domain name mapping 830 specified in [RFC5731]. 832 The Data Set File (DSF) field elements specific to the domain name 833 object include: 835 Domain name field with type="eppcom:labelType" and 836 isRequired="true". 837 Domain name initial or extension period of the 838 expiration date with type="domain:pLimitType". 839 Domain name initial or extension period unit 840 of the expiration date with type="domain:pUnitType". 841 Domain name server is an extension of the 842 "dataSet:fListItemType" field, described in Section 2.4.1, with 843 type="eppcom:labelType". 844 Domain contact identifer with 845 type="eppcom:clIDType" and with required "role" attribute. The 846 possible values of the "role" attribute include "registrant", 847 "admin", "tech", and "billing". 848 The status of the domain name is an extension of 849 the "dataSet:fListItemType" field, described in Section 2.4.1, 850 with type="domain:statusValueType". 851 Contains the DS key tag value per [RFC5910] with 852 type="unsignedShort". 853 Contains the DS algorithm value per [RFC5910] 854 with type="unsignedByte". 855 Contains the DS digest type value per 856 [RFC5910] with type="unsignedByte". 857 Contains the DS digest value per [RFC5910] with 858 type="hexBinary". 859 Contains the flags field value per [RFC5910] with 860 type="unsignedShort". 861 Contains the Key protocol value per [RFC5910] 862 with type="unsignedByte". 863 Contains the Key algorithm value per [RFC5910] 864 with type="unsignedByte". 865 Contains the public key value per [RFC5910] with 866 type="secDNS:keyType". 867 Indicates a child's preference for the 868 number of seconds after signature generation when the parent's 869 signature on the DS information provided by the child will expire 870 with type="secDNS:maxSigLifeType" defined in [RFC5910]. 872 The following are example DSF files using the domain object fields. 873 The different forms of domain object DSF files is up to server 874 policy. 876 Example of a "domain.update.replaceClientStatuses" DSF that will set 877 the client statuses of a domain name to those specified in the DSF 878 record. The client statuses set will be replaced by the set of 879 client statuses specified. Empty statuses will result in the removal 880 of those statuses if previously set. Non-empty statuses will be 881 added if not previously set. Non-empty statuses will result in no 882 change if previously set. All five client statuses defined in 883 [RFC5731] are defined in the DSF in fixed order. 885 886 891 892 893 domain.update.replaceClientStatuses 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 abc-123 909 2016-04-03T22:00:00.0Z 910 911 912 -----BEGIN DATA SET----- 913 domain1.example,clientDeleteProhibited,,,,clientUpdateProhibited 914 domain2.example,,clientHold,,, 915 domain3.example,,,clientRenewProhibited,clientTransferProhibited, 916 domain4.example,,,,, 917 -----END DATA SET----- 918 Example of a "domain.update.addRemoveStatus" DSF that will add a 919 status and remove a status for each domain name. Any status can be 920 empty to indicate no action for that domain name. 922 923 928 929 930 domain.update.addRemoveNs 931 932 933 934 935 936 937 abc-123 938 2016-04-03T22:00:00.0Z 939 940 941 -----BEGIN DATA SET----- 942 domain1.example,ns1.domain1.example,n2.domain1.example 943 domain2.example,ns1.domain1.example, 944 domain3.example,,ns2.domain1.example 945 -----END DATA SET----- 946 Example of a "domain.update.replaceNs" DSF that will set the name 947 servers of a domain name to those specified in the DSF record. The 948 server supports setting up to 13 name servers to a domain name, so 949 there are 13 defined. All existing name servers set 950 will be replaced with the name servers specified. 952 953 958 959 960 domain.update.replaceNs 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 abc-123 979 2016-04-03T22:00:00.0Z 980 981 982 -----BEGIN DATA SET----- 983 domain1.example,ns1.domain1.example,n2.domain1.example,,,,,,,,,,, 984 domain2.example,ns1.domain1.example,,,,,,,,,,,, 985 domain3.example,,,,,,,,,,,,, 986 -----END DATA SET----- 987 Example of a "domain.update.addRemoveNs" DSF that will add a name 988 server and remove a name server for each domain name. Any name 989 server can be empty to indicate no action for that domain name. 991 992 997 998 999 domain.update.addRemoveNs 1000 1001 1002 1003 1004 1005 1006 abc-123 1007 2016-04-03T22:00:00.0Z 1008 1009 1010 -----BEGIN DATA SET----- 1011 domain1.example,ns1.domain1.example,n2.domain1.example 1012 domain2.example,ns1.domain1.example, 1013 domain3.example,,ns2.domain1.example 1014 -----END DATA SET----- 1015 Example of a "domain.update.contacts" DSF that supports updating the 1016 contacts (registrant, admin, tech, and billing) for each domain name. 1017 All four contacts fields are set as required using the "isRequired" 1018 attribute and any existing contacts set for each domain name are 1019 replaced. 1021 1022 1027 1028 1029 domain.update.contacts 1030 1031 1032 1033 1034 1035 1036 1037 1038 abc-123 1039 2016-04-03T22:00:00.0Z 1040 1041 1042 -----BEGIN DATA SET----- 1043 domain1.example,jd1234,sh813,sh813,sh813 1044 domain2.example,jd1234,sh813,sh813, 1045 -----END DATA SET----- 1046 Example of a "domain.create.standard" DSF that supports creating each 1047 domain name record with a standard set of fields / attributes for a 1048 thick domain name. 1050 1051 1056 1057 1058 domain.create.standard 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 abc-123 1072 2016-04-03T22:00:00.0Z 1073 1074 1075 -----BEGIN DATA SET----- 1076 domain1.example,1,ns1.dom.example,,jd1234,sh813,sh813,sh813,2fooBAR 1077 domain2.example,1,,,jd1234,sh813,sh813,sh813,2fooBAR 1078 -----END DATA SET----- 1080 4.2. Host Object 1082 The host object is based on the EPP host mapping specified in 1083 [RFC5732]. 1085 The Data Set File (DSF) field elements specific to the host object 1086 include: 1088 Host name field with type="eppcom:labelType" and 1089 isRequired="true". 1090 Host new name field used to rename the host with 1091 type="eppcom:labelType". 1092 The address version ("v4" or "v6") is an 1093 extension of the "dataSet:fListItemType" field, described in 1094 Section 2.4.1, with type="eppcom:addrStringType". The 1095 "dsfHost.fAddrVersion" field usually corresponds with a following 1096 "dsfHost:fAddr" field. The "dsfHost:fAddrVersion" and 1097 "dsfHost.fAddr" fields are included in pairs. 1098 The address is an extension of the 1099 "dataSet:fListItemType" field, described in Section 2.4.1, with 1100 type="eppcom:addrStringType". The "dsfHost.fAddr" field usually 1101 corresponds with a previous "dsfHost:fAddrVersion" field that 1102 defines the type of address. The "dsfHost:fAddrVersion" and 1103 "dsfHost.fAddr" fields are included in pairs. 1104 The status of the host is an extension of the 1105 "dataSet:fListItemType" field, described in Section 2.4.1, with 1106 type="host:statusValueType". 1108 The following are example DSF files using the host object fields. 1109 The different forms of host object DSF files is up to server policy. 1111 Example of a "host.update.replaceClientStatuses" DSF that will set 1112 the client statuses of a host to those specified in the DSF record. 1113 The client statuses set will be replaced by the set of client 1114 statuses specified. Empty statuses will result in the removal of 1115 those statuses if previously set. Non-empty statuses will be added 1116 if not previously set. Non-empty statuses will result in no change 1117 if previously set. All two client statuses defined in [RFC5732] are 1118 defined in the DSF in fixed order. 1120 1121 1126 1127 1128 host.update.replaceClientStatuses 1129 1130 1131 1132 1133 1134 1135 1136 1137 abc-123 1138 2016-04-03T22:00:00.0Z 1139 1140 1141 -----BEGIN DATA SET----- 1142 ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited 1143 ns2.domain.example,,clientUpdateProhibited 1144 ns3.domain.example,clientDeleteProhibited, 1145 ns4.domain.example,, 1146 -----END DATA SET----- 1147 Example of a "host.update.addRemoveStatus" DSF that will add a status 1148 and remove a status for each host. Any status can be empty to 1149 indicate no action for that host. 1151 1152 1157 1158 1159 host.update.addRemoveClientStatuses 1160 1161 1162 1163 1164 1165 1166 abc-123 1167 2016-04-03T22:00:00.0Z 1168 1169 1170 -----BEGIN DATA SET----- 1171 ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited 1172 ns2.domain.example,,clientUpdateProhibited 1173 ns3.domain.example,clientUpdateProhibited, 1174 -----END DATA SET----- 1175 Example of a "host.update.replaceAddr" DSF that will set the 1176 addresses of a host to those specified in the DSF record. The server 1177 supports setting up to 6 addresses to a host, so there are 6 1178 and field pairs defined. All 1179 existing addresses set will be replaced with the addresses specified. 1181 1182 1187 1188 1189 host.update.replaceAddr 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 abc-123 1207 2016-04-03T22:00:00.0Z 1208 1209 1210 -----BEGIN DATA SET----- 1211 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29,,,,,,,, 1212 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,,,,,,,,,, 1213 ns3.domain.example,,,,,,,,,,,, 1214 -----END DATA SET----- 1215 Example of a "host.update.addRemoveAddr" DSF that will add an address 1216 and remove an address for each host. Any address can be empty to 1217 indicate no action for that host. The and 1218 field pairs are provided with matching list 1219 operations. 1221 1222 1227 1228 1229 host.update.addRemoveAddr 1230 1231 1232 1233 1234 1235 1236 1237 1238 abc-123 1239 2016-04-03T22:00:00.0Z 1240 1241 1242 -----BEGIN DATA SET----- 1243 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29 1244 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,, 1245 ns3.domain.example,,v4,192.0.2.29 1246 -----END DATA SET----- 1247 Example of a "host.create.standard" DSF that supports creating each 1248 host record with a standard set of fields / attributes for a host. 1249 There is an example of creating an internal host (ns1.domain.example 1250 and ns2.domain.example) with up to two addresses and an external host 1251 (ns1.domain.external) without addresses. 1253 1254 1259 1260 1261 host.create.standard 1262 1263 1264 1265 1266 1267 1268 1269 1270 abc-123 1271 2016-04-03T22:00:00.0Z 1272 1273 1274 -----BEGIN DATA SET----- 1275 ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29 1276 ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A, 1277 ns1.domain.external,,,, 1278 -----END DATA SET----- 1280 4.3. Contact Object 1282 The contact object is based on the EPP host mapping specified in 1283 [RFC5733]. 1285 Some elements MAY be provided in either internationalized form 1286 ("int") or provided in localized form ("loc"). Those elements use a 1287 field value or "isLoc" attribute to specify the form used. If an 1288 "isLoc" attribute is used, a value of "true" indicates the use of the 1289 localized form and a value of "false" indicates the use of the 1290 internationalized form. This MAY override the form specified for a 1291 parent element. A value of "int" is used to indicate the 1292 internationalized form and a value of "loc" is used to indicate the 1293 localized form. When the internalized form ("int") is provided, the 1294 field value MUST be represented in a subset of UTF-8 that can be 1295 represented in the 7-bit US-ASCII character set. When the localized 1296 form ("loc") is provided, the field value MAY be represented in 1297 unrestricted UTF-8. Some of the contact field elements specify the 1298 internationalized form with the isLoc="false" attribute. 1300 The Data Set File (DSF) field elements specific to the contact object 1301 include: 1303 Contains the server-unique contact identifier with 1304 type="eppcom:clIDType" and isRequired="true". 1305 Contains the contact's email address with 1306 type="eppcom:minTokenType" and isRequired="true". 1307 Contains the contact's voice telephone number 1308 with type="contact:e164StringType". 1309 Contains the contact's voice telephone number 1310 extension with type="token". 1311 Contains the contact's facsimile telephone number 1312 with type="contact:e164StringType". 1313 Contains the contact's facsimile telephone 1314 number extension with type="token". 1315 Contains the contact's name of the individual or 1316 role represented by the contact with 1317 type="contact:postalLineType" and isRequired="true". An OPTIONAL 1318 "isLoc" attribute to used to indicate the localized or 1319 internationalized form. 1320 Contains the contact's contact's street address 1321 line with type="contact:fPostalLineType". An index attribute is 1322 required to indicate which street address line the field 1323 represents with index "0" for the first line and index "2" for 1324 the last line. An OPTIONAL "isLoc" attribute to used to indicate 1325 the localized or internationalized form. 1326 Contains the contact's city with 1327 type="contact:postalLineType" and isRequired="true". An OPTIONAL 1328 "isLoc" attribute to used to indicate the localized or 1329 internationalized form. 1330 Contains the contact's country code with 1331 type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" 1332 attribute to used to indicate the localized or internationalized 1333 form. 1334 Contains the form of the postal-address 1335 information with type="contact:postalLineType". This field 1336 specifies the form ("int" or "loc") of the , 1337 , , , 1338 , , fields. 1339 Contains the name of the organization with which 1340 the contact is affiliated with type="contact:optPostalLineType". 1341 An OPTIONAL "isLoc" attribute to used to indicate the localized 1342 or internationalized form. 1344 Contains the contact's state or province with 1345 type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute 1346 to used to indicate the localized or internationalized form. 1347 Contains the contact's postal code with 1348 type="contact:pcType". An OPTIONAL "isLoc" attribute to used to 1349 indicate the localized or internationalized form. 1350 Contains flag with a value of "true" or 1351 "1" (one) notes the preference to allow disclosure of the 1352 specified elements as an exception to the stated data-collection 1353 policy. A value of "false" or "0" (zero) notes a client 1354 preference to not allow disclosure of the specified elements as 1355 an exception to the stated data-collection policy with 1356 type="boolean". The additional fields define specific 1357 exceptional disclosure preferences based on the 1358 field. 1359 Exceptional disclosure preference flag 1360 for the localized form of the contact name with type="boolean". 1361 Exceptional disclosure preference flag 1362 for the internationalized form of the contact name with 1363 type="boolean". 1364 Exceptional disclosure preference flag 1365 for the localized form of the contact organization with 1366 type="boolean". with type="boolean". 1367 Exceptional disclosure preference flag 1368 for the internationalized form of the contact organization with 1369 type="boolean". with type="boolean". 1370 Exceptional disclosure preference flag 1371 for the localized form of the contact address with 1372 type="boolean". 1373 Exceptional disclosure preference flag 1374 for the internationalized form of the contact address with 1375 type="boolean". 1376 Exceptional disclosure preference flag 1377 of the contact voice telephone number with type="boolean". 1378 Exceptional disclosure preference flag of 1379 the contact facsimile telephone number with type="boolean". 1380 Exceptional disclosure preference flag 1381 of the contact email address with type="boolean". 1382 Exceptional disclosure preference flag of 1383 all of the supported disclose fields with type="boolean". This 1384 single field represents the field 1385 value for all of the disclose fields, that include 1386 , , 1387 , , 1388 , , 1389 , , and 1390 . 1392 The following are example DSF files using the contact object fields. 1393 The different forms of contact object DSF files is up to server 1394 policy. 1396 Example of a "contact.update.replaceClientStatuses" DSF that will set 1397 the client statuses of a contact to those specified in the DSF 1398 record. The client statuses set will be replaced by the set of 1399 client statuses specified. Empty statuses will result in the removal 1400 of those statuses if previously set. Non-empty statuses will be 1401 added if not previously set. Non-empty statuses will result in no 1402 change if previously set. All three client statuses defined in 1403 [RFC5733] are defined in the DSF in fixed order. 1405 1406 1411 1412 1413 contact.update.replaceClientStatuses 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 abc-123 1425 2016-04-03T22:00:00.0Z 1426 1427 1428 -----BEGIN DATA SET----- 1429 sh1111,clientDeleteProhibited,,clientUpdateProhibited 1430 sh2222,,clientUpdateProhibited 1431 sh3333,,clientTransferProhibited, 1432 sh4444,,, 1433 -----END DATA SET----- 1434 Example of a "contact.update.addRemoveStatus" DSF that will add a 1435 status and remove a status for each contact. Any status can be empty 1436 to indicate no action for that contact. 1438 1439 1444 1445 1446 contact.update.addRemoveClientStatuses 1447 1448 1449 1450 1451 1452 1453 abc-123 1454 2016-04-03T22:00:00.0Z 1455 1456 1457 -----BEGIN DATA SET----- 1458 sh1111,clientDeleteProhibited,clientUpdateProhibited 1459 sh2222,,clientUpdateProhibited 1460 sh3333,clientUpdateProhibited, 1461 sh4444,clientTransferProhibited, 1462 -----END DATA SET----- 1464 Example of a "contact.create.standard" DSF that supports creating 1465 each contact record with a standard set of fields / attributes for a 1466 contact. A "|" character is used as a separator to minimize 1467 conflicting with the contact data. This is an example of creating 1468 two contacts, where indented data set lines are a continuation from 1469 the prior line. 1471 1472 1477 1478 1479 contact.create.standard 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 abc-123 1501 2016-04-03T22:00:00.0Z 1502 1503 1504 -----BEGIN DATA SET----- 1505 sh1111|int|John Doe|Example Inc.| 1506 123 Example Dr.|||Dulles|VA|20166-6503|US| 1507 +1.7035555555|1234|+1.7035555556|| 1508 johndoe@example.com|2fooBAR 1509 sh2222|int|Jane Doe|Example Inc.| 1510 123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US| 1511 +1.7035555555|||| 1512 janedoe@example.com|2fooBAR 1513 -----END DATA SET----- 1515 Example of a "contact.create.routing" DSF that extends the 1516 "contact.create.standard" DSF with the field 1517 (Section 2.5) to route the create to the appropriate Top Level Domain 1518 (TLD) or group of TLDs. A "|" character is used as a separator to 1519 minimize conflicting with the contact data. This is an example of 1520 creating two contacts, where indented data set lines are a 1521 continuation from the prior line. 1523 1524 1531 1532 1533 contact.create.routing 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 abc-123 1556 2016-04-03T22:00:00.0Z 1557 1558 1559 -----BEGIN DATA SET----- 1560 EXAMPLE|sh1111|int|John Doe|Example Inc.| 1561 123 Example Dr.|||Dulles|VA|20166-6503|US| 1562 +1.7035555555|1234|+1.7035555556|| 1563 johndoe@example.com|2fooBAR 1564 EXAMPLE|sh2222|int|Jane Doe|Example Inc.| 1565 123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US| 1566 +1.7035555555|||| 1567 janedoe@example.com|2fooBAR 1568 -----END DATA SET----- 1570 4.4. Verification Code Object 1572 The Verification Code Object is defined in the Verification Code 1573 Extension for the Extensible Provisioning Protocol 1574 [I-D.gould-eppext-verificationcode]. This section defines the 1575 Verification Code specific Data Set File (DSF) field elements and 1576 sample DSF files used to set verification codes with a bulk update. 1578 The Verification Service Provider (VSP) is a certified party to 1579 verify that data is in compliance with the policies of a locality. A 1580 locality MAY require the client to have data verified in accordance 1581 with local regulations or laws utilizing data sources not available 1582 to the server. The VSP has access to the local data sources and is 1583 authorized to verify the data. Examples include verifying that the 1584 domain name is not prohibited and verifying that the domain name 1585 registrant is a valid individual, organization, or business in the 1586 locality. The data verified, and the objects and operations that 1587 require the verification code to be passed to the server is up to the 1588 policies of the locality. The verification code represents a marker 1589 that the verification was completed. The data verified by the VSP 1590 MUST be stored by the VSP along with the generated verification codes 1591 in order to address any compliance issues. The signer certificate 1592 and the digital signature of the verification code MUST be verified 1593 by the server. 1595 The Data Set File (DSF) field elements specific to the Verification 1596 Code Object include: 1598 dsfVerificationCode:fCode Field that represents a Verification Code 1599 Token value. The field extends a "dataSet:fieldOptionalType", as 1600 defined in Section 2.4.1, with the 1601 type="dataSet:verificationCodeValueType". The field includes the 1602 required "codeType" attribute that represents the type of 1603 verification code, as defined by the "type" attribute of the 1604 element in 1605 [I-D.gould-eppext-verificationcode]. The verification code field 1606 can be empty since it is a "dataSet:fieldOptionalType". 1607 dsfVerificationCode:fEncodedSignedCode Field that represents a 1608 Encoded Signed Code. The field extends a 1609 "dataSet:fieldOptionalType", as defined in Section 2.4.1, with 1610 the type="token". The field includes the OPTIONAL "encoding" 1611 attribute with the default value of "base64". The line breaks, 1612 defined in [RFC2045], MUST NOT be used with the "base64" Encoded 1613 Signed Code. 1615 The Data Set File (DSF) used for setting of the verification codes 1616 MAY include fields from other objects and the fields specific to the 1617 Verification Code Object. There are two scenarios in passing the 1618 verification codes based on who generates the DSF file, which 1619 includes: 1621 VSP Generated DSF The VSP generates the Verification Code Token 1622 values, represented with the field, 1623 and digitally signs the DSF file by referencing the 1624 element in the DSF header. 1625 Client Generated DSF The client generates the DSF file with a set of 1626 encoded signed codes, represented with the 1627 field, collected from 1628 the VSP to bulk submit them to the server. The 1629 element, described in Section 3.1.1, is referenced in the DSF 1630 header. 1632 The following examples reference verification codes supported by the 1633 China Locality, which includes the Domain Name Verification Code 1634 (DNVC) and the Real Name Verification Code (RNVC). Both China 1635 Locality verification codes are set on a domain name with the 1636 verification code type of "domain" used for the DNVC and the 1637 verification code type of "real-name" used for the RNVC. Other 1638 localities MAY include a different set of verification codes. 1640 Example VSP Generated DSF that includes a domain name primary key 1641 field, a "domain" code token value field, and a "real-name" token 1642 value field. The "base64" value includes "..." representing 1643 continuation of data for brevity: 1645 1646 1649 1650 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 1651 ... 1652 b25Db2RlOnNpZ25lZENvZGU+Cg== 1653 1654 1655 -----BEGIN DATA SET----- 1656 domain1.example,0-abc111,0-abc222 1657 domain2.example,0-abc333,0-abc444 1658 domain3.example,0-abc555, 1659 domain3.example,,0-abc666 1660 -----END DATA SET----- 1661 Example Client Generated Data Set File (DSF) that includes a domain 1662 name primary key field, a "domain" encoded signed code field, and a 1663 "real-name" encoded signed code field. The "base64" values include 1664 no line breaks and include "..." representing continuation of data 1665 for brevity: 1667 1668 1676 1677 1678 verificationCode.update.encodedSignedCode 1679 1680 1681 1682 1683 1684 1685 abc-123 1686 2016-04-03T22:00:00.0Z 1687 1688 1689 -----BEGIN DATA SET----- 1690 domain1.example,ICAg...GlvbkN,CAgICA...uOmlldG 1691 domain2.example,YW1zOb2R...GlvbkNvZGU6c2ln, 1692 domain3.example,,CAgICAnZ...htbDpZmljYXMCIKI 1693 -----END DATA SET----- 1695 5. Result Codes 1697 The result codes are based on and not equal to the reply codes 1698 defined in the EPP result codes of [RFC5730]. Four decimal digits 1699 are used to describe the success or failure of the processing of the 1700 Data Set File (DSF) or the processing of an individual record. Each 1701 digit of the result code has specific significance. 1703 The first digit denotes success or failure. The second digit denotes 1704 the result category, such as request syntax or security. The third 1705 and fourth digits provide explicit response detail within each result 1706 category. 1708 There are two values for the first digit of the result code: 1710 1yzz Positive result. The file or record was processed by the 1711 system successfully. Partial successful results MAY be included. 1712 2yzz Negative result. The file or record was not processed 1713 successfully. Partial successful results MAY NOT be included. 1715 The second digit groups responses into one of five specific 1716 categories: 1718 x0zz File or record syntax 1719 x1zz Implementation-specific rules 1720 x2zz Security 1721 x3zz Data Management 1722 x4zz Server System 1724 Successful result codes: 1726 1000 "Success" 1727 This is the result for a successfully processed file when all 1728 records are processed successfully or the result for an 1729 individual record that is successfully processed. 1731 1001 "Success with failures" 1732 This is the result for a successfully processed file when some 1733 records are processed successfully and some records failed. 1735 1002 "Success with all failures" 1736 This is the result for a successfully processed file when all 1737 of the records failed. 1739 Error result codes: 1741 2000 "File syntax error" 1742 This result code occurs when the overall file is syntactically 1743 incorrect. 1745 2001 "Header syntax error" 1746 This result code occurs when the header is syntactically 1747 incorrect. 1749 2002 "Body syntax error" 1750 This result code occurs when the body is syntactically 1751 incorrect. 1753 2003 "Required parameter missing" 1754 This result code occurs when a server receives a request for 1755 which a required parameter has not been provided. 1757 2004 "Parameter value range error" 1758 This result code occurs when a server receives a request whose 1759 value is outside the range of values specified in the protocol. 1761 2005 "Parameter value syntax error" 1762 This result code occurs when a server receives a request whose 1763 value is improperly formed. 1765 2100 "Unimplemented protocol version" 1766 This result code occurs when a server receives a request 1767 version, as defined by the XML namespace of the header, that is 1768 not implemented by the server. 1770 2102 "Unimplemented option" 1771 This result code occurs when a server receives a request that 1772 contains a protocol option that is not implemented by the 1773 server. 1775 2103 "Unimplemented extension" 1776 This result code occurs when a server receives a request that 1777 contains an extension, as defined by the XML namespace used by 1778 a field element extension, that is not implemented by the 1779 server. 1781 2104 "Billing failure" 1782 This result code occurs when a server receives a request that 1783 cannot be completed due to a client-billing failure. 1785 2201 "Authorization error" 1786 This result code occurs when a server receives a request cannot 1787 be execute due to a client-authorization error. 1789 2202 "Invalid authorization information" 1790 This result code occurs when a server receives invalid 1791 authorization information to execute a request. 1793 2302 "Object exists" 1794 This result code occurs when a server receives a request to 1795 create an object that already exists in the repository. 1797 2303 "Object does not exist" 1798 This result code occurs when a server receives a request to 1799 transform an object that does not exist in the repository. 1801 2304 "Object status prohibits operation" 1802 This result code occurs when a server receives a request to 1803 transform an object that cannot be completed due to server 1804 policy or business practices. 1806 2305 "Object association prohibits operation" 1807 This result code occurs when a server receives a request to 1808 transform an object that cannot be completed due to 1809 dependencies to other objects that are associated with the 1810 target object. 1812 2306 "Parameter value policy error" 1813 This result code occurs when a server receives a request that 1814 contains a parameter value that is syntactically valid but 1815 semantically invalid due to local policy. 1817 2307 "Unimplemented object service" 1818 This result code occurs when a server receives a request to 1819 operate on an object that is not supported by the server. 1821 2308 "Data management policy violation" 1822 This result code occurs when a server receives a request whose 1823 execution results in a violation of server data management 1824 policies. 1826 2400 "Request failed" 1827 This result code occurs when a server receives a request that 1828 cannot be executed due to an internal server error that is not 1829 related to the protocol. 1831 The error result codes include some overlap that will require the 1832 server to decide which one to return based on server policy. For 1833 example, a "Header syntax error", represented by the error result 1834 code 2001, may have occured for multiple reasons including a 2003 1835 "Required parameter missing", a 2004 "Parameter value range error", 1836 or a 2005 "Parameter value syntax error". The overlapping reasons 1837 also apply at the record level, where an object may be syntactically 1838 incorrect with a 2005 "Parameter value syntax error", and also be 1839 against server policy with a 2306 "Parameter value policy error". 1840 The server SHOULD attempt to provide the most accurate error result 1841 code to match the error. For example, a syntax error defined by the 1842 protocol SHOULD take precedence over a server policy error. 1844 6. Example Data Set File (DSF) Result Files 1846 This section includes a set of Data Set File (DSF) result examples. 1848 6.1. Example Data Set File (DSF) with Result Data 1850 This section includes example Data Set File (DSF) files that 1851 reference the element, described in 1852 Section 3.1.3, for providing the meta-data about the result file, 1853 along with a set of fields that reference the 1854 field element, described in Section 2.4.2, for including the result 1855 code in processing the domain name record in the request. 1857 Example Data Set File (DSF) for a succesful result by the server: 1859 1860 1865 1866 1867 1868 1869 1870 1871 1872 abc-123 1873 54322-XYZ 1874 Code Set processed successfully. 1875 1876 2 1877 2 1878 0 1879 1880 1881 1882 -----BEGIN DATA SET----- 1883 domain1.example,1000,, 1884 domain2.example,1000,, 1885 -----END DATA SET----- 1886 Example Data Set File (DSF) for a partially successful result by the 1887 server: 1889 1890 1895 1896 1897 1898 1899 1900 1901 1902 abc-123 1903 54322-XYZ 1904 Success with failures 1905 1906 4 1907 1 1908 3 1909 1910 1911 1912 -----BEGIN DATA SET----- 1913 domain1.example,1000,Success, 1914 domain2.example,2303,Object does not exist, 1915 domain3.example,2201,Authorization error, 1916 domain4.example,2302,Object exists,domain code already set 1917 -----END DATA SET----- 1918 Example Data Set File (DSF) for a failure result by the server: 1920 1921 1924 1925 abc-123 1926 54322-XYZ 1927 File syntax error 1928 Malformed request file 1929 1930 1931 1932 -----BEGIN DATA SET----- 1933 -----END DATA SET----- 1935 7. Formal Syntax 1937 Each schema is included in a sub-section, starting with the Data Set 1938 schema and followed by each object schema. 1940 The formal syntax presented here is a complete schema representation 1941 of the object mapping suitable for automated validation of EPP XML 1942 instances. The BEGIN and END tags are not part of the schema; they 1943 are used to note the beginning and ending of the schema for URI 1944 registration purposes. 1946 7.1. Data Set Schema 1948 Data Set schema that represents the base XML schema for the Data Set 1949 File (DSF). 1951 BEGIN 1952 1953 1962 1963 1964 Data Set XML Schema 1965 1967 1969 1972 1975 1976 1977 1978 1980 1982 1984 1985 1986 1988 1989 1990 1991 1992 1993 1994 1996 1997 1998 1999 2000 2001 2002 2004 2005 2006 2007 2009 2011 2013 2016 2017 2019 2020 2021 2022 2023 2024 2025 2026 2028 2029 2032 2033 2034 2035 2036 2038 2039 2040 2041 2042 2043 2045 2046 2047 2048 2051 2054 2057 2059 2061 2065 2068 2069 2071 2073 2074 2075 2076 2077 2078 2079 2081 2082 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 2132 2133 2134 2135 2136 2137 2139 2140 2141 2142 2144 2145 2146 2148 2149 2152 2153 2154 2155 2157 2158 2159 2160 2161 2164 2165 2166 2168 2169 2170 2171 2172 2173 2175 2177 2178 2179 2181 2182 2183 2184 2185 2186 2188 2190 2191 2192 2194 2195 2196 2197 2198 2199 2201 2203 2204 2205 2207 2208 2209 2210 2211 2212 2215 2216 2217 2219 2220 2221 2222 2223 2224 2225 2226 2228 2229 2230 2231 2232 2234 2235 2236 2238 2241 2242 2243 2244 2245 2247 2249 2250 2251 2253 2254 2257 2258 2259 2260 2261 2263 2264 2265 2267 2268 2269 2270 2271 2272 2274 2275 2276 2278 2279 2280 2281 2282 2283 2285 2286 2287 2289 2290 2293 2294 2295 2296 2297 2299 2300 2301 2303 2304 2307 2308 2309 2310 2311 2313 2315 2316 2317 2319 2320 2323 2324 2325 2326 2327 2329 2331 2332 2333 2335 2336 2337 2338 2339 2340 2342 2343 2344 2346 2347 2348 2349 2350 2351 2353 2354 2355 2357 2358 2359 2360 2361 2362 2364 2365 2366 2368 2369 END 2371 7.2. Domain Name Schema 2373 Domain Name Object XML schema that defines the fields specific to the 2374 Domain Name Object. 2376 BEGIN 2377 2379 2388 2391 2393 2395 2397 2400 2401 2402 Domain Name Data Set File (DSF) Object 2403 2404 2406 2407 2410 2411 2414 2415 2416 2417 2418 2420 2421 2422 2424 2425 2428 2429 2430 2431 2432 2434 2435 2436 2438 2439 2442 2443 2444 2445 2446 2449 2451 2452 2453 2455 2456 2457 2458 2459 2460 2461 2462 2464 2465 2468 2469 2470 2471 2472 2474 2475 2476 2478 2480 2481 2483 2484 2485 2486 2487 2489 2490 2491 2493 2494 2497 2498 2501 2502 2505 2506 2509 2510 2513 2514 2517 2518 2521 2522 2524 2525 2526 2527 2528 2530 2531 2532 2534 2535 2538 2539 2540 2541 2542 2543 2546 2547 2548 2550 2553 2554 END 2556 7.3. Host Schema 2558 Host Object XML schema that defines the fields specific to the Host 2559 Object. 2561 BEGIN 2562 2564 2572 2575 2577 2579 2582 2583 2584 Host Name Data Set File (DSF) Object 2585 2586 2588 2589 2592 2593 2596 2597 2598 2599 2600 2602 2603 2604 2606 2607 2610 2611 2612 2613 2614 2616 2617 2618 2620 2621 2623 2624 2625 2626 2627 2629 2630 2631 2633 2634 2637 2638 2639 2640 2641 2642 2644 2645 2646 2648 2651 2652 END 2654 7.4. Contact Schema 2656 Contact Object XML schema that defines the fields specific to the 2657 Contact Object. 2659 BEGIN 2660 2662 2670 2673 2675 2677 2680 2681 2682 Contact Data Set File (DSF) Object 2683 2684 2686 2687 2690 2691 2692 2693 2694 2696 2697 2698 2700 2701 2705 2706 2708 2710 2711 2712 2713 2714 2716 2717 2718 2720 2721 2723 2726 2727 2729 2730 2731 2732 2733 2735 2737 2738 2740 2744 2746 2747 2748 2749 2750 2752 2753 2754 2756 2757 2758 2759 2760 2761 2763 2764 2765 2766 2768 2769 2770 2771 2772 2773 2775 2776 2777 2778 2780 2781 2784 2785 2788 2789 2790 2792 2793 2794 2795 2796 2798 2799 2800 2802 2803 2806 2807 2810 2811 2813 2814 2815 2816 2817 2819 2820 2821 2822 2824 2825 2827 2828 2829 2830 2831 2833 2834 2835 2836 2838 2839 2841 2843 2845 2847 2849 2851 2853 2855 2857 2859 2861 2863 2865 2867 2869 2871 2873 2875 2877 2880 2881 2882 2883 2884 2886 2887 2888 2890 2891 2894 2895 2896 2897 2898 2899 2901 2902 2903 2905 2908 2909 END 2911 7.5. Verification Code Schema 2913 Verification Code Object XML schema that defines the fields specific 2914 to the Verification Code Object. 2916 BEGIN 2917 2918 2927 2928 2929 Verification Code Data Set File (DSF) Object 2930 2931 2933 2936 2937 2939 2940 2941 2942 2943 2945 2946 2947 2948 2950 2951 2952 2953 2954 2955 2957 2958 2961 2962 2963 2964 2965 2967 2969 2970 2971 2973 2974 END 2976 7.6. Routing Schema 2978 Routing XML schema that defines the fields specific to routing. 2980 BEGIN 2981 2982 2991 2992 2993 Routing Data Set File (DSF) Fields 2994 2995 2997 3000 3001 3003 3004 3005 3006 3007 3009 3010 3011 3013 3014 END 3016 8. IANA Considerations 3018 8.1. XML Namespace 3020 This document uses URNs to describe XML namespaces and XML schemas 3021 conforming to a registry mechanism described in [RFC3688]. 3023 Registration request for the dataSet namespace: 3025 URI: ietf:params:xml:ns:dataSet-1.0 3026 Registrant Contact: See the "Author's Address" section of this 3027 document. 3028 XML: None. Namespace URIs do not represent an XML specification. 3030 Registration request for the dataSet XML schema: 3032 URI: ietf:params:xml:ns:dataSet-1.0 3033 Registrant Contact: See the "Author's Address" section of this 3034 document. 3035 XML: See the "Formal Syntax" section of this document. 3037 Registration request for the dsfDomain namespace: 3039 URI: ietf:params:xml:ns:dsfDomain-1.0 3040 Registrant Contact: See the "Author's Address" section of this 3041 document. 3042 XML: None. Namespace URIs do not represent an XML specification. 3044 Registration request for the dsfDomain XML schema: 3046 URI: ietf:params:xml:ns:dsfDomain-1.0 3047 Registrant Contact: See the "Author's Address" section of this 3048 document. 3049 XML: See the "Formal Syntax" section of this document. 3051 Registration request for the dsfHost namespace: 3053 URI: ietf:params:xml:ns:dsfHost-1.0 3054 Registrant Contact: See the "Author's Address" section of this 3055 document. 3056 XML: None. Namespace URIs do not represent an XML specification. 3058 Registration request for the dsfHost XML schema: 3060 URI: ietf:params:xml:ns:dsfHost-1.0 3061 Registrant Contact: See the "Author's Address" section of this 3062 document. 3063 XML: See the "Formal Syntax" section of this document. 3065 Registration request for the dsfContact namespace: 3067 URI: ietf:params:xml:ns:dsfContact-1.0 3068 Registrant Contact: See the "Author's Address" section of this 3069 document. 3070 XML: None. Namespace URIs do not represent an XML specification. 3072 Registration request for the dsfContact XML schema: 3074 URI: ietf:params:xml:ns:dsfContact-1.0 3075 Registrant Contact: See the "Author's Address" section of this 3076 document. 3077 XML: See the "Formal Syntax" section of this document. 3079 Registration request for the dsfVerificationCode namespace: 3081 URI: ietf:params:xml:ns:dsfVerificationCode-1.0 3082 Registrant Contact: See the "Author's Address" section of this 3083 document. 3084 XML: None. Namespace URIs do not represent an XML specification. 3086 Registration request for the dsfVerificationCode XML schema: 3088 URI: ietf:params:xml:ns:dsfVerificationCode-1.0 3089 Registrant Contact: See the "Author's Address" section of this 3090 document. 3091 XML: See the "Formal Syntax" section of this document. 3093 Registration request for the dsfRouting namespace: 3095 URI: ietf:params:xml:ns:dsfRouting-1.0 3096 Registrant Contact: See the "Author's Address" section of this 3097 document. 3098 XML: None. Namespace URIs do not represent an XML specification. 3100 Registration request for the dsfRouting XML schema: 3102 URI: ietf:params:xml:ns:dsfRouting-1.0 3103 Registrant Contact: See the "Author's Address" section of this 3104 document. 3105 XML: See the "Formal Syntax" section of this document. 3107 9. Security Considerations 3109 The data supported by the Data Set File (DSF) format MAY include 3110 information that needs to be protected with the use of a secure 3111 transport. For example, the field provides 3112 object authorization information, and as described in [RFC5731], both 3113 the client and the server MUST ensure that it is stored and exchanged 3114 with high-grade encryption mechanisms. The transport leveraged to 3115 exchange the DSF containing sensitive or secure data MUST protect it 3116 from inadvertent disclosure. 3118 XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this 3119 document to verify that the Data Set originated from a trusted source 3120 and that it wasn't tampered with in transit from the source to the 3121 client to the server. To support multiple source keys, the source 3122 certificate chain MUST be included in the elements 3123 of the Signed Def Data (Section 3.1.2.1) and MUST chain up and be 3124 verified by the server against a set of trusted certificates. 3126 It is RECOMMENDED that signed definition data does not include white- 3127 spaces between the XML elements in order to mitigate risks of 3128 invalidating the digital signature when transferring of signed codes 3129 between applications takes place. 3131 Use of XML canonicalization SHOULD be used when generating the signed 3132 code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing. 3133 The size of the RSA key SHOULD be at least 2048 bits. 3135 10. Normative References 3137 [I-D.gould-eppext-verificationcode] 3138 Gould, J., "Verification Code Extension for the Extensible 3139 Provisioning Protocol (EPP)", draft-gould-eppext- 3140 verificationcode-04 (work in progress), September 2016. 3142 [iso13239] 3143 the International Organization for Standardization, "ISO 3144 13239", December 2007, 3145 . 3148 [itu-t-V.42] 3149 International Telecommunication Union, "ITU-T V.42 Series 3150 V: Data Communication Over the Telephone Network", March 3151 2002, . 3153 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3154 Extensions (MIME) Part One: Format of Internet Message 3155 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 3156 . 3158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3159 Requirement Levels", BCP 14, RFC 2119, 3160 DOI 10.17487/RFC2119, March 1997, 3161 . 3163 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3164 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3165 . 3167 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3168 DOI 10.17487/RFC3688, January 2004, 3169 . 3171 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3172 Specifications: ABNF", STD 68, RFC 5234, 3173 DOI 10.17487/RFC5234, January 2008, 3174 . 3176 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 3177 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 3178 . 3180 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3181 Domain Name Mapping", STD 69, RFC 5731, 3182 DOI 10.17487/RFC5731, August 2009, 3183 . 3185 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3186 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 3187 August 2009, . 3189 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 3190 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 3191 August 2009, . 3193 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 3194 Security Extensions Mapping for the Extensible 3195 Provisioning Protocol (EPP)", RFC 5910, 3196 DOI 10.17487/RFC5910, May 2010, 3197 . 3199 [W3C.CR-xmldsig-core2-20120124] 3200 Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, 3201 J., Solo, D., Datta, P., and F. Hirsch, "XML Signature 3202 Syntax and Processing Version 2.0", World Wide Web 3203 Consortium CR CR-xmldsig-core2-20120124, January 2012, 3204 . 3206 Appendix A. Acknowledgements 3208 The author wishes to acknowledge the work done by Scott Hollenbeck in 3209 the EPP RFC 5730 for providing some of the concepts and text used in 3210 this document. 3212 Special suggestions that have been incorporated into this document 3213 were provided by John Colosi, Deepak Deshpande, Scott Hollenbeck, 3214 Suzy Strier, and Srikanth Veeramachaneni. 3216 Appendix B. Change History 3218 B.1. Change from 00 to 01 3220 1. Fixed the ABNF. 3221 2. Added support for the 1002 "Success with all failures" result 3222 code to indicate that the file was successfully processed but 3223 that all of the records failed. 3224 3. Updated the description for the 1000 "Success" and the 1001 3225 "Success with failures" result codes. 3227 Author's Address 3229 James Gould 3230 VeriSign, Inc. 3231 12061 Bluemont Way 3232 Reston, VA 20190 3233 US 3235 Email: jgould@verisign.com 3236 URI: http://www.verisign.com