idnits 2.17.1 draft-thomson-webpush-http2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 12, 2014) is 3422 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. 'CAP-URI' == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-01 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBPUSH M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track December 12, 2014 5 Expires: June 15, 2015 7 Generic Event Delivery Using HTTP Push 8 draft-thomson-webpush-http2-02 10 Abstract 12 A simple protocol for the delivery of realtime events to clients is 13 described. This scheme uses HTTP/2 server push. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on June 15, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 6 53 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Subscribing . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 7 56 6. Receiving Push Messages . . . . . . . . . . . . . . . . . . . 8 57 7. Operational Considerations . . . . . . . . . . . . . . . . . 9 58 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 9 59 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 10 60 7.3. Registration and Subscription Expiration . . . . . . . . 10 61 7.4. Implications for Application Reliability . . . . . . . . 11 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 8.1. Confidentiality from Push Service Access . . . . . . . . 11 64 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 12 65 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 66 8.4. Denial of Service Considerations . . . . . . . . . . . . 13 67 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 14 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 72 11.2. Informative References . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 Mobile computing devices are increasingly relied upon for a great 78 many applications. Mobile devices typically have limited power 79 reserves, so finding more efficient ways to serve application 80 requirements is an important part of any mobile platform. 82 One significant contributor to power usage mobile devices is the 83 radio. Radio communications consumes a significant portion of the 84 energy budget on a wirelessly connected mobile device. 86 Many applications require continuous access to network communications 87 so that real-time events - such as incoming calls or messages - can 88 be conveyed (or "pushed") to the user in a timely fashion. 89 Uncoordinated use of persistent connections or sessions from multiple 90 applications can contribute to unnecessary use of the device radio, 91 since each independent session independently incurs overheads. In 92 particular, keep alive traffic used to ensure that middleboxes do not 93 prematurely time out sessions, can result in significant waste. 95 Maintenance traffic tends to dominate over the long term, since 96 events are relatively rare. 98 Consolidating all real-time events into a single session ensures more 99 efficient use of network and radio resources. A single service 100 consolidates all events, distributing those events to applications as 101 they arrive. This requires just one session, avoiding duplicated 102 overhead costs. 104 The W3C Web Push API [API] describes an API that enables the use of a 105 consolidated push service from web applications. This expands on 106 that work by describing a protocol that can be used to: 108 o request the delivery of a push message to a user agent, 110 o register a new user agent, 112 o create new push message delivery subscriptions, and 114 o monitor for new push messages. 116 This is intentionally split into these two categories because 117 requesting the delivery of events is required for immediate use by 118 the Web Push API. The registration, management and monitoring 119 functions are currently fulfilled by proprietary protocols; these are 120 adequate, but do not offer any of the advantages that standardization 121 affords. 123 The monitoring function described in this document is intended to be 124 replaceable, enabling the use of monitoring schemes that are better 125 optimized for the network environment and the user agent. For 126 instance, using notification systems like the 3GPP Short Message 127 Service (SMS) [TS.3GPP.23.040] can take advantage of the native 128 paging capabilities of a cellular network, avoiding the ongoing 129 maintainence cost of a persistent TCP connection. 131 This document intentionally does not describe how a push service is 132 discovered. Discovery of push services is left for future efforts, 133 if it turns out to be necessary at all. User agents are expected to 134 be configured with a URL for a push service. 136 Similarly, discovery of support for and negotiation of use of 137 alternative monitoring schemes is left to documents that extend this 138 basic protocol. 140 1.1. Conventions and Terminology 142 In cases where normative language needs to be emphasized, this 143 document falls back on established shorthands for expressing 144 interoperability requirements on implementations: the capitalized 145 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 146 is described in [RFC2119]. 148 This document defines the following terms: 150 application: Both the sender and ultimate consumer of push messages. 151 Many applications have components that are run on a user agent and 152 other components that run on servers. 154 application server: The component of an application that runs on a 155 server and requests the delivery of a push message. 157 push message: A message, sent from an application server to a user 158 agent via a push service. 160 push service: A service that delivers push messages to user agents. 162 registration: A session that is established between the user agent 163 and the push service. A registation has any number of associated 164 subscriptions. 166 subscription: A message delivery context that is established between 167 the user agent and the push service and shared with applications. 168 All push messages are associated with a subscription. 170 user agent: A device and software that is the recipient of push 171 messages. 173 Examples in this document use the HTTP/1.1 message format [RFC7230]. 174 Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 175 is necessary, the more verbose frame format from 176 [I-D.ietf-httpbis-http2] is used. 178 2. Overview 180 A general model for push services includes three basic actors: a user 181 agent, a push service, and an application (server). 183 +-------+ +--------------+ +-------------+ 184 | UA | | Push Service | | Application | 185 +-------+ +--------------+ +-------------+ 186 | | | 187 | Register | | 188 |--------------------->| | 189 | Monitor | | 190 |<====================>| | 191 | Subscribe | | 192 |--------------------->| | 193 | Provide Subscription | 194 |-------------------------------------------->| 195 | | | 196 : : : 197 | | Push Message | 198 | Push Message |<---------------------| 199 |<---------------------| | 200 | | | 202 At the very beginning of the process, the device creates a 203 registration resource at the push service. The registration is the 204 basis of all future interactions between the user agent and push 205 service. The registration aggregates push messages that the user 206 agent receives from all subscriptions. 208 The registration resource describes how the user agent is expected to 209 monitor for incoming push messages. This document describes one such 210 mechanism, though more efficient means of monitoring could be 211 defined. 213 The registration resource also describes how the user agent might 214 create a subscription. A new subscription is created by the user 215 agent and then distributed by to an application server. 217 It is expected that a different subscription will be provided to each 218 application; however, there are no inherent cardinality constraints 219 in the protocol. Multiple subscriptions might be created for the 220 same application, or multiple applications could use the same 221 subscription. Note however that sharing subscriptions can have 222 security and privacy implications. 224 Application servers use subscriptions to deliver push messages to 225 devices, via the push service. 227 Both registrations and subscriptions have a limited lifetime. They 228 can also be terminated by either push service or user agent at any 229 time. User agents and application servers need to be prepared to 230 handle changes in registrations and subscriptions; the protocol 231 described here supports any number of either resource concurrently 232 with minimal overhead. 234 2.1. HTTP Resources 236 This protocol uses HTTP resources [RFC7230] and link relations 237 [RFC5988]. The following resources are defined: 239 push service: This resource is used in Registration (Section 3). It 240 is configured into user agents. 242 registration: A link relation of type "urn:ietf:params:push:reg" 243 refers to a registration resource. This resource is used by a 244 user agent in requesting the delivery of push messages. A process 245 for monitoring for messages using this resource is described in 246 Section 6. 248 subscribe: A link relation of type "urn:ietf:params:push:sub" refers 249 to a resource where a user agent can create new subscriptions. 250 Creating a subscription is described in Section 4. 252 subscription: A link relation of type "urn:ietf:params:push" refers 253 to a subscription resource. Subscription resources are used to 254 deliver push messages. An application server sends push messages 255 (Section 5) and a user agent receives push messages (Section 6) 256 using this resource. 258 3. Registration 260 A user agent that wishes to establish a new or replacement 261 registration sends an HTTP POST request to its configured push 262 service resource. 264 A request to create a registration contains no entity body. A future 265 specification MAY define a format and semantics for the entity body 266 on this request. 268 The push service creates a new registration and subscribe resource in 269 response to this request. URIs for these resources are included in 270 Link header fields in the response. The push server includes the 271 "registration" link relation in a Location header field. 273 For example, the following request requests the creation of a new 274 registration: 276 POST /register HTTP/1.1 277 Host: push.example.net 278 The following response might be generated in response to this 279 request: 281 HTTP/1.1 201 Created 282 Date: Thu, 11 Dec 2014 23:56:47 GMT 283 Link: ; 284 rel="urn:ietf:params:push:reg" 285 Link: ; 286 rel="urn:ietf:params:push:sub" 287 Location: https://push.example.net/reg/1G_GIPMorg_n-IrQvqZr6g 288 Cache-Control: max-age=8640000, private 290 The push server SHOULD provide a URI for the associated "subscribe" 291 resource and any known expiration information in response to requests 292 to the "registration" resource. 294 4. Subscribing 296 A client sends a POST request to the "subscribe" resource to create a 297 new subscription. 299 POST /subscribe/1G_GIPMorg_n-IrQvqZr6g HTTP/1.1 300 Host: push.example.net 302 A response with a 201 (Created) status code includes a URI for the 303 subscription in the Location header field. 305 HTTP/1.1 201 Created 306 Date: Thu, 11 Dec 2014 23:56:52 GMT 307 Link:

; 308 rel="urn:ietf:params:push" 309 Location: https://push.example.net/p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 310 Cache-Control: max-age:864000, private 312 5. Requesting Push Message Delivery 314 A push subscription is an HTTP resource [RFC7230]. 316 An application server requests the delivery of a push message by 317 sending an HTTP PUT request to this resource, including the push 318 message in the body of the request. 320 PUT /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 321 Host: push.example.net 322 Content-Type: text/plain;charset=utf8 323 Content-Length: 15 325 Hello, World! 327 A simple 200 response is sufficient to indicate that the push message 328 was accepted. This does not indicate that the message was delivered 329 to the user agent. 331 HTTP/1.1 200 OK 332 Date: Thu, 11 Dec 2014 23:56:55 GMT 333 Cache-Control: max-age=600 335 A push service MAY generate a 413 (Payload Too Large) status code in 336 response to PUT requests that include an entity body that is too 337 large. Push services MUST NOT generate a 413 status code in 338 responses to an entity body that is 4k (4096 bytes) or less in size. 340 A push service that does not store messages can stream the payload of 341 push messages to the user agent. Flow control SHOULD be used to 342 limit the state commitment for delivery of large messages. 344 6. Receiving Push Messages 346 A user agent requests the delivery of new push messages by making a 347 GET request to the "registration" resource. The push service does 348 not respond to this request, it instead uses HTTP/2 server push 349 [I-D.ietf-httpbis-http2] to send the contents of push messages as 350 they are sent by application servers. 352 Each push message is pushed in response to a synthesized GET request. 353 The GET request is made to the same "subscription" URI that is used 354 by the application server to send the message. The response body is 355 the entity body from the most recent PUT request sent to the 356 subscription resource. 358 The following example request is made over HTTP/2. 360 HEADERS [stream 7] +END_STREAM +END_HEADERS 361 :method = GET 362 :path = /monitor/1G_GIPMorg_n-IrQvqZr6g 363 :authority = push.example.net 365 The push service permits the request to remain outstanding. When a 366 push message is sent by an application server, a server push is 367 associated with the initial request. The response includes the push 368 message. 370 PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS 371 :method = GET 372 :path = /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 373 :authority = push.example.net 375 HEADERS [stream 4] +END_HEADERS 376 :status = 200 377 date = Thu, 11 Dec 2014 23:56:55 GMT 378 last-modified = Thu, 11 Dec 2014 23:56:55 GMT 379 cache-control = private 380 content-type = text/plain;charset=utf8 381 content-length = 15 383 DATA [stream 4] +END_STREAM 384 Hello World!\r\n 386 A user agent can request the contents of the "registration" resource 387 immediately by including a Prefer header field [RFC7240] with a 388 "wait" parameter set to "0". The push server SHOULD return a link 389 reference to the "registration" resource and expiration information 390 in response to this request. This request also triggers the delivery 391 of all push messages that the push service has stored but not yet 392 delivered. 394 A user agent can request the last push message for a "subscription" 395 resource by sending GET requests to its URI. A 200 (OK) status 396 response contains the last push message sent to the subscription. A 397 204 (No Content) status code indicates that no messages are presently 398 available. 400 7. Operational Considerations 402 A push service is likely to have to maintain a very large number of 403 open TCP connections. Effective management of those connections can 404 depend on being able to move connections between server instances. 406 7.1. Load Management 408 A user agent MUST support the 307 (Temporary Redirect) status code 409 [RFC7231], which can be used by a push service to redistribute load 410 at the time that a new registration is requested. 412 A server that wishes to redistribute load can do so using the 413 alternative services mechanisms that are part of HTTP/2 414 [I-D.ietf-httpbis-alt-svc]. Alternative services allows for 415 redistribution of load whilst maintaining the same URIs for various 416 resources. User agents can ensure a graceful transition by using the 417 GOAWAY frame once it has established a replacement connection. 419 7.2. Push Message Expiration 421 Push services typically store messages for some time to allow for 422 limited recovery from transient faults. If a push message is stored, 423 but not delivered, the push service can indicate the probable 424 duration of storage by including expiration information in the 425 response to the push request. 427 A push service is not obligated to store messages indefinitely. If a 428 user agent is not actively monitoring for push messages, those 429 messages can be lost or overridden by newer messages on the same 430 subscription. 432 Push messages that were stored and not delivered to a client are 433 delivered when a client recommences monitoring. Stored push messages 434 SHOULD include a Last-Modified header field (see Section 2.2 of 435 [RFC7232]) indicating when delivery was requested by an application 436 server. 438 A GET request to a "subscription" resource that has expired messages 439 results in a 204 (No Content) status response, equivalent to if no 440 push message were ever sent. 442 Push services might need to limit the size and number of stored push 443 messages to avoid overloading. In addition to using the 413 (Payload 444 Too Large) status code for too large push messages, a push service 445 MAY expire push messages prior to any advertised expiration time. 447 7.3. Registration and Subscription Expiration 449 In some cases, it may be necessary to terminate registrations or 450 subscriptions so that they can be refreshed. 452 A push service might choose to set a fixed expiration time. If a 453 resource has a known expiration time, expiration information is 454 included in responses to requests that create the resource, or in 455 requests that retrieve a representation of the resource. 457 Expiration is indicated using either the Expires header field, or by 458 setting a "max-age" parameter on a Cache-Control header field (see 460 [RFC7234]). The Cache-Control header field MUST also include the 461 "private" directive. 463 A push service can invalidate a registration or subscription at any 464 time. If a user agent has an outstanding request to the 465 "registration" resource (see Section 6), this can be signaled by 466 returning a 400-series response code, such as 410 (Gone). A push 467 service uses server push to indicate that a subscription has expired; 468 a pushed 400-series status code for the subscription resource signals 469 the termination of a subscription. 471 A user agent can request that a registration or subscription be 472 removed by sending a DELETE request to the corresponding URI. 474 7.4. Implications for Application Reliability 476 An application developer might find it tempting to create alternative 477 mechanisms for message delivery in case the push service fails to 478 deliver a critical message. Setting up a polling mechanism or a 479 backup messaging channel in order to compensate for these 480 shortcomings negates almost all of the advantages a push service 481 provides. 483 Applications are encouraged to instead provide a means to detect 484 situations where push messages were not delivered and recover 485 gracefully. For instance, an application server might include a 486 sequence number in push messages; a gap in the sequence can then be 487 used to trigger some form of state resynchronization. For instance, 488 the missing messages might be requested from the application server 489 directly. Push service failures are expected to be rare, therefore 490 performance optimization of any recovery mechanism might be 491 unnecessary. 493 8. Security Considerations 495 This protocol MUST use HTTP over TLS [RFC2818]; this includes any 496 communications between user agent and push service, plus 497 communications between the application and the push service. Thus, 498 all URIs use the "https" scheme. This provides confidentiality and 499 integrity protection for registrations and push messages from 500 external parties. 502 8.1. Confidentiality from Push Service Access 504 The protection afforded by TLS does not protect content from the push 505 service. Without additional safeguards, a push service is able to 506 see and modify the content of the messages. 508 Applications are able to provide additional confidentiality, 509 integrity or authentication mechanisms within the push message 510 itself. The application server sending the push message and the 511 application on the user agent that receives it are frequently just 512 different instances of the same application, so no standardized 513 protocol is needed to establish a proper security context. The 514 process of providing the application server with subscription 515 information provides a convenient medium for key agreement. 517 The Web Push API codifies this practice by requiring that each push 518 subscription created by the browser be bound to a browser generated 519 encryption key. Pushed messages are authenticated and decrypted by 520 the browser before delivery to applications. This scheme ensures 521 that the push service is unable to examine the contents of push 522 messages. 524 The public key for a subscription ensures that applications using 525 that subscription can identify messages from unknown sources and 526 discard them. This depends on the public key only being disclosed to 527 entities that are authorized to send messages on the channel. The 528 push server does not require access to this public key. 530 8.2. Privacy Considerations 532 Push message confidentiality does not ensure that the identity of who 533 is communicating and when they are communicating is protected. 534 However, the amount of information that is exposed can be limited. 536 Subscription URIs MUST NOT provide any basis to correlate 537 communications for a given user agent. It MUST NOT be possible to 538 correlate any two subscription URIs based solely on the content of 539 the subscription URIs. This allows a user agent to control 540 correlation across different applications, or over time. 542 In particular, user and device information MUST NOT be exposed 543 through the subscription URI. 545 In addition, subscription URIs established by the same user agent 546 MUST NOT include any information that allows them to be correlated 547 with the associated registration or the user agent. The push service 548 is the only entity that needs to be able to correlate subscriptions 549 with a registration. 551 Note: This need not be perfect as long as the resulting anonymity 552 set (see [RFC6973], Section 6.1.1) is sufficiently large. A 553 subscription URI necessarily identifies a push service or a single 554 server instance. It is also possible that traffic analysis could 555 be used to correlate subscriptions. 557 A user agent MUST be able to create new registrations and 558 subscriptions with new identifiers at any time. 560 8.3. Authorization 562 This protocol does not define how a push service establishes whether 563 a user agent is permitted to create a registration or subscription, 564 or whether push messages can be delivered to the user agent. A push 565 service MAY choose to authorize request based on any HTTP-compatible 566 authorization method available, of which there are numerous options. 567 The authorization process and any associated credentials are expected 568 to be configured in the user agent along with the URI for the "push 569 service". 571 Authorization for sending push messages is managed using capability 572 URLs (see [CAP-URI]). A capability URL grants access to a resource 573 based solely on knowledge of the URL. Capability URLs are used for 574 their "easy onward sharing" and "easy client API" properties. These 575 make it possible to avoid relying on relationships between push 576 services and application servers, with the protocols necessary to 577 build and support those relationships. 579 A subscription URI therefore acts as a bearer token: knowledge of the 580 URI implies authorization to send push messages. Subscription URIs 581 MUST be extremely difficult to guess. Encoding a large amount of 582 random entropy (at least 120 bits) in the path component ensures that 583 it is difficult to successfully guess a valid subscription URI. 585 8.4. Denial of Service Considerations 587 Discarding unwanted messages at the user agent based on message 588 authentication doesn't protect against a denial of service attack on 589 the user agent. Even a relatively small volume of push messages can 590 cause battery-powered devices to exhaust power reserves. Limiting 591 the number of entities with access to push channels limits the number 592 of entities that can generate value push requests of the push server. 594 An application can limit where push messages can originate by 595 limiting the distribution of subscription URIs to authorized 596 entities. Ensuring that subscription URIs are hard to guess ensures 597 that only applications servers that have been given a subscription 598 URI can use it. 600 A malicious application with a valid subscription use the greater 601 resources of a push service to mount a denial of service attack on a 602 user agent. Push service SHOULD limit the rate at which push 603 messages are sent to individual user agents. A push service or user 604 agent MAY terminate subscriptions (Section 7.3) that receives too 605 many push messages. 607 End-to-end confidentiality mechanisms, such as those in [API], 608 prevent an entity with a registration URI from learning the contents 609 of push messages. In both cases, push messages that are not 610 successfully authenticated will not be delivered by the API, but this 611 can present a denial of service risk. 613 Conversely, a push service is also able to deny service to user 614 agents. Intentional failure to deliver messages is difficult to 615 distinguish from faults, which might occur due to transient network 616 errors, interruptions in device availability, or genuine service 617 outages. 619 8.5. Logging Risks 621 Server request logs can reveal registration and subscription URIs. 622 Acquiring a registration URI permits the creation of new 623 subscriptions, as well as potentially enabling the receipt of 624 messages. Acquiring a subscription URI permits the sending of push 625 messages. Logging could also reveal relationships between different 626 subscription URIs for the same registration, or between different 627 registrations for the same device. 629 Limitations on log retention and strong access control mechanisms can 630 ensure that URIs are not learned by unauthorized entities. 632 9. IANA Considerations 634 This document registers three URNs for use in identifying link 635 relation types. These are added to a new "Web Push Identifiers" 636 registry according to the procedures in Section 4 of [RFC3553]; the 637 corresponding "push" sub-namespace is entered in the "IETF URN Sub- 638 namespace for Registered Protocol Parameter Identifiers" registry. 640 The "Web Push Identifiers" registry operates under the IETF Review 641 policy [RFC5226]. 643 Registry name: Web Push Identifiers 645 URN Prefix: urn:ietf:params:push 647 Specification: (this document) 649 Respository: [Editor/IANA note: please include a link to the final 650 registry location.] 652 Index value: Values in this registry are URNs or URN prefixes that 653 start with the prefix "urn:ietf:params:push". Each is registered 654 independently. 656 New registrations in the "Web Push Identifiers" are encouraged to 657 include the following information: 659 URN: A complete URN or URN prefix. 661 Description: A summary description. 663 Specification: A reference to a specification describing the 664 semantics of the URN or URN prefix. 666 Contact: Email for the person or group making the registration. 668 Index value: As described in [RFC3553], URN prefixes that are 669 registered include a description of how the URN is constructed. 670 This is not applicable for specific URNs. 672 Three values are entered as the initial content of the "Web Push 673 Identifiers" registry. 675 URN: urn:ietf:params:push 677 Description: This link relation type is used to identify a web push 678 subscription. 680 Specification: (this document) 682 Contact: Martin Thomson (martin.thomson@gmail) or the Web Push WG 683 (webpush@ietf.org) 685 URN: urn:ietf:params:push:reg 687 Description: This link relation type is used to identify a web push 688 registration. 690 Specification: (this document) 692 Contact: Martin Thomson (martin.thomson@gmail) or the Web Push WG 693 (webpush@ietf.org) 695 URN: urn:ietf:params:push:sub 697 Description: This link relation type is used to identify a resource 698 that can be used to create new web push subscriptions. 700 Specification: (this document) 702 Contact: Martin Thomson (martin.thomson@gmail) or the Web Push WG 703 (webpush@ietf.org) 705 10. Acknowledgements 707 Significant technical input to this document has been provided by 708 Costin Manolache, Robert Sparks, Mark Nottingham, Matthew Kaufman and 709 many others. 711 11. References 713 11.1. Normative References 715 [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD 716 capability-urls, February 2014, 717 . 719 [I-D.ietf-httpbis-alt-svc] 720 Nottingham, M., McManus, P., and J. Reschke, "HTTP 721 Alternative Services", draft-ietf-httpbis-alt-svc-01 (work 722 in progress), April 2014. 724 [I-D.ietf-httpbis-http2] 725 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 726 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 727 progress), April 2014. 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997. 732 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 734 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 735 IETF URN Sub-namespace for Registered Protocol 736 Parameters", BCP 73, RFC 3553, June 2003. 738 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 739 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 740 May 2008. 742 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 744 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 745 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 746 2014. 748 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 749 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 751 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 752 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 754 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 755 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 756 2014. 758 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 760 11.2. Informative References 762 [API] Sullivan, B. and E. Fullea, "Web Push API", ED push-api, 763 December 2014, . 765 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 766 Morris, J., Hansen, M., and R. Smith, "Privacy 767 Considerations for Internet Protocols", RFC 6973, July 768 2013. 770 [TS.3GPP.23.040] 771 3GPP, "Technical realization of the Short Message Service 772 (SMS)", 3GPP TS 23.040 12.2.0, October 2014. 774 Author's Address 776 Martin Thomson 777 Mozilla 778 331 E Evelyn Street 779 Mountain View, CA 94041 780 US 782 Email: martin.thomson@gmail.com