idnits 2.17.1 draft-newton-iris-ereg-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1757. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1773), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2004) is 7151 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: '17' is defined on line 1709, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-core-05 == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-beep-05 ** Obsolete normative reference: RFC 3513 (ref. '7') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 3490 (ref. '14') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (ref. '15') (Obsoleted by RFC 5891) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: March 28, 2005 September 27, 2004 6 An ENUM Registry Type for the Internet Registry Information Service 7 draft-newton-iris-ereg-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes an IRIS registry schema for registered ENUM 41 information. The schema extends the necessary query and result 42 operations of IRIS to provide the functional information service 43 needs for syntaxes and results used by ENUM registries. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 49 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 5 50 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 5 51 3.1.1 Query . . . . . . . . . . . . . . 5 52 3.1.2 Query . . . . . . . . . . . . . . . . . 5 53 3.1.3 Query . . . . . . . . . . . . . . . 6 54 3.1.4 Contact Search Group . . . . . . . . . . . . . . . . . 6 55 3.2 Result Derivatives . . . . . . . . . . . . . . . . . . . . 6 56 3.2.1 Privacy Labels . . . . . . . . . . . . . . . . . . . . 7 57 3.2.2 Result . . . . . . . . . . . . . . . . . . . . 8 58 3.2.3 Result . . . . . . . . . . . . . . . . . . . . 10 59 3.2.4 Result . . . . . . . . . . . . . . . . . . . 11 60 3.2.5 . . . . . . . . . . . . . . . 12 61 3.2.6 . . . . . . . . . . . . . . 13 62 3.3 Generic Code Derivatives . . . . . . . . . . . . . . . . . 14 63 3.3.1 . . . . . . . . . . . . . . . . . . . 14 64 3.3.2 . . . . . . . . . . . . . . . . 15 65 3.4 Support for . . . . . . . . . . . . . 15 66 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 16 67 5. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 36 68 5.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 36 69 5.2 Server Authentication . . . . . . . . . . . . . . . . . . 36 70 6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 37 71 6.1 Application Service Label . . . . . . . . . . . . . . . . 37 72 7. Internationalization Considerations . . . . . . . . . . . . . 38 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 74 8.1 XML Namespace URN Registration . . . . . . . . . . . . . . 39 75 8.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 39 76 8.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 39 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 79 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 41 80 10.2 Informative References . . . . . . . . . . . . . . . . . . . 42 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 43 82 A. Contributions and Acknowledgements . . . . . . . . . . . . . . 44 83 Intellectual Property and Copyright Statements . . . . . . . . 45 85 1. Introduction 87 This document describes an IRIS registry schema for registries of 88 ENUM data using an XML Schema [4] derived from and using the IRIS [5] 89 schema. 91 The schema given is this document is specified using the Extensible 92 Markup Language (XML) 1.0 as described in XML [1], XML Schema 93 notation as described in XML_SD [3] and XML_SS [4], and XML 94 Namespaces as described in XML_NS [2]. 96 2. Document Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119 [10]. 102 3. Schema Description 104 IRIS requires the derivation of both query and result elements by a 105 registry schemas. These descriptions follow. 107 References to XML elements with no namespace qualifier are from the 108 schema defined in Section 4. References to elements and attributes 109 with the "iris" XML namespace qualifier are from the schema defined 110 in IRIS [5]. 112 The descriptions contained within this section refer to XML elements 113 and attributes and their relation to the exchange of data within the 114 protocol. These descriptions also contain specifications outside the 115 scope of the formal XML syntax. Therefore, this section will use 116 terms defined by RFC 2119 [10] to describe the specification outside 117 the scope of the formal XML syntax. While reading this section, 118 please reference Section 4 for needed details on the formal XML 119 syntax. 121 3.1 Query Derivatives 123 3.1.1 Query 125 finds ENUMs by searches on fields associated 126 with an ENUM's contact. 128 The allowable search fields are handled with either the 129 element or one of the elements in the 130 "contactSearchGroup" (see Section 3.1.4). The 131 element allows for the ENUMs to be selected based on the contact 132 having the specified contact handle. 134 The query MAY also be constrained further using the optional 135 element. The contents of this element signify the role the contact 136 has with the ENUM. 138 This query also provides optional elements containing 139 language tags. Clients MAY use these elements to give a hint about 140 the natural language(s) of the affected element. Servers MAY use 141 this information in processing the query, such as tailoring 142 normalization routines to aid in more effective searches. 144 3.1.2 Query 146 searches for contacts given search constraints. 148 The allowable search fields are handled by one of the elements in the 149 "contactSearchGroup" (see Section 3.1.4). 151 This query also provides optional elements containing 152 language tags. Clients MAY use these elements to give a hint about 153 the natural language(s) of the affected element. Servers MAY use 154 this information in processing the query, such as tailoring 155 normalization routines to aid in more effective searches. 157 3.1.3 Query 159 This query does a simple search for the ENUMs being hosted by a name 160 server. The search is constrained using either the host name [12], 161 host handle, IPv4 address, or IPv6 address of the name server. 163 3.1.4 Contact Search Group 165 Some of the queries above have similar query constraints for 166 searching on contacts. This section describes those common 167 parameters. 169 allows the query to be constrained based on the common 170 name of the contact. The constraint can either constrain the query 171 by an exact match using the element, or it may constrain 172 the query by a subset of the common name using the and 173 elements. 175 allows the query to be constrained based on the 176 organization name of the contact. It has the same semantics as the 177 element. 179 constrains the query based on the e-mail address of the 180 contact. This may be done by an exact e-mail address using the 181 element or by any e-mail address in a domain using the 182 element. The MUST only contain a valid domain 183 name (i.e. no '@' symbol), and the matching SHOULD take place only 184 on the domain given (i.e. no partial matches with respect to 185 substrings or parent domains). If either the contents of the 186 element or domain part of the contents of the 187 element contain a name with non-ASCII characters, they MUST be 188 normalized according to the processes of RFC 3491 [15]. 190 The , , and elements restrict the scope of 191 the query based on the city, region, or postal code of the contact, 192 respectively. Each one must only contain an element 193 containing the exact city, region, or postal code (i.e. no substring 194 searches). 196 3.2 Result Derivatives 197 3.2.1 Privacy Labels 199 Several of the results in this registry type have values that cannot 200 be given but must be specified as present or must be flagged so that 201 clients do not divulge them. In order to achieve this, some of the 202 results use the following element types: 203 o "dateTimePrivacyType" - contains the XML Schema [3] data type 204 "dateTime". The contents of this element MUST be specified using 205 the 'Z' indicator for Coordinated Universal Time (UTC). 206 o "stringPrivacyType" - contains the XML Schema [3] data type 207 "string". 208 o "normalizedStringPrivacyType" - contains the XML Schema [3] data 209 type "normalizedString". 210 o "tokenPrivacyType" - contains the XML Schema [3] data type 211 "token". 212 o "enumStatusType" - contains an optional element of 213 indicating the date and time the status was applied and an 214 optional element of with required attribute 215 'language' indicating a description of the status. This element 216 also has an optional attribute of 'scope' to indicate the scope or 217 origin of the status value. 218 o "contactTypeType" - contains an optional child 219 elements. Each child element requires a 'language' 220 attribute. 222 As specified, they are nillable and therefore may be present with 223 empty content or present with their specified content. The use of 224 these elements is also optional. 226 If present without content, each of these element types MUST have one 227 or more of the following boolean attributes: 228 o 'private' - if true, this specifies that the content is absent 229 because it may never be published. 230 o 'denied' - if true, this specifies that the content is absent 231 because policy does not allow it to be given under the current 232 level of access. 234 If present with content, each of these element types MAY have one or 235 more of the following boolean attributes: 236 o 'doNotRedistribute' - if true, this specifies that the content is 237 not to be redistributed. 238 o 'specialAccess' - if true, this specifies that the content has 239 been provided due to special access rights. 241 These boolean attributes SHOULD be used in accordance with the level 242 of access being granted the recepient of the data. For example, 243 marking data as 'private' or 'denied' is to be expected if the user 244 is anonymous or has some other low level of access that does not 245 warrant viewing of that particular data. Likewise, data marked with 246 'doNotRedistribute' or 'specialAccess' is to be expected if the user 247 is authenticated and has a high level of access. 249 3.2.2 Result 251 An example of a result: 253 257 +1-703-555-1212 259 263 268 272 273 Bill Eckels 274 275 277 281 282 Mark Kosters 283 284 286 287 288 290 292 The result represents an instance of an ENUM assignment. The 293 children of the element are as follows: 294 o - the E.164 number for this ENUM as defined by [13]. 295 o - a registry unique assigned identifier to an ENUM. 296 o - MUST contain an entity reference to a referent of 297 type (Section 3.2.3). 298 o - an element containing an entity reference to the 299 registrant of this ENUM. The referent MUST be a 300 (Section 3.2.4) result. 301 o ENUM contacts - the following elements contain an entity reference 302 with a relationship to the ENUM. The referent of each MUST be a 303 (Section 3.2.4). 304 * 305 * 306 * 307 * 308 * 309 * 310 * 311 * 312 o - may contain at least one of the following elements of 313 type 'enumStatusType' (see Section 3.2.1), but none of these 314 elements may appear more than once. 315 * - permanently inactive 316 * - normal state 317 * - registration assigned but delegation 318 inactive 319 * - dispute 320 * - database purge pending 321 * - change of authority pending 322 * - on hold by registry 323 * - on hold by registrar 324 o - an element containing an entity 325 reference, the referent of which MUST be an (Section 326 3.2.2). The intention of this element is to point to the 327 downstream registration reference. Therefore, if this is a result 328 given back by an ENUM registry, it should point to the ENUM in the 329 ENUM registrar or registrant service. 330 o - contains an entity reference specifying the ENUM 331 registry operator for this ENUM which MUST be a 332 (Section 3.2.5). 333 o - contains an entity reference specifying the ENUM 334 registrar operator for this ENUM which MUST be a 335 (Section 3.2.5). 336 o - contains an entity reference specifying the ENUM 337 authenticator for this ENUM which MUST be a 338 (Section 3.2.5). 339 o - an element containing the date and 340 time of the initial delegation of this ENUM. 342 o - an element containing the date and time of 343 last renewal of this ENUM. 344 o - an element containing the date and time of 345 the expiration of this ENUM. 346 o - specifies the last time a 347 contact for the ENUM was added or removed. 348 o - an element containing an entity 349 reference. The referent MUST be a (Section 3.2.4) 350 responsible for the last addition or removal of a contact for this 351 ENUM. 352 o - an element containing the 353 date and time of the last time one of the nameservers was added or 354 removed for the delegation of this ENUM. 355 o - an element containing an entity 356 reference. The referent MUST be a (Section 3.2.4) 357 result and be responsible for the last addition or removal of a 358 nameserver for this ENUM. 359 o - an element containing the date and 360 time of the last time the data for this domain was verified by the 361 responsible registration authority. 362 o - an element containing an entity reference 363 specifying a referent that is indirectly associated with this 364 domain. 366 3.2.3 Result 368 An example of a result: 370 373 nsol184 374 a.iana-servers.net 375 192.0.2.43 376 380 382 The element represents an instance of a host registration. 383 The children of the element are as follows: 384 o - a registry unique assigned identifier for the host. 385 o - the fully qualified domain name of the host. The 386 contents of this element are a domain name and MUST conform to RFC 387 1035 [9]. 388 o - the content of which MUST conform to the a valid 389 IP version 4 host address as specified by RFC 791 [8]. 391 o - the content of which MUST conform to the a valid 392 IP version 6 host address as specified by RFC 3513 [7]. 393 o - an element containing an entity reference 394 specifying a contact associated with this host. The referent MUST 395 be (Section 3.2.4) results. 396 o - an element containing the date and time this 397 host was created. 398 o - an element containing the date and 399 time this host was last modified. 400 o - an element containing the date and 401 time this data for this host was last verified to be correct by 402 the appropriate registration authority. 403 o - an element containing an entity reference 404 specifying a referent that is indirectly associated with this 405 host. 407 3.2.4 Result 409 An example of a result: 411 414 dbarton 415 IANA Manager 416 Internet Assigned Numbers Authority 417 res-dom@iana.org 418 419
4676 Admiralty Way, Suite 330
420 Marina del Rey 421 CA 422 92092 423 US 424 425 310-823-9358 426 428 The element represents an instance of a contact 429 registration. The children of the element are as follows: 430 o - a registry unique assigned identifier for this 431 contact. 432 o - the name of the contact. 433 o - a specification of the language code to use to 434 localize the data in this result. 435 o - contains one of the following child elements: , 436 , , or . Each of these elements is a 437 "contactTypeType" as defined in Section 3.2.1. 439 o - an element containing the organization name of 440 the contact. 441 o - elements containing an e-mail address for this contact. 442 o - elements containing an e-mail address within an 443 internationalized domain name [14]. 444 o - elements containing a SIP address for this contact. 445 o - elements containing children representing a 446 postal address. has the following children: 447 *
- an element containing the street address for this 448 contact. 449 * - an element containing the city for this contact. 450 * - an element containing the national region for this 451 contact. 452 * - an element containing the postal code for this 453 contact. 454 * - an element containing the country for this contact. 455 This SHOULD be a 2-letter country code compliant with ISO 3166 456 [11]. 457 o - elements containing a voice phone number for this 458 contact. If it begins with a '+' (plus) character, it MUST be a 459 number defined by E164 [13]. The format number defined in E164 460 [13] is RECOMMENDED. 461 o - elements containing a facsimile phone number for this 462 contact. If it begins with a '+' (plus) character, it MUST be a 463 number defined by E164 [13]. The format number defined in E164 464 [13] is RECOMMENDED. 465 o - an element containing the date and time this 466 contact was created. 467 o - an element containing the date and 468 time this contact was last modified. 469 o - an element containing the date and 470 time this data for this contact was last verified to be correct by 471 the appropriate registration authority. 472 o - an element containing an entity reference 473 specifying equivalents of this contact that have been translated 474 into other languages. The referent MUST be (Section 475 3.2.4) results. 476 o - an element containing an entity reference 477 specifying a referent that is indirectly associated with this 478 contact. 480 3.2.5 482 An example of a result: 484 487 491 492 Internet Assigned Numbers Authority 493 494 495 497 The result represents an entity capable of 498 registering domains. 500 The child element of 501 contains an entity reference pointing to the entity "id" in the 502 entity class "iris". 504 The child element contains the name of the 505 registration authority. 507 The registration authority type child elements, , 508 , and , determine the role in which this 509 registration authority plays in the process of registering ENUMs. 510 The intent of this element is to explain the various roles a 511 registration authority may have with regards to the authority areas 512 pointed to by the element. A client MAY understand 513 the relationship of a registration authority with respect to an ENUM 514 by the placement of the reference in the domain (e.g. or 515 ). 517 3.2.6 519 An example of a result: 521 524 528 529 Some Government Authority 530 531 535 539 541 The result represents an entity responsible 542 for authenticating ENUMs against E.164 [13] registrations. 544 The child element of 545 contains an entity reference pointing to the entity "id" in the 546 entity class "iris". 548 The child element contains the name of the 549 authentication authority. 551 - an element containing an entity reference 552 specifying a technical contact associated with this authority. The 553 referent MUST be (Section 3.2.4) results. 555 - an element containing an entity reference 556 specifying an administrative contact associated with this authority. 557 The referent MUST be (Section 3.2.4) results. 559 3.3 Generic Code Derivatives 561 3.3.1 563 Servers MAY use the error code when a query must be 564 narrowed to yield a result set acceptable to the policies of the 565 server operator. 567 3.3.2 569 The queries , and support 570 optional language tags that allow a client to suggest to a server the 571 languages in which to scope the queries. If a client passes to the 572 server a language which the server does not support, the server MAY 573 use this error code to indicate that one of the languages is not 574 supported. 576 This element contains child elements named . 577 Each of these child elements specify a language not supported by the 578 server. When a server returns this error, it MUST give the languages 579 from the query which are not supported. 581 3.4 Support for 583 The following types of entity classes are recognized by the 584 query of IRIS for this registry: 585 o host-name - the fully qualified domain name of a nameserver. 586 Yields a (Section 3.2.3) in the response. 587 o host-handle - the registry unique identifier given a nameserver. 588 Yields a (Section 3.2.3) in the response. 589 o e164 - an E.164 number as specified by [13]. Yields a 590 (Section 3.2.2) in the response. 591 o enum - the fully qualified name of an ENUM domain. This a domain 592 name as specified by RFC 1035 [9]. Yields a (Section 593 3.2.2) in the response. 594 o enum-handle - the registry unique identifier given a ENUM. Yields 595 a ; (Section 3.2.2) in the response. 596 o contact-handle - the registry unique identifier given a contact. 597 Yields a (Section 3.2.4) in the response. 598 o ipv4-address - the IPv4 address of a nameserver. Yields a 599 (Section 3.2.3) in the response. 600 o ipv6-address - the IPv6 address of a nameserver. Yields a 601 (Section 3.2.3) in the response. 602 o registration-authority - the name of a registration authority. 603 Yields a (Section 3.2.5) in the response. 604 o authentication-authority - the name of an authentication 605 authority. Yields a (Section 3.2.6) 606 o All names in these entity classes are case insensitive. 608 4. Formal XML Syntax 610 This registry schema is specified in the XML Schema notation. The 611 formal syntax presented here is a complete schema representation 612 suitable for automated validation of an XML instance when combined 613 with the formal schema syntax of IRIS. 615 616 622 624 625 626 ENUM registry schema 627 derived from IRIS schema 628 629 631 632 633 634 635 637 638 639 641 643 644 646 647 648 650 653 654 658 659 661 663 665 667 669 671 673 675 677 679 680 681 682 687 688 689 690 692 697 698 699 701 703 704 706 707 709 714 715 716 717 719 724 725 726 728 730 731 733 734 735 738 741 744 747 748 749 750 752 754 759 760 761 763 765 766 769 772 775 778 781 784 787 788 790 792 793 795 797 798 799 801 803 805 807 808 810 811 813 815 816 818 821 822 824 826 827 828 830 831 833 835 836 837 838 841 842 844 846 848 849 850 851 853 854 856 858 859 860 861 862 864 866 867 870 871 873 874 875 876 877 879 880 881 883 885 886 888 889 892 898 903 908 913 918 923 928 933 938 943 948 954 959 963 964 965 970 975 980 985 990 995 1000 1005 1010 1011 1012 1013 1018 1023 1028 1033 1039 1045 1051 1057 1062 1068 1072 1073 1074 1075 1077 1082 1083 1084 1086 1088 1089 1091 1092 1098 1101 1106 1111 1116 1122 1128 1134 1138 1139 1140 1141 1143 1148 1149 1150 1152 1154 1155 1157 1158 1164 1170 1175 1179 1180 1181 1185 1188 1191 1194 1195 1196 1197 1203 1209 1215 1221 1225 1226 1227 1234 1240 1246 1252 1258 1259 1260 1261 1267 1273 1279 1285 1291 1296 1300 1301 1302 1303 1305 1310 1311 1312 1314 1316 1317 1319 1320 1325 1331 1334 1336 1337 1338 1340 1341 1342 1344 1345 1346 1347 1348 1349 1350 1352 1357 1358 1359 1361 1363 1364 1366 1367 1372 1377 1382 1387 1388 1389 1390 1392 1397 1398 1399 1401 1403 1406 1409 1412 1415 1417 1419 1420 1422 1424 1425 1426 1427 1429 1430 1432 1434 1435 1436 1438 1440 1441 1443 1445 1446 1447 1449 1451 1452 1454 1456 1457 1458 1460 1462 1463 1468 1472 1473 1474 1476 1480 1481 1482 1483 1484 1485 1487 1490 1492 1494 1495 1499 1500 1501 1503 1507 1508 1509 1510 1511 1512 1514 1516 1517 1518 1519 1520 1522 1523 1524 1526 1531 1532 1533 1535 1537 1538 1540 1541 1546 1547 1548 1549 1551 1556 1558 Figure 6: dreg.xsd 1560 5. BEEP Transport Compliance 1562 IRIS allows several extensions of the core capabilities. This 1563 section outlines those extensions allowable by IRIS-BEEP [6]. 1565 5.1 Message Pattern 1567 This registry type uses the default message pattern as described in 1568 IRIS-BEEP [6]. 1570 5.2 Server Authentication 1572 This registry type only uses the basic TLS server authentication 1573 method as described in IRIS-BEEP [6]. 1575 6. URI Resolution 1577 6.1 Application Service Label 1579 The application service label associated with this registry type MUST 1580 be "EREG1". This is the abbreviated form of the URN for this 1581 registry type, urn:ietf:params:xml:ns:ereg1. 1583 7. Internationalization Considerations 1585 Implementers should be aware of considerations for 1586 internationalization in IRIS [5]. 1588 The social data associated with contacts may be non-ASCII, and could 1589 contain virtually any Unicode character. The element is 1590 provided in queries that have potential to traverse such data. 1591 Clients should use these elements to indicate to the server of the 1592 target languages desired, and servers should use these elements to 1593 better enable normalization and search processes (see [18]). 1595 Clients needing to localize the data tags in this protocol should 1596 take note that localization is only needed on the names of XML 1597 elements and attributes with the exception of elements containing 1598 date and time information. The schema for this registry has been 1599 designed so that clients need not interpret the content of elements 1600 or attributes for localization, other than those elements containing 1601 date and time information. 1603 Clients should also make use of the elements provided in 1604 many of the results. Results containing data that may be in Unicode 1605 are accompanied by these elements in order to aid better presentation 1606 of the data to the user. 1608 The "dateTimePrivacyType" element type contains the XML Schema [3] 1609 data type "dateTime". The contents of this element MUST be specified 1610 using the 'Z' indicator for Coordinated Universal Time (UTC). 1612 8. IANA Considerations 1614 8.1 XML Namespace URN Registration 1616 This document makes use of a proposed XML namespace and schema 1617 registry specified in XML_URN [16]. Accordingly, the following 1618 registration information is provided for the IANA: 1619 o URN/URI: 1620 * urn:ietf:params:xml:ns:3reg1 1621 o Contact: 1622 * Andrew Newton 1623 o XML: 1624 * The XML Schema specified in Section 4 1626 8.2 S-NAPTR Registration 1628 The following S-NAPTR application service label will need to be 1629 registered with IANA according to the IANA considerations defined in 1630 IRIS [5]: 1631 EREG1 1633 8.3 BEEP Registration 1635 The following BEEP Profile URI is to be registeried with IANA, in 1636 addition to the registration provided in IRIS-BEEP [6]. 1638 http://iana.org/beep/iris1/ereg1 1640 9. Security Considerations 1642 This document lays out no new considerations for security precautions 1643 beyond that specified in IRIS [5]. 1645 10. References 1647 10.1 Normative References 1649 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1650 1.0", W3C XML, February 1998, 1651 . 1653 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 1654 Namespaces, January 1999, 1655 . 1657 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 1658 XML Schema, October 2000, 1659 . 1661 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C 1662 XML Schema, October 2000, 1663 . 1665 [5] Newton, A. and M. Sanz, "Internet Registry Information 1666 Service", draft-ietf-crisp-iris-core-05 (work in progress), 1667 January 2004. 1669 [6] Newton, A. and M. Sanz, "Internet Registry Information Service 1670 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 1671 draft-ietf-crisp-iris-beep-05 (work in progress), January 2004. 1673 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1674 Addressing Architecture", RFC 3513, April 2003. 1676 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1677 1981. 1679 [9] Mockapetris, P., "Domain names - implementation and 1680 specification", STD 13, RFC 1035, November 1987. 1682 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1683 Levels", RFC 2119, BCP 14, March 1997. 1685 [11] International Organization for Standardization, "Codes for the 1686 representation of names of countries, 3rd edition", ISO 1687 Standard 3166, August 1988. 1689 [12] Braden, R., "Requirements for Internet Hosts - Application and 1690 Support", STD 3, RFC 1123, October 1989. 1692 [13] International Telecommunications Union, "The International 1693 Public Telecommunication Numbering Plan", ITU-T Recommendation 1694 E.164, 1991. 1696 [14] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 1697 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 1699 [15] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 1700 for Internationalized Domain Names (IDN)", RFC 3491, March 1701 2003. 1703 [16] Mealling, M., "The IETF XML Registry", 1704 draft-mealling-iana-xmlns-registry-03 (work in progress), 1705 November 2001. 1707 10.2 Informative References 1709 [17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 1710 Requirements", RFC 3707, February 2004. 1712 URIs 1714 [18] 1716 Author's Address 1718 Andrew L. Newton 1719 VeriSign, Inc. 1720 21345 Ridgetop Circle 1721 Sterling, VA 20166 1722 USA 1724 Phone: +1 703 948 3382 1725 EMail: anewton@verisignlabs.com; andy@hxr.us 1726 URI: http://www.verisignlabs.com/ 1728 Appendix A. Contributions and Acknowledgements 1730 This document is a derivative of the specification used to define 1731 forward domain registries for IRIS. Marcos Sanz was a major 1732 contributor to that specification and many of his words and ideas are 1733 present in this document. 1735 Intellectual Property Statement 1737 The IETF takes no position regarding the validity or scope of any 1738 Intellectual Property Rights or other rights that might be claimed to 1739 pertain to the implementation or use of the technology described in 1740 this document or the extent to which any license under such rights 1741 might or might not be available; nor does it represent that it has 1742 made any independent effort to identify any such rights. Information 1743 on the procedures with respect to rights in RFC documents can be 1744 found in BCP 78 and BCP 79. 1746 Copies of IPR disclosures made to the IETF Secretariat and any 1747 assurances of licenses to be made available, or the result of an 1748 attempt made to obtain a general license or permission for the use of 1749 such proprietary rights by implementers or users of this 1750 specification can be obtained from the IETF on-line IPR repository at 1751 http://www.ietf.org/ipr. 1753 The IETF invites any interested party to bring to its attention any 1754 copyrights, patents or patent applications, or other proprietary 1755 rights that may cover technology that may be required to implement 1756 this standard. Please address the information to the IETF at 1757 ietf-ipr@ietf.org. 1759 Disclaimer of Validity 1761 This document and the information contained herein are provided on an 1762 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1763 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1764 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1765 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1766 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1767 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1769 Copyright Statement 1771 Copyright (C) The Internet Society (2004). This document is subject 1772 to the rights, licenses and restrictions contained in BCP 78, and 1773 except as set forth therein, the authors retain all their rights. 1775 Acknowledgment 1777 Funding for the RFC Editor function is currently provided by the 1778 Internet Society.