idnits 2.17.1 draft-newton-crisp-iris-dchk-00.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 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1028. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1044), 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 (July 10, 2004) is 7201 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: '1' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 924, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 932, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 951, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 954, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 963, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 967, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 970, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 974, 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 ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-beep-05 ** Obsolete normative reference: RFC 3513 (ref. '9') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 3490 (ref. '16') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (ref. '17') (Obsoleted by RFC 5891) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Newton 2 Internet-Draft VeriSign, Inc. 3 Expires: January 8, 2005 July 10, 2004 5 IRIS - A Domain Availability Check (dchk) Registry Type for the 6 Internet Registry Information Service 7 draft-newton-crisp-iris-dchk-00 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 January 8, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes a lightweight domain availability service 41 using the IRIS framework and the data model of the IRIS Domain 42 Registry service. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 5 48 3. DCHK Registry . . . . . . . . . . . . . . . . . . . . . . . . 6 49 3.1 Schema Description . . . . . . . . . . . . . . . . . . . . 6 50 3.1.1 The Result . . . . . . . . . . . . . . . . . 6 51 3.1.2 Support for . . . . . . . . . . . 7 52 3.2 DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . . 7 53 3.3 BEEP Transport Compliance . . . . . . . . . . . . . . . . 11 54 3.3.1 Message Pattern . . . . . . . . . . . . . . . . . . . 11 55 3.3.2 Server Authentication . . . . . . . . . . . . . . . . 11 56 3.4 URI Resolution . . . . . . . . . . . . . . . . . . . . . . 11 57 3.4.1 Application Service Label . . . . . . . . . . . . . . 11 58 3.4.2 Bottom-Up Resolution . . . . . . . . . . . . . . . . . 11 59 3.4.3 Top-Down Resolution . . . . . . . . . . . . . . . . . 12 60 4. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 61 4.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 13 62 4.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 13 63 4.1.2 IRIS-LWZ Transactions . . . . . . . . . . . . . . . . 13 64 4.2 IRIS-LWZ Operations . . . . . . . . . . . . . . . . . . . 14 65 4.2.1 Requests . . . . . . . . . . . . . . . . . . . . . . . 15 66 4.2.2 Responses . . . . . . . . . . . . . . . . . . . . . . 16 67 4.3 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 18 68 4.4 IRIS Transport Mapping Definitions . . . . . . . . . . . . 19 69 4.4.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 19 70 4.4.2 Application Protocol Label . . . . . . . . . . . . . . 19 71 4.5 Registrations . . . . . . . . . . . . . . . . . . . . . . 20 72 4.5.1 URI Scheme Registration . . . . . . . . . . . . . . . 20 73 4.5.2 Well-known UDP Port Registration . . . . . . . . . . . 20 74 4.5.3 NAPSTR Registration . . . . . . . . . . . . . . . . . 20 75 5. Internationalization Considerations . . . . . . . . . . . . . 22 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 77 6.1 XML Namespace URN Registration . . . . . . . . . . . . . . 23 78 6.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 23 79 6.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 23 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 83 8.2 Informative References . . . . . . . . . . . . . . . . . . . 26 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 85 Intellectual Property and Copyright Statements . . . . . . . . 28 87 1. Introduction 89 There are many ways to check domain name availability for 90 registration, but none of them are ideal for the general public. 91 Currently, checks for domain availability are conducted in the 92 following ways: 93 1. DNS - Checking the existance of a domain name using DNS is fast. 94 However, a DNS existance check only reveals if a domain name is 95 registered and active and does not reveal if a domain name is 96 registered and inactive. There are many administrative reasons 97 why a domain name may be inactive. Today, there are over 2 98 million in registered but inactive domains in .com. 99 2. EPP - This method of checking can indicate the state where a 100 domain is registered but not active. However, EPP is a 101 registrar-to-registry protocol and is not generally available to 102 the public. EPP environments are often tuned specifically for 103 registrar-to-registry communications with long-lived connections, 104 strong encryption and authentication, fixed sets of channels, and 105 other parameters that do not make it ideal for use by 106 non-registrars. 107 3. Nicname/Whois - This protocol was created before the advent of 108 DNS and consequently does not fulfill many of the needs for a 109 general domain-name information service much less a domain 110 availability service. Its defeciencies are well documented and 111 the basis for the [19] work. 112 4. DREG - The IRIS Domain Registry is a product of the [19] working 113 group, and it solves many of the deficiencies in the Nicname/ 114 Whois protocol and is well positioned to serve as a general 115 domain registration information service for the general public. 117 This document describes a lightweight service for checking the 118 availability of domain names. This service is based on the IRIS 119 framework and uses the data model defined by DREG. By doing this, 120 the domain availability service has the advantages provided by IRIS 121 and DREG, such as well-known methods for server navigation, 122 structured queries and results, and layered extensibility. 124 The use of IRIS for this service also allows seemless integration 125 between the domain availability service and the service provided by 126 DREG. This allows a user to find the availability status of domain 127 and reference the full registration information in DREG. 129 The data model in this service (called a registry schema in IRIS 130 terms) is a strict subset of the DREG data model. This enables 131 implementors to directly reuse DREG code paths and allows operators 132 to deploy the service in either the same server processes as a DREG 133 service (same host and port) or in a different server process 134 (different port) or machine (different host). 136 As an example, an operator may wish to deploy both types of service 137 on the same set of machines. As time goes on, the operator may then 138 decide to segregate the services, placing the domain availability 139 service on one set of machines and the DREG service on a separate set 140 of machines with a stricter set of controls. Either deployment 141 scenario is transparent to the end user and always appear to be 142 seemlessly complementary. 144 This domain availability service is lightweight because it defines a 145 UDP transport. Using S-NAPTR, IRIS has the ability to define the use 146 of multiple transports for different types of registry services, all 147 at the descretion of the server operator. The UDP transport defined 148 in this document is completely modular and may be used by other 149 registry types. An earlier version of it was previously described in 150 draft-newton-iris-lightweight-01.xml. 152 2. Document Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC2119 [12]. 158 3. DCHK Registry 160 The data model used for the domain availability check (DCHK) service 161 is a strict subset of the DREG data model. This section describes 162 the DCHK registry type. See [5]. 164 3.1 Schema Description 166 References to XML elements with no namespace qualifier are from the 167 schema defined in Section 3.2. References to elements and attributes 168 with the "iris" XML namespace qualifier are from the schema defined 169 in IRIS [5]. 171 The descriptions contained within this section refer to XML elements 172 and attributes and their relation to the exchange of data within the 173 protocol. These descriptions also contain specifications outside the 174 scope of the formal XML syntax. Therefore, this section will use 175 terms defined by RFC 2119 [12] to describe the specification outside 176 the scope of the formal XML syntax. While reading this section, 177 please reference Section 3.2 for needed details on the formal XML 178 syntax. 180 3.1.1 The Result 182 An example of a result: 184 187 example.com 188 189 191 The result represents an instance of a domain assignment. 192 The children of the element are as follows: 193 o - the full name of the domain as it is in DNS. The 194 contents of this element MUST be a domain name as specified by RFC 195 1035 [11]. 196 o - the name of the domain in nameprep form if applicable. 197 See RFC 3491 [17]. 198 o - may contain at least one of the following elements of 199 type 'domainStatusType' (see Section 3.1.1.1), but none of these 200 elements may appear more than once. 201 * - permanently inactive 202 * - normal state 203 * - registration assigned but delegation 204 inactive 206 * - dispute 207 * - database purge pending 208 * - change of authority pending 209 * - on hold by registry 210 * - on hold by registrar 211 o - contains an entity reference, the referent of 212 which MUST be a (Section 3.1.1). 213 o - an element containing an entity 214 reference, the referent of which MUST be a (Section 215 3.1.1). The intention of this element is to point to the 216 downstream registration reference. Therefore, if this is a result 217 given back by a domain registry, it should point to the domain in 218 the domain registrar or registrant service. 219 o - an element containing an entity reference 220 specifying a referent that is indirectly associated with this 221 domain. 223 3.1.1.1 Domain Status Type 225 Each element that is of the 'domainStatusType' may have an optional 226 element and one or more elements, the 227 text contents of which may be used to describe the status in natural 228 language. Each element must have a 'language' 229 attribute describing the language of the description element. 231 3.1.2 Support for 233 The following types of entity classes are recognized by the 234 query of IRIS for this registry: 235 o domain-name - the fully qualified name of a domain. This a domain 236 name as specified by RFC 1035 [11]. Yields a (Section 237 3.1.1) in the response. 238 o idn - the fully qualified name of a domain in nameprep form (see 239 RFC 3491 [17]). Yields a (Section 3.1.1) in the 240 response. 242 3.2 DCHK Formal XML Syntax 244 This registry schema is specified in the XML Schema notation. The 245 formal syntax presented here is a complete schema representation 246 suitable for automated validation of an XML instance when combined 247 with the formal schema syntax of IRIS. 249 250 256 258 259 260 Domain availability check schema 261 derived from IRIS schema 262 263 265 266 267 268 269 271 272 273 275 277 278 280 281 284 289 293 294 295 300 305 310 315 320 325 330 335 340 341 342 343 348 353 357 358 359 360 362 367 369 370 375 379 380 381 383 387 388 389 390 391 392 395 397 399 Figure 2: dchk.xsd 401 3.3 BEEP Transport Compliance 403 Though this document defines a UDP transport for use with DCHK, it is 404 still possible to use DCHK with the [8] transport. The use of this 405 transport is completely at the descretion of the server operator. 407 IRIS allows several extensions of the core capabilities. This 408 section outlines those extensions allowable by IRIS-BEEP [8]. 410 3.3.1 Message Pattern 412 This registry type uses the default message pattern as described in 413 IRIS-BEEP [8]. 415 3.3.2 Server Authentication 417 This registry type uses the default server authentication method as 418 described in IRIS-BEEP [8]. 420 3.4 URI Resolution 422 3.4.1 Application Service Label 424 The application service label associated with this registry type MUST 425 be "DCHK1". This is the abbreviated form of the URN for this 426 registry type, urn:ietf:params:xml:ns:dchk1. 428 3.4.2 Bottom-Up Resolution 430 The bottom-up alternative resolution method MUST be identified as 431 'bottom' in IRIS URI's. 433 The process for this resolution method differs from the 434 direct-resolution method if the authority is only a domain name (i.e. 435 without the port number). The process for this condition is as 436 follows: 437 1. The IRIS [5] direct resolution process is tried on the domain 438 name (e.g. "example.com" ). 439 2. If the direct resolution process yields no server for which a 440 connection can be made, then the leftmost label of the domain 441 name is removed, and the first step is repeated again (e.g. 442 "com" ). 444 3. If all the labels of the domain name are removed and no server 445 connections have been made, then the DNS is queried for the 446 address records corresponding to the original domain name and the 447 port used is the well-known port for the default protocol of 448 IRIS. 450 3.4.3 Top-Down Resolution 452 The top-down alternative resolution method MUST be identified as 453 'top' in IRIS URI's. 455 The process for this resolution method differs from the 456 direct-resolution method if the authority is only a domain name (i.e. 457 without the port number). The process for this condition is as 458 follows: 459 1. The domain name is reduced to its rightmost label. This is 460 always '.'. 461 2. The IRIS [5] direct resolution process is tried on the domain 462 name. 463 3. If the direct resolution process yields no server for which a 464 connection can be made, then the original label to the left of 465 the rightmost label of the domain name is prepended, and the 466 second step is repeated again (e.g. if "." then "com", if "com" 467 then "example.com"). 468 4. If all the labels of the original domain are present and no 469 server connections have been made, then the DNS is queried for 470 the address records corresponding to the original domain name and 471 the port used is the well-known port for the default protocol of 472 IRIS. 474 4. UDP Transport 476 To be fast, the domain availability service may use the UDP transport 477 defined in this section. The binding of this UDP transport to IRIS 478 is called IRIS-LWZ (for IRIS Lightweight using Compression). This 479 transport may be used with other registry types defined for IRIS, 480 such as DREG. 482 IRIS-LWZ is composed of two parts, a 1 byte payload header and an XML 483 request/response transaction payload. The XML request/response 484 transaction payload may be compressed using the DEFLATE algorithm. 486 4.1 Use of IRIS-LWZ 488 4.1.1 IRIS-LWZ Packet Formats 490 The UDP packet format for IRIS-LWZ is as follows: 492 0 8 16 31 493 +--------------------+--------------------+ 494 | Src Port | Dst Port | 495 +--------------------+--------------------+ 496 | Checksum | Length | 497 +--------------------+--------------------+ 498 | LWZ-HEADER | | 499 +------------+ | 500 | Data: XML instance | 501 | compliant with IRIS-LWZ | 502 | schema defined above | 503 +-----------------------------------------+ 505 Each IRIS-LWZ query and response is contained in a single UDP packet. 506 If no length information is contained in the IRIS-LWZ query, servers 507 should assume a packet size limitation of 512 bytes. 509 Each bit in the 1 byte payload header has the following meaning: 510 bit 7 - version - if 0, the protocol is the version defined in 511 this document. If 1, the rest of the bits in the header and the 512 payload may be interpreted as another version. 513 bit 6 - deflate - if 1, the payload is compressed using DEFLATE. 514 bits 5 through 1 - reserved 515 bit 0 - protocol error - meaning that there was something not 516 understood in the payload (e.g. a version mis-match, malformed 517 XML, etc...). 519 4.1.2 IRIS-LWZ Transactions 520 4.1.2.1 Client behaviour 522 To initiate an IRIS-LWZ query, a client sends a UDP datagram to the 523 identified IRIS-LWZ port on the destination server. 525 The client then waits for a reply from the server on the same port 526 from which it sent the query packet. The timeout waiting for a reply 527 is at the discretion of the client. 529 As an example, the client may send the following XML to the server: 531 535 537 538 542 544 546 548 4.1.2.2 Server behaviour 550 Upon receipt of an IRIS-LWZ query, the server will apply DEFLATE 551 decompression to the payload if appropriate, carry out whatever 552 processing is appropriate, create a valid IRIS-LWZ XML response 553 instance to the query, and apply DEFLATE to that instance if 554 necessary. If the resulting size is greater than the maximum size 555 provided in the query (or 512 bytes if no maximum size was provided), 556 the server will respond with a IRIS-LWZ XML indicating the response 557 was too large. The response is sent as a UDP datagram to the source 558 address and port of the original query. 560 The server's responsibility for addressing a query ends with the 561 transmission of the UDP response datagram. 563 4.2 IRIS-LWZ Operations 565 The XML in the following sections is descriptive of the formal XML 566 syntax described in Section 4.3. 568 For each request type, there is one or more response types. The 569 following shows a brief summary: 570 o 571 * 572 o 573 * an IRIS response. 574 * containing 575 * containing 577 4.2.1 Requests 579 IRIS-LWZ requests use the formal syntax specified in Section 4.3. 580 There are two types of IRIS-LWZ requests: 581 o a profile request 582 o an IRIS query request 584 The profile request simply uses the element. 586 589 An IRIS request is wrapped in an element. This element has 590 an OPTIONAL 'length' attribute containing a positive integer. This 591 attribute indicates the allowable length of the response in bytes. 592 It allows clients that have an understanding of their UDP path to 593 specify how long the response should be. Clients that do not care 594 about UDP fragmentation may set this number arbitrarily high. If 595 this attribute is not present, servers MUST assume a length of 512 596 bytes. 598 The following is an example of an IRIS request with a query in the 599 'dchk1' registry-type. 601 605 607 608 613 615 617 619 4.2.2 Responses 621 The IRIS-LWZ responses come in two flavors: 622 o a response 623 o a response 625 The response MUST be returned by the server when a client 626 issues a request. The element contains 627 children. Each child element contains an IRIS 628 profile as defined by IRIS-BEEP [8]. 630 The following is an example of a response. 632 634 635 http://iana.org/beep/iris1/dchk1 636 637 639 The response MUST be sent by the server to the client in 640 reply to an . It contains one of three types of content: 641 o an IRIS result response 642 o an error indicating the IRIS request was for an unsupported 643 profile. 644 o an error indicating the IRIS response was too large to send. 646 An containing an IRIS response simply contains the IRIS 647 response to the appropriate IRIS request. The following is an 648 example of 'dchk1' IRIS response. 650 653 655 656 658 example.com 659 660 661 662 664 666 668 When a client makes an IRIS request for a profile that is not 669 supported by the server, the server MUST return an 670 indicating that an error has occured. This is done with the 671 child element. To signal this condition, the element MUST 672 contain the element. Here is an example: 674 677 678 679 680 http://iana.org/beep/iris1/dchk1 681 682 683 685 687 When a client makes an IRIS request that yields a response too large 688 to fit in the negotiated UDP packet, the server MUST respond with an 689 indicating that a size error has occured. This is done 690 with the child element. To signal this condition, the 691 element MUST contain a element. The content of the 692 element is a positive integer stating the size of the IRIS 693 response. 695 Upon receiving this error, a client has the following options: 697 o Requery over IRIS-BEEP. 698 o Requery over IRIS-LWZ using a larger 'length' indicator. 699 o Signal an error to the user. 701 The following is an example of a length error: 703 706 707 2652 708 710 712 4.3 Formal XML Syntax 714 The following is the XML Schema used to define IRIS-LWZ operations. 716 717 723 725 726 727 Lightweight (LWZ) Transport for 728 Internet Registry Information Service (IRIS) 729 Schema v1 730 731 733 734 735 736 738 739 740 741 742 743 745 747 748 749 750 751 752 753 755 756 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 776 778 4.4 IRIS Transport Mapping Definitions 780 This section lists the definitions required by IRIS [5] for transport 781 mappings. 783 4.4.1 URI Scheme 785 The URI scheme name specific to this transport MUST be "iris.lwz". 787 4.4.2 Application Protocol Label 789 The application protocol label MUST be "iris.lwz". 791 4.5 Registrations 793 4.5.1 URI Scheme Registration 795 URL scheme name: iris.lwz 797 URL scheme syntax: defined in Section 4.4.1 and [5]. 799 Character encoding considerations: as defined in RFC2396 [6]. 801 Intended usage: identifies an IRIS entity made available using 802 compressed XML over UDP 804 Applications using this scheme: defined in IRIS [5]. 806 Interoperability considerations: n/a 808 Security Considerations: defined in Section 7. 810 Relevant Publications: IRIS [5]. 812 Contact Information: Andrew Newton 814 Author/Change controller: the IESG 816 4.5.2 Well-known UDP Port Registration 818 Protocol Number: UDP 820 Message Formats, Types, Opcodes, and Sequences: defined in Section 821 4.1.1 and Section 4.2. 823 Functions: defined in IRIS [5]. 825 Use of Broadcast/Multicast: none 827 Proposed Name: IRIS over LWZ 829 Short name: iris.lwz 831 Contact Information: Andrew Newton 833 4.5.3 NAPSTR Registration 835 Application Protocol Label: iris.lwz 837 Intended usage: identifies an IRIS server using compressed XML over 838 UDP 839 Interoperability considerations: n/a 841 Security Considerations: defined in Section 7. 843 Relevant Publications: IRIS [5]. 845 Contact Information: Andrew Newton 847 Author/Change controller: the IESG 849 5. Internationalization Considerations 851 Implementers should be aware of considerations for 852 internationalization in IRIS [5]. 854 This document specifies the lookup of domain names, both the 855 traditional ASCII form and the IDN form. In addition, the social 856 data associated with contacts may also be non-ASCII, and could 857 contain virtually any Unicode character. The element is 858 provided in queries that have potential to traverse such data. 859 Clients should use these elements to indicate to the server of the 860 target languages desired, and servers should use these elements to 861 better enable normalization and search processes (see [20]). 863 Clients needing to localize the data tags in this protocol should 864 take note that localization is only needed on the names of XML 865 elements and attributes with the exception of elements containing 866 date and time information. The schema for this registry has been 867 designed so that clients need not interpret the content of elements 868 or attributes for localization, other than those elements containing 869 date and time information. 871 Clients should also make use of the elements provided in 872 many of the results. Results containing data that may be in Unicode 873 are accompanied by these elements in order to aid better presentation 874 of the data to the user. 876 The "dateTimePrivacyType" element type contains the XML Schema [3] 877 data type "dateTime". The contents of this element MUST be specified 878 using the 'Z' indicator for Coordinated Universal Time (UTC). 880 6. IANA Considerations 882 6.1 XML Namespace URN Registration 884 This document makes use of a proposed XML namespace and schema 885 registry specified in XML_URN [18]. Accordingly, the following 886 registration information is provided for the IANA: 887 o URN/URI: 888 * urn:ietf:params:xml:ns:dchk1 889 o Contact: 890 * Andrew Newton 891 o XML: 892 * The XML Schema specified in Section 3.2 894 6.2 S-NAPTR Registration 896 The following S-NAPTR application service label will need to be 897 registered with IANA according to the IANA considerations defined in 898 IRIS [5]: 899 DCHK1 901 6.3 BEEP Registration 903 The following BEEP Profile URI is to be registeried with IANA, in 904 addition to the registration provided in IRIS-BEEP [8]. 906 http://iana.org/beep/iris1/dchk1 908 7. Security Considerations 910 IRIS-LWZ is intended for serving public data; it provides no in-band 911 mechanisms for authentication or encryption. Any application that 912 needs that must provide out of band mechanisms to provide it (e.g., 913 IPSec), or use the IRIS protocol with an application transport that 914 provides such capabilities (e.g. BEEP [7]. 916 8. References 918 8.1 Normative References 920 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 921 1.0", W3C XML, February 1998, 922 . 924 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 925 Namespaces, January 1999, 926 . 928 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 929 XML Schema, October 2000, 930 . 932 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", 933 W3C XML Schema, October 2000, 934 . 936 [5] Newton, A. and M. Sanz, "Internet Registry Information 937 Service", draft-ietf-crisp-iris-core-05 (work in progress), 938 January 2004. 940 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 941 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 942 1998. 944 [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 945 3080, March 2001. 947 [8] Newton, A. and M. Sanz, "Internet Registry Information Service 948 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 949 draft-ietf-crisp-iris-beep-05 (work in progress), January 2004. 951 [9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 952 Addressing Architecture", RFC 3513, April 2003. 954 [10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 955 1981. 957 [11] Mockapetris, P., "Domain names - implementation and 958 specification", STD 13, RFC 1035, November 1987. 960 [12] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", RFC 2119, BCP 14, March 1997. 963 [13] International Organization for Standardization, "Codes for the 964 representation of names of countries, 3rd edition", ISO 965 Standard 3166, August 1988. 967 [14] Braden, R., "Requirements for Internet Hosts - Application and 968 Support", STD 3, RFC 1123, October 1989. 970 [15] International Telecommunications Union, "The International 971 Public Telecommunication Numbering Plan", ITU-T Recommendation 972 E.164, 1991. 974 [16] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 975 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 977 [17] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 978 for Internationalized Domain Names (IDN)", RFC 3491, March 979 2003. 981 [18] Mealling, M., "The IETF XML Registry", 982 draft-mealling-iana-xmlns-registry-03 (work in progress), 983 November 2001. 985 8.2 Informative References 987 [19] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 988 Requirements", RFC 3707, February 2004. 990 URIs 992 [20] 994 Author's Address 996 Andrew L. Newton 997 VeriSign, Inc. 998 21345 Ridgetop Circle 999 Sterling, VA 20166 1000 USA 1002 Phone: +1 703 948 3382 1003 EMail: anewton@verisignlabs.com; andy@hxr.us 1004 URI: http://www.verisignlabs.com/ 1006 Intellectual Property Statement 1008 The IETF takes no position regarding the validity or scope of any 1009 Intellectual Property Rights or other rights that might be claimed to 1010 pertain to the implementation or use of the technology described in 1011 this document or the extent to which any license under such rights 1012 might or might not be available; nor does it represent that it has 1013 made any independent effort to identify any such rights. Information 1014 on the procedures with respect to rights in RFC documents can be 1015 found in BCP 78 and BCP 79. 1017 Copies of IPR disclosures made to the IETF Secretariat and any 1018 assurances of licenses to be made available, or the result of an 1019 attempt made to obtain a general license or permission for the use of 1020 such proprietary rights by implementers or users of this 1021 specification can be obtained from the IETF on-line IPR repository at 1022 http://www.ietf.org/ipr. 1024 The IETF invites any interested party to bring to its attention any 1025 copyrights, patents or patent applications, or other proprietary 1026 rights that may cover technology that may be required to implement 1027 this standard. Please address the information to the IETF at 1028 ietf-ipr@ietf.org. 1030 Disclaimer of Validity 1032 This document and the information contained herein are provided on an 1033 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1034 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1035 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1036 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1037 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1038 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1040 Copyright Statement 1042 Copyright (C) The Internet Society (2004). This document is subject 1043 to the rights, licenses and restrictions contained in BCP 78, and 1044 except as set forth therein, the authors retain all their rights. 1046 Acknowledgment 1048 Funding for the RFC Editor function is currently provided by the 1049 Internet Society.