idnits 2.17.1 draft-hardie-ecrit-iris-03.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1110. ** 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. 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 (October 21, 2005) is 6761 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- No information found for draft-ietf-crips-iris-lwz - is the name correct? -- No information found for draft-ietf-crips-iris-xpc - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 Expires: April 24, 2006 A. Newton 5 Verisign, Inc. 6 H. Tschofenig 7 Siemens 8 October 21, 2005 10 An IRIS schema for Emergency Service contact URIs 11 draft-hardie-ecrit-iris-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 24, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes an XML-based protocol for passing location 45 information to a server that returns emergency service contact URIs. 46 It is intended to fit within a larger framework of standards. 47 Specifically, it presumes the existence of a URI scheme appropriate 48 for signalling that emergency service is required and distinguishing 49 among emergency services if appropriate. It also presumes that an 50 entity requesting this response will be able to handle the URIs 51 returned as input to appropriate handlers. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3 A Simple Example . . . . . . . . . . . . . . . . . . . . . 5 60 2.4 Deployment Methods . . . . . . . . . . . . . . . . . . . . 7 61 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 11 62 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 11 63 3.1.1 Query . . . . . . . . . . . . . . . 11 64 3.1.2 Query . . . . . . . . . . . . . . . . 11 65 3.1.3 Query . . . . . . . . . . . . . . . . . 12 66 3.2 Service Types . . . . . . . . . . . . . . . . . . . . . . 12 67 3.3 Result Derivatives . . . . . . . . . . . . . . . . . . . . 12 68 3.3.1 Result . . . . . . . . . . . . . . 12 69 3.3.2 Result . . . . . . . . . . . . . . 13 70 3.4 Error Derivatives . . . . . . . . . . . . . . . . . . . . 13 71 3.4.1 . . . . . . . . . . . . . . . . . . 13 72 3.4.2 . . . . . . . . . . . . . . . . . . . 13 73 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Database Replication . . . . . . . . . . . . . . . . . . . . . 18 75 5.1 ECONREP Model . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2 ECONREP Formal Syntax . . . . . . . . . . . . . . . . . . 19 77 6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 24 78 6.1 Application Service Label . . . . . . . . . . . . . . . . 24 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 80 8. Internationalization Considerations . . . . . . . . . . . . . 26 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 82 9.1 XML Namespace URN Registration . . . . . . . . . . . . . . 27 83 9.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 27 84 9.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 28 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 10.1 Normative References . . . . . . . . . . . . . . . . . . . 29 87 10.2 Informative References . . . . . . . . . . . . . . . . . . 29 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 89 A. Object Signing . . . . . . . . . . . . . . . . . . . . . . . . 31 90 Intellectual Property and Copyright Statements . . . . . . . . 32 92 1. Requirements notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [5]. 98 2. Introduction 100 This document describes a protocol for taking location information 101 compatible with PIDF-LO [8] and passing it to an IRIS [3] server 102 using an XML schema specific to the task of returning emergency 103 service contact URIs. These URIs may be of multiple forms, including 104 sip, xmpp, and tel, and multiple URIs may be returned to a single 105 query. This document does not presume that this activity takes place 106 at any specific point in a call flow. It is a feature of the overall 107 system of which this forms a part that multiple entities may request 108 the lookup and perform the substitution of the emergency service 109 contact URI. 111 This document names this protocol usage "ECON", short for Emergency 112 Contact. The features of ECON are: 114 o Supports queries using civic as well as geospatial location 115 information. 117 o Can be used in both recursive and iterative resolution. 119 o Through the re-use of an existing protocol, contains search- 120 oriented directory semantics. 122 o Can be used for civic address validation. 124 o Hierarchical deployment of ECON services is independent of civic 125 location labels. 127 o Can communicate erroneous requests to facillitate debugging and 128 proper user feedback while simultaneously providing best-effort 129 answers. 131 2.1 Usage 133 The intended usage of this protocol (ECON) is a simple client query 134 to a server that yields a result. The result may contain a URI for a 135 single contact method or URIs for multiple contact methods, a 136 reference to another server to which the client should send a query, 137 and error messages indicating problems with interpretation of 138 location information. The combination of these components are left 139 to the needs and policy of the jurisdiction where the server is being 140 operated. 142 The framing and formalization of these results are accomplished with 143 XML using the IRIS [3] framework. Though IRIS may be used with 144 multiple transfer protocols, this specification intends to target 145 small XML interactions and stateless transactions so that the UDP- 146 based transfer protocol LWZ [9] may be employeed for fast response 147 times. 149 2.2 Discovery 151 Discovery of ECON services is to be provided by network elements 152 local to the client, hopefully via the same mechanisms providing 153 clients with location information. For instance, clients may obtain 154 their location information via DHCP using optional civic or location 155 request methods. Therefore, DHCP could also be used to provide 156 clients a reference to the most appropriate ECON server. 158 2.3 A Simple Example 160 After performing link layer attachment, an end host performs stateful 161 address autoconfiguration (in our example) using DHCP. DHCP provides 162 the end host with civic location information (encoded in UTF-8 163 format): 165 +--------+---------------+ 166 | CAtype | CAvalue | 167 +--------+---------------+ 168 | 0 | US | 169 | 1 | New York | 170 | 3 | New Yor | 171 | 6 | Broadway | 172 | 22 | Suite 75 | 173 | 24 | 10027-0401 | 174 +--------+---------------+ 176 Figure 1: DHCP Civic Example 178 Additionally, DHCP provides information about the ECON server that 179 has to be contacted. An additional step of indirection is possible, 180 for example by referring to a domain name that has to be resolved to 181 one or multiple IP addresses referring to ECON servers). 183 When the user wants to make an emergency call (seeking help from the 184 police) the following protocol interaction takes place using UDP- 185 based transfer protocol LWZ. The client encapsulates the received 186 civic location information into XML and puts it into a UDP packet. 187 The header represents information from IRIS, as detailed in LWZ [9]. 188 The search query is constructed according to Section 4. The message 189 flow is shown below. 191 C: (request packet) 192 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 193 C: 0x03 0xA4 (transaction ID=932) 194 C: 0x05 0xDA (maximum response size=1498) 195 C: 0x09 (authority length=9) 196 C: (authority="localhost") 197 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 198 C: (IRIS XML request) 199 C: 200 C: 201 C: 202 C: 203 C: 205 C: 206 C: 207 C: US 208 C: New York 209 C: New York 210 C: Broadway 211 C: 123 212 C: Suite 75 213 C: 10027-0401 214 C: 215 C: 216 C: sos.police 217 C: 218 C: 219 C: 220 C: 221 C: 222 C: 224 Figure 2 226 Since the contacted ECON server has the requested information 227 available the following response message is returned. The response 228 indicates, as a human readable display string that the 'New York City 229 Police Department' is responsible for the given geographical area. 230 The indicated URI allows the user to start SIP based communication. 232 S: (response packet) 233 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 234 S: 0x03 0xA4 (transaction ID=932) 235 S: (IRIS XML response) 236 S: 237 S: 238 S: 239 S: 240 S: 241 S: 244 S: 245 S: 246 S: New York City Police Department 247 S: 248 S: sos.police 249 S: 250 S: sip:nypd@example.com 251 S: xmpp:nypd@example.com 252 S: 253 S: 254 S: 255 S: 256 S: 257 S: 258 S: 259 S: 260 S: 262 2.4 Deployment Methods 264 Because services for emergency contact resolution may differ 265 depending jurisdiction need, this document only specifies the "wire 266 format" for ECON services and explicitly leaves open the possibility 267 for many different types of deployment. 269 For instance: 271 During discovery, a client may be directed to issue all queries to 272 an ECON service completely authoritative for a given jursidiction. 274 A client may be directed to issue queries to an ECON server that 275 acts as a reflector. In such a case, the ECON server analyzes the 276 query to determine the best server to wich to refer the client. 278 Or the client may be directed to a server that performs further 279 resolution on behalf of the client. 281 An ECON service may also be represented by multiple ECON servers, 282 either grouped together or at multiple network locations. Section 5 283 discusses database replication of ECON data to multiple servers. 284 Using S-NAPTR [11], clients may be given a list of multiple servers 285 to which queries can be sent for a single service. 287 For instance, the service at emergency.example.com may advertise ECON 288 service at local1.emergency.example.com, 289 local2.emergency.example.com, and master.emergency.example.com. Each 290 server may given a different preference. In this case, 'local1' and 291 'local2' may be given a lower preference (more preferred) than 292 'master', which might be a busier server or located further away. 294 +-----------+ pref 10 +-----------+ 295 | |-------------------->+ | 296 | client |------ | local1 | 297 | |--- \ | | 298 +-----------+ \ \ +-----------+ 299 \ \ 300 \ \ +-----------+ 301 \ \ pref 10 | | 302 \ --------->| local2 | 303 \ | | 304 \ +-----------+ 305 \ 306 \ +-----------+ 307 \ pref 20 | | 308 ------------------------->| master | 309 | | 310 +-----------+ 312 For scenarios requiring redirection, a contact ECON server can 313 instruct the client to redirect the query to another ECON server. If 314 a client were to issue a query (such as the one in Figure 2), the 315 responding ECON server could redirect the client to another ECON 316 server with the following response: 318 S: (response packet) 319 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 320 S: 0x03 0xA4 (transaction ID=932) 321 S: (IRIS XML response) 322 S: 323 S: 324 S: 325 S: 326 S: 327 S: 328 S: 329 S: 331 S: 332 S: 333 S: US 334 S: New York 335 S: New York 336 S: Broadway 337 S: 123 338 S: Suite 75 339 S: 10027-0401 340 S: 341 S: 342 S: sos.police 343 S: 344 S: 345 S: 346 S: 347 S: 348 S: 349 S: 350 S: 351 S: 352 S: 354 Finally, some deployment scenarios may find it necessary to minimize 355 the number of packets sent across the network for reasons of 356 performance. Given the same bootstrap process in Section 2.3, the 357 client would be given the following URIs: 359 +--------------+-----------------------------+ 360 | Purpose Type | URI Value | 361 +--------------+-----------------------------+ 362 | 8 | iris.lwz:econ1//192.0.2.11/ | 363 | 9 | iris.lwz:econ1//192.0.2.22/ | 364 | 10 | iris.lwz:econ1//192.0.2.33/ | 365 | 11 | iris.lwz:econ1//192.0.2.44/ | 366 +--------------+-----------------------------+ 368 Figure 6: DHCP URI Example 370 For the sake of redundancy, multiple URIs may be given pointing to 371 different servers or one URI may be given utilizing an anycast IP 372 address routing to multiple servers. Utilizing either method, there 373 is only one round-trip to map a location to a URI. 375 3. Schema Description 377 IRIS [3] requires the derivation of both query and result elements by 378 a registry schema. These descriptions follow. 380 References to XML elements without a namespace qualifier are from the 381 schema defined in this document. References to elements and 382 attributes with the "iris" XML namespace qualifier are from the 383 schema defined in IRIS [3]. Reference to elements and attributes 384 with the "civilLoc" XML namespace qualifier are from the civil 385 location schema defined in PIDF-LO [8]. References to elements and 386 attributes with the "gml" XML namespace qualifier are from the GML 387 [7]. 389 The descriptions contained within this section refer to XML elements 390 and attributes and their relation to the exchange of data within the 391 protocol. These descriptions also contain specifications outside the 392 scope of the formal XML syntax. This section will use terms defined 393 by RFC 2119 to describe these. While reading this section, please 394 refer below for needed details on the formal XML syntax. 396 3.1 Query Derivatives 398 3.1.1 Query 400 The query allows a client to search for an 401 emergency contact using civic information. Civic information is 402 communicated via a element defined in the 403 urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc namespace defined by 404 the civil location schema in PIDF-LO [8]. 406 This query may also have a element as defined in 407 Section 3.2. 409 Finally, this query has an optional 'validate' attribute that can 410 either be true or false (the default is false). This attribute 411 indicates that the query is being performed for validation purposes. 413 3.1.2 Query 415 The query allows a client to search for an emergency 416 contact using geo-spatial location information. This geo-spatial 417 information is communicated via a element defined by GML 418 [7]. 420 This query may also have a element as defined in 421 Section 3.2. 423 Finally, this query has an optional 'validate' attribute that can 424 either be true or false (the default is false). This attribute 425 indicates that the query is being performed for validation purposes. 427 3.1.3 Query 429 The query allows a client to obtain a list of 430 emergency services supported by an ECON server. Like the other 431 queries, it to has a 'validate' attribute that can either be true or 432 false (the default is false). 434 3.2 Service Types 436 Types of emergency service are specified by the element. 437 Its well-known values are: 439 1. sos.fire 441 2. sos.police 443 3. sos.medical 445 This information is provided as a hint from the client to the server 446 and is not intended to produce no results should the 447 element not be given or if its specified type is not available. In 448 other words, servers MUST ignore this information if it would cause 449 no result to be returned. 451 The purpose of defining a well-known list for this element is so that 452 these tokens may be localized by client user interfaces. However, 453 ECON servers may recognize other tokens and may pass them back via 454 the query. 456 3.3 Result Derivatives 458 3.3.1 Result 460 The result describes the URIs to be used to reach 461 an emergency contact. It may have an optional element 462 and element (see Section 3.2 which may be used by user 463 agents for user feedback purposes. 465 The primary information relayed in this result are URIs to be used to 466 make contact with emergency services. This result may contain 467 multiple URIs. These URIs are not provided in preference order, and 468 clients MUST NOT attach preference to any URI based upon its position 469 in the list. Server MUST NOT provide more than one URI of the same 470 URI scheme in a result (e.g. two "sip:" URIs are not allowed). The 471 purpose of providing multiple URIs is to offer multiple methods of 472 contact. 474 This query has an optional 'timeToLive' attribute which expresses the 475 number of minutes a client SHOULD wait before requerying the ECON 476 server if the client's location has not changed. For clients with 477 knowledge of their geo-spatial location, this query may also contain 478 a element as defined by GML [7]. This polygon indicates to 479 the client that the server considers a location change to mean that 480 the client has moved outside of the polygon. 482 3.3.2 Result 484 The result describes an emergency service provided 485 by the ECON server. It consists of a display name and a 486 element as found in Section 3.2. 488 3.4 Error Derivatives 490 The following errors indicate that either a civic address or geo- 491 spatial location were in some way invalid. These errors provide for 492 free form text to further explain the error. 494 3.4.1 496 Servers may use the error to inform clients of 497 semantically invalid civil address information sent in a query. When 498 the validate attribute on the query was set to true, a server MAY 499 return this error when the CivicData provided is not recognized as 500 valid even if the data provided would normally have returned a URI or 501 set of URIs. This can occur, for example, when an invalid street 502 name or number is provided but the algorithm for determining the 503 correct URI is satisfied when a valid county is provided. This 504 facility will normally only be used in debugging and by technical 505 professionals; it is not recommended outside of that context. 507 3.4.2 509 Servers may use the error to inform clients of 510 semantically invalid geo-spatial data sent in a query. When the 511 validate attribute on the query was set to true, a server MAY return 512 this error when the GeoData provided is not recognized as valid even 513 if the data provided would normally return a URI or set of URIs. 514 This facility will normally only be used in debugging and by 515 technical professionals; it is not recommended outside of that 516 context. 518 4. Formal Syntax 520 This registry schema is specified in the XML Schema notation (see [1] 521 and [2]). The formal syntax presented here is a complete schema 522 representation suitable for automated validation of an XML instance 523 when combined with the formal schema syntax of IRIS [3], PIDF-LO [8] 524 Civil Location, and GML [7]. 526 527 536 537 539 541 542 543 A schema for finding Emergency Contacts (ECON) 544 using the Internet Registry Information Service (IRIS) 545 546 548 549 550 552 553 554 555 556 558 560 561 563 564 566 568 572 573 574 575 576 578 580 581 583 584 585 587 591 592 593 594 596 597 598 600 604 605 606 608 609 610 611 612 615 617 618 621 622 624 625 626 628 632 633 634 635 636 638 640 641 642 643 645 649 650 651 653 657 661 662 Figure 7: econ.xsd 664 5. Database Replication 666 Local copies of the emergency contact database will need to have data 667 replicated from a master copy of the emergency contact database. 668 Three methods may be employeed to conduct this database replication: 670 1. Database contents may be serialized to a file using the format 671 specified in Section 5 of IRIS [3]. These files may then be 672 transfered using FTP or other appropriate file transfer 673 protocols. 675 2. Periodic and incremental database replication may be accomplished 676 using the ECONREP schema provided in Section 5.1. 678 3. Native database replication methods found with many commercial 679 and/or highly scalable database management systems may be used as 680 appropriate. 682 5.1 ECONREP Model 684 This section describes a method for replicating ECON databases using 685 a distinct IRIS profile. This is not the only mechanism for database 686 replication and any other method that produces synchronization of the 687 required atomicity and freshness is permitted. ECONREP has the 688 following characteristics: 690 o Replication may occur incrementally. 692 o Changes to ECON data may be replicated to local copies before the 693 effective date of the changes. 695 o Replication requests may conducted over XPC [10] allowing the 696 server to retain lower protocol overhead when transfering large 697 quantities of data. 699 o It is a distinctly different set of queries and results for the 700 purpose of database replication and does not muddle the semantics 701 of the ECON query and response semantics used between an ECON 702 client and an ECON service. 704 Utilizing ECONREP, local copies periodically query the master copy 705 for a list of changes. The master may reply with the entire list of 706 changes or may only provide a partial list of changes and inform the 707 local copy to requery later for the remainder of the change list. 709 The queries used to conduct replication are 710 and , for civic addresses and geospatial 711 locations respectively. Both queries take three parameters: a 712 location (either geospatial or civic), an emergency service type, and 713 starting synchronization point (expressed either as a date or as a 714 starting change set). 716 Depending on the query, the server will return a series of 717 results or results. Both types of result 718 have the following components: the change set to which they belong, 719 the effective date for the change (may be in the future), a list of 720 covered locations, and the emergency contact for the covered 721 locations. The effective date allows replication of future changes 722 to the data. Its absence means the change is to be effective 723 immediately. 725 A change set is composed of two values, a serial number and a set 726 number. The serial number indicates an overall version of the 727 database. The set number is used to group results together in sets. 728 The method used to group sets of results is implementation dependent, 729 however this is the key used by the client to indicate the last set 730 of data that was replicated. Entire change sets SHOULD be set at one 731 time. 733 If a master becomes too busy or wishes to incrementally replicate 734 data for other reasons, it may issue a error. 735 This can be done after sending change sets in a response, such as: 737 response 739 change set 1 741 change set 2 743 change set 3 745 replication limit 747 The error may have an optional 'backOff' attribute 748 indicating the number of minutes that should elapse before a 749 subsequent replication query is attempted. 751 5.2 ECONREP Formal Syntax 753 This registry schema is specified in the XML Schema notation (see [1] 754 and [2]). The formal syntax presented here is a complete schema 755 representation suitable for automated validation of an XML instance 756 when combined with the formal schema syntax of IRIS [3], ECON, 757 PIDF-LO [8] Civil Location, and GML [7]. 759 760 770 771 772 774 776 777 778 A schema for replicating Emergency Contact (ECON) 779 data stores. 780 781 783 784 785 787 788 789 790 791 794 796 797 798 800 801 802 803 804 805 809 810 811 812 813 816 818 819 820 822 823 824 825 826 828 832 833 835 837 839 840 841 843 844 845 846 847 849 851 852 853 854 858 859 862 863 864 866 867 868 869 871 875 876 877 878 879 881 883 884 885 886 890 891 892 893 895 896 897 898 900 904 905 906 908 909 910 911 913 914 915 917 921 923 Figure 8: econrep.xsd 925 6. URI Resolution 927 6.1 Application Service Label 929 The application service label associated with ECON MUST be "ECON1". 930 This is the abbreviated form of the URN for this registry type, 931 urn:ietf:params:xml:ns:econ1. 933 The application service label associated with ECONREP MUST be 934 "ECON1REP1". This is the abbreviated form of the URN for this 935 registry type, urn:ietf:params:xml:ns:econ1rep1. 937 7. Security Considerations 939 There are multiple threats to the overall system of which this forms 940 a part. An attacker that can obtain emergency service contact URIs 941 can use those URIs to attempt to disrupt emergency services. An 942 attacker that can prevent the lookup of contact URIs can hinder the 943 request of emergency services. An attacker that can eavesdrop on the 944 communication requesting this lookup can surmise the existence of an 945 emergency and possibly its nature, and may be able to use this as a 946 springboard to a physical attack. 948 8. Internationalization Considerations 950 Implementers should be aware of considerations for 951 internationalization in IRIS [3]. 953 9. IANA Considerations 955 9.1 XML Namespace URN Registration 957 This document makes use of a proposed XML namespace and schema 958 registry specified in XML_URN [6]. Accordingly, the following 959 registration information is provided for the IANA regarding ECON: 961 o URN/URI: 963 * urn:ietf:params:xml:ns:econ1 965 o Contact: 967 * Andrew Newton 969 * Ted Hardie 971 o XML: 973 * The XML Schema specified in Section 4 975 This document makes use of a proposed XML namespace and schema 976 registry specified in XML_URN [6]. Accordingly, the following 977 registration information is provided for the IANA regarding ECONREP: 979 o URN/URI: 981 * urn:ietf:params:xml:ns:econ1rep1 983 o Contact: 985 * Andrew Newton 987 * Ted Hardie 989 o XML: 991 * The XML Schema specified in Section 5.2 993 9.2 S-NAPTR Registration 995 The following S-NAPTR application service labels will need to be 996 registered with IANA according to the IANA considerations defined in 997 IRIS [3]: 999 ECON1 1001 ECON1REP1 1003 9.3 BEEP Registration 1005 The following BEEP Profile URIs are to be registeried with IANA, in 1006 addition to the registration provided in IRIS-BEEP [4]. 1008 http://iana.org/beep/iris1/econ1 1010 http://iana.org/beep/iris1/econ1rep1 1012 10. References 1014 10.1 Normative References 1016 [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 1017 W3C XML Schema, October 2000, 1018 . 1020 [2] World Wide Web Consortium, "XML Schema Part 1: Structures", 1021 W3C XML Schema, October 2000, 1022 . 1024 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 1025 RFC 3891, January 2005. 1027 [4] Newton, A. and M. Sanz, "Internet Registry Information Service 1028 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 1029 RFC 3893, January 2005. 1031 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1032 Levels", RFC 2119, BCP 14, March 1997. 1034 [6] Mealling, M., "The IETF XML Registry", 1035 draft-mealling-iana-xmlns-registry-03 (work in progress), 1036 November 2001. 1038 [7] OpenGIS, "Open Geography Markup Language (GML) Implementation 1039 Specification", OGC OGC 02-023r4, January 2003. 1041 [8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 1042 draft-ietf-geopriv-pidf-lo-03 (work in progress), 1043 September 2004. 1045 10.2 Informative References 1047 [9] Newton, A., "A Lightweight UDP Transport for IRIS", 1048 draft-ietf-crips-iris-lwz-03 (work in progress), June 2005. 1050 [10] Newton, A., "XML Pipelining with Chunks", 1051 draft-ietf-crips-iris-xpc-01 (work in progress), June 2005. 1053 [11] Daigle, L. and A. Newton, "Domain-Based Application Service 1054 Location Using SRV RRs and the Dynamic Delegation Discovery 1055 Service (DDDS)", RFC 3958, January 2005. 1057 Authors' Addresses 1059 Ted Hardie 1060 Qualcomm, Inc. 1062 Andrew Newton 1063 Verisign, Inc. 1065 Hannes Tschofenig 1066 Siemens 1068 Appendix A. Object Signing 1070 The authors considered several mechanisms for attaching digital 1071 signatures to one or more parts of the ECON response. After this 1072 consideration, they were all rejected. The authors believe that the 1073 mechanisms available to check the validity of the digital signature 1074 are too heavyweight for the use cases in which the query is made 1075 immediately prior to an emergency call. In those cases, the authors 1076 believe that the rational response is to attempt the emergency call 1077 whether the digital signature is valid or invalid. Further, we 1078 believe that the check could add significant time and network round 1079 trips to the call set-up, which is clearly undesirable in this case. 1081 Other use cases, for validation or replication, might benefit from 1082 object signatures, but they have been omitted at this time as 1083 requiring more implementation and deployment resources than are 1084 justified by the return. Details on lightweight mechanisms which 1085 might change the value of digital signatures for one or more of these 1086 use cases would be welcomed by the authors. 1088 Intellectual Property Statement 1090 The IETF takes no position regarding the validity or scope of any 1091 Intellectual Property Rights or other rights that might be claimed to 1092 pertain to the implementation or use of the technology described in 1093 this document or the extent to which any license under such rights 1094 might or might not be available; nor does it represent that it has 1095 made any independent effort to identify any such rights. Information 1096 on the procedures with respect to rights in RFC documents can be 1097 found in BCP 78 and BCP 79. 1099 Copies of IPR disclosures made to the IETF Secretariat and any 1100 assurances of licenses to be made available, or the result of an 1101 attempt made to obtain a general license or permission for the use of 1102 such proprietary rights by implementers or users of this 1103 specification can be obtained from the IETF on-line IPR repository at 1104 http://www.ietf.org/ipr. 1106 The IETF invites any interested party to bring to its attention any 1107 copyrights, patents or patent applications, or other proprietary 1108 rights that may cover technology that may be required to implement 1109 this standard. Please address the information to the IETF at 1110 ietf-ipr@ietf.org. 1112 Disclaimer of Validity 1114 This document and the information contained herein are provided on an 1115 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1116 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1117 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1118 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1119 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1120 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1122 Copyright Statement 1124 Copyright (C) The Internet Society (2005). This document is subject 1125 to the rights, licenses and restrictions contained in BCP 78, and 1126 except as set forth therein, the authors retain all their rights. 1128 Acknowledgment 1130 Funding for the RFC Editor function is currently provided by the 1131 Internet Society.