idnits 2.17.1 draft-ietf-core-href-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 649 lines 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 date (9 March 2020) is 1499 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) == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-13 -- Possible downref: Normative reference to a draft: ref. 'RFC7049bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft Ericsson 4 Intended status: Standards Track 9 March 2020 5 Expires: 10 September 2020 7 Constrained Resource Identifiers 8 draft-ietf-core-href-03 10 Abstract 12 The Constrained Resource Identifier (CRI) is a complement to the 13 Uniform Resource Identifier (URI) that serializes the URI components 14 in Concise Binary Object Representation (CBOR) instead of a sequence 15 of characters. This simplifies parsing, comparison and reference 16 resolution in environments with severe limitations on processing 17 power, code size, and memory size. 19 Note to Readers 21 This note is to be removed before publishing as an RFC. 23 The issues list for this Internet-Draft can be found at 24 . 26 A reference implementation and a set of test vectors can be found at 27 . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 10 September 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction 63 1.1. Notational Conventions 64 2. Constraints 65 3. Creation and Normalization 66 4. Comparison 67 5. CRI References 68 5.1. CBOR Serialization 69 5.2. Reference Resolution 70 6. Relationship between CRIs, URIs and IRIs 71 6.1. Converting CRIs to URIs 72 7. Security Considerations 73 8. IANA Considerations 74 9. References 75 9.1. Normative References 76 9.2. Informative References 77 Appendix A. Change Log 78 Acknowledgements 79 Author's Address 81 1. Introduction 83 The Uniform Resource Identifier (URI) [RFC3986] and its most common 84 usage, the URI reference, are the Internet standard for linking to 85 resources in hypertext formats such as HTML [W3C.REC-html52-20171214] 86 and the HTTP "Link" header field [RFC8288]. 88 A URI reference is a sequence of characters chosen from the 89 repertoire of US-ASCII characters. The individual components of a 90 URI reference are delimited by a number of reserved characters, which 91 necessitates the use of an escape mechanism ("percent-encoding") when 92 these reserved characters are used in a non-delimiting function. The 93 resolution of URI references involves parsing a character sequence 94 into its components, combining those components with the components 95 of a base URI, merging path components, removing dot-segments, and 96 recomposing the result back into a character sequence. 98 Overall, the proper handling of URI references is relatively 99 intricate. This can be a problem, especially in constrained 100 environments [RFC7228] where nodes often have severe code size and 101 memory size limitations. As a result, many implementations in such 102 environments support only an ad-hoc, informally-specified, bug- 103 ridden, non-interoperable subset of half of RFC 3986. 105 This document defines the Constrained Resource Identifier (CRI) by 106 constraining URIs to a simplified subset and serializing their 107 components in Concise Binary Object Representation (CBOR) 108 [RFC7049bis] instead of a sequence of characters. This allows 109 typical operations on URI references such as parsing, comparison and 110 reference resolution to be implemented (including all corner cases) 111 in a comparatively small amount of code. 113 As a result of simplification, however, CRIs are not capable of 114 expressing all URIs permitted by the generic syntax of RFC 3986 115 (hence the "constrained" in "Constrained Resource Identifier"). The 116 supported subset includes all URIs of the Constrained Application 117 Protocol (CoAP) [RFC7252], most URIs of the Hypertext Transfer 118 Protocol (HTTP) [RFC7230], and other URIs that are similar. The 119 exact constraints are defined in Section 2. 121 1.1. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Terms defined in this document appear in _cursive_ where they are 130 introduced (rendered in plain text as the new term surrounded by 131 underscores). 133 2. Constraints 135 A Constrained Resource Identifier consists of the same five 136 components as a URI: scheme, authority, path, query, and fragment. 137 The components are subject to the following constraints: 139 C1. The scheme name can be any Unicode string (see Definition D80 140 in [Unicode]) that matches the syntax defined in Section 3.1 of 141 [RFC3986] and is lowercase (see Definition D139 in [Unicode]). 143 C2. An authority is always a host identified by an IP address or 144 registered name, along with optional port information. User 145 information is not supported. 147 C3. An IP address can be either an IPv4 address or an IPv6 address. 148 IPv6 scoped addressing zone identifiers and future versions of 149 IP are not supported. 151 C4. A registered name can be any Unicode string that is lowercase 152 and in Unicode Normalization Form C (NFC) (see Definition D120 153 in [Unicode]). (The syntax may be further restricted by the 154 scheme.) 156 C5. A port is always an integer in the range from 0 to 65535. 157 Empty ports or ports outside this range are not supported. 159 C6. The port is omitted if and only if the port would be the same 160 as the scheme's default port (provided the scheme is defining 161 such a default port) or the scheme is not using ports. 163 C7. A path consists of zero or more path segments. A path must not 164 consist of a single zero-length path segment, which is 165 considered equivalent to a path of zero path segments. 167 C8. A path segment can be any Unicode string that is in NFC 168 (including the zero-length string) with the exception of the 169 special "." and ".." complete path segments. No special 170 constraints are placed on the first path segment. 172 C9. A query always consists of one or more query parameters. A 173 query parameter can be any Unicode string that is in NFC. It 174 is often in the form of a "key=value" pair. When converting a 175 CRI to a URI, query parameters are separated by an ampersand 176 ("&") character. (This matches the structure and encoding of 177 the query in CoAP URIs.) 179 C10. A fragment identifier can be any Unicode string that is in NFC. 181 C11. The syntax of registered names, path segments, query 182 parameters, and fragment identifiers may be further restricted 183 and sub-structured by the scheme. There is no support, 184 however, for escaping sub-delimiters that are not intended to 185 be used in a delimiting function. 187 C12. When converting a CRI to a URI, any character that is outside 188 the allowed character range or a delimiter in the URI syntax is 189 percent-encoded. Percent-encoding always uses the UTF-8 190 encoding form (see Definition D92 in [Unicode]) to convert the 191 character to a sequence of one or more octets. 193 3. Creation and Normalization 195 Resource identifiers are generally created on the initial creation of 196 a resource with a certain resource identifier, or the initial 197 exposition of a resource under a particular resource identifier. 199 A Constrained Resource Identifier SHOULD be created by the naming 200 authority that governs the namespace of the resource identifier. For 201 example, for the resources of an HTTP origin server, that server is 202 responsible for creating the CRIs for those resources. 204 The creator MUST ensure that any CRI created satisfies the 205 constraints defined in Section 2. The creation of a CRI fails if the 206 CRI cannot be validated to satisfy all of the constraints. 208 If a creator creates a CRI from user input, it MAY apply the 209 following (and only the following) normalizations to get the CRI more 210 likely to validate: map the scheme name to lowercase (C1.); map the 211 registered name to NFC (C4.); elide the port if it's the default port 212 for the scheme (C6.); elide a single zero-length path segment (C7.); 213 map path segments, query parameters and the fragment identifier to 214 NFC (C8., C9., C10.). 216 Once a CRI has been created, it can be used and transferred without 217 further normalization. All operations that operate on a CRI SHOULD 218 rely on the assumption that the CRI is appropriately pre-normalized. 219 (This does not contradict the requirement that when CRIs are 220 transferred, recipients must operate on as-good-as untrusted input 221 and fail gracefully in the face of malicious inputs.) 223 4. Comparison 225 One of the most common operations on CRIs is comparison: determining 226 whether two CRIs are equivalent, without using the CRIs to access 227 their respective resource(s). 229 Determination of equivalence or difference of CRIs is based on simple 230 component-wise comparison. If two CRIs are identical component-by- 231 component (using code-point-by-code-point comparison for components 232 that are Unicode strings) then it is safe to conclude that they are 233 equivalent. 235 This comparison mechanism is designed to minimize false negatives 236 while strictly avoiding false positives. The constraints defined in 237 Section 2 imply the most common forms of syntax- and scheme-based 238 normalizations in URIs, but do not comprise protocol-based 239 normalizations that require accessing the resources or detailed 240 knowledge of the scheme's dereference algorithm. False negatives can 241 be caused by resource aliases and CRIs that do not fully satisfy the 242 constraints. 244 When CRIs are compared to select (or avoid) a network action, such as 245 retrieval of a representation, fragment components (if any) should be 246 excluded from the comparison. 248 5. CRI References 250 The most common usage of a Constrained Resource Identifier is to 251 embed it in resource representations, e.g., to express a hyperlink 252 between the represented resource and the resource identified by the 253 CRI. 255 This section defines the serialization of CRIs in Concise Binary 256 Object Representation (CBOR) [RFC7049bis]. To reduce representation 257 size, CRIs are not serialized directly. Instead, CRIs are indirectly 258 referenced through _CRI references_ that take advantage of 259 hierarchical locality. The CBOR serialization of CRI references is 260 specified in Section 5.1. 262 The only operation defined on a CRI reference is _reference 263 resolution_: the act of transforming a CRI reference into a CRI. An 264 application MUST implement this operation by applying the algorithm 265 specified in Section 5.2 or any algorithm that is functionally 266 equivalent to it. 268 The method of transforming a CRI into a CRI reference is unspecified; 269 implementations are free to use any algorithm as long as reference 270 resolution of the resulting CRI reference yields the original CRI. 272 When testing for equivalence or difference, applications SHOULD NOT 273 directly compare CRI references; the references should be resolved to 274 their respective CRI before comparison. 276 5.1. CBOR Serialization 278 A CRI reference is encoded as a CBOR array [RFC7049bis] that contains 279 a sequence of zero or more options. Each option consists of an 280 option number followed by an option value, holding one component or 281 sub-component of the CRI reference. To reduce size, both option 282 numbers and option values are immediate elements of the CBOR array 283 and appear in alternating order. 285 Not all possible sequences of options denote a well-formed CRI 286 reference. The structure can be described in the Concise Data 287 Definition Language (CDDL) [RFC8610] as follows: 289 CRI-Reference = [ 290 (?scheme, ?((host.name // host.ip), ?port) // path.type), 291 *path, 292 *query, 293 ?fragment 294 ] 296 scheme = (0, text .regexp "[a-z][a-z0-9+.-]*") 297 host.name = (1, text) 298 host.ip = (2, bytes .size 4 / bytes .size 16) 299 port = (3, 0..65535) 300 path.type = (4, 0..127) 301 path = (5, text) 302 query = (6, text) 303 fragment = (7, text) 305 The options correspond to the (sub-)components of a CRI, as described 306 in Section 2, with the addition of the "path.type" option. The 307 "path.type" option can be used to express path prefixes like "/", 308 "./", "../", "../../", etc. The exact semantics of the option values 309 are defined by Section 5.2. A sequence of options that is empty or 310 starts with a "path" option is equivalent the same sequence prefixed 311 by a "path.type" option with value 2. 313 Examples: 315 [0, "coap", 316 2, h'C6336401', 317 3, 61616, 318 5, ".well-known", 319 5, "core"] 321 [4, 0, 322 5, ".well-known", 323 5, "core", 324 6, "rt=temperature-c"] 326 A CRI reference is considered _absolute_ if the sequence of options 327 starts with a "scheme" option. 329 A CRI reference is considered _relative_ if the sequence of options 330 is empty or starts with an option other than a "scheme" option. 332 5.2. Reference Resolution 334 The term "relative" implies that a "base CRI" exists against which 335 the relative reference is applied. Aside from fragment-only 336 references, relative references are only usable when a base CRI is 337 known. 339 The following steps define the process of resolving any CRI reference 340 against a base CRI so that the result is a CRI in the form of an 341 absolute CRI reference: 343 1. Establish the base CRI of the CRI reference and express it in the 344 form of an absolute CRI reference. The base CRI can be 345 established in a number of ways; see Section 5.1 of [RFC3986]. 347 2. Determine the values of two variables, T and E, depending on the 348 first option of the CRI reference to be resolved, according to 349 Table 1. 351 +---------------------+------------------+------------------------+ 352 | First Option Number | T | E | 353 +=====================+==================+========================+ 354 | 0 (scheme) | 0 | 0 | 355 +---------------------+------------------+------------------------+ 356 | 1 (host.name) | 0 | 1 | 357 +---------------------+------------------+------------------------+ 358 | 2 (host.ip) | 0 | 1 | 359 +---------------------+------------------+------------------------+ 360 | 3 (port) | (invalid sequence of options) | 361 +---------------------+------------------+------------------------+ 362 | 4 (path.type) | option value - 1 | if T < 0 then 5 else 6 | 363 +---------------------+------------------+------------------------+ 364 | 5 (path) | 1 | 6 | 365 +---------------------+------------------+------------------------+ 366 | 6 (query) | 0 | 6 | 367 +---------------------+------------------+------------------------+ 368 | 7 (fragment) | 0 | 7 | 369 +---------------------+------------------+------------------------+ 370 | none/empty sequence | 0 | 7 | 371 +---------------------+------------------+------------------------+ 373 Table 1: Values of the Variables T and E 375 3. Initialize a buffer with all the options from the base CRI where 376 the option number is less than the value of E. 378 4. If the value of T is greater than 0, remove the last T-many 379 "path" options from the end of the buffer (up to the number of 380 "path" options in the buffer). 382 5. Append all the options from the CRI reference to the buffer, 383 except for any "path.type" option. 385 6. If the buffer contains a single "path" option and the value of 386 that option is the zero-length string, remove that option from 387 the buffer. 389 7. Return the sequence of options in the buffer. 391 6. Relationship between CRIs, URIs and IRIs 393 CRIs are meant to replace both Uniform Resource Identifiers (URIs) 394 [RFC3986] and Internationalized Resource Identifiers (IRIs) [RFC3987] 395 in constrained environments [RFC7228]. Applications in these 396 environments may never need to use URIs and IRIs directly, especially 397 when the resource identifier is used simply for identification 398 purposes or when the CRI can be directly converted into a CoAP 399 request. 401 However, it may be necessary in other environments to determine the 402 associated URI or IRI of a CRI, and vice versa. Applications can 403 perform these conversions as follows: 405 CRI to URI 406 A CRI is converted to a URI as specified in Section 6.1. 408 URI to CRI 409 The method of converting a URI to a CRI is unspecified; 410 implementations are free to use any algorithm as long as 411 converting the resulting CRI back to a URI yields an equivalent 412 URI. 414 CRI to IRI 415 A CRI can be converted to an IRI by first converting it to a URI, 416 and then converting the URI to an IRI as described in Section 3.2 417 of [RFC3987]. 419 IRI to CRI 420 An IRI can be converted to a CRI by first converting it to a URI 421 as described in Section 3.1 of [RFC3987], and then converting the 422 URI to a CRI. 424 Everything in this section also applies to CRI references, URI 425 references and IRI references. 427 6.1. Converting CRIs to URIs 429 Applications MUST convert a CRI reference to a URI reference by 430 determining the components of the URI reference according to the 431 following steps and then recomposing the components to a URI 432 reference string as specified in Section 5.3 of [RFC3986]. 434 scheme 435 If the CRI reference contains a "scheme" option, the scheme 436 component of the URI reference consists of the value of that 437 option. Otherwise, the scheme component is undefined. 439 authority 440 If the CRI reference contains a "host.name" or "host.ip" option, 441 the authority component consists of the host subcomponent, 442 optionally followed by a colon (":") character and the port 443 subcomponent. Otherwise, the authority component is undefined. 445 The host subcomponent consists of the value of the "host.name" or 446 "host.ip" option. 448 Any character in the value of a "host.name" option that is not in 449 the set of unreserved characters (Section 2.3 of [RFC3986]) or 450 "sub-delims" (Section 2.2 of [RFC3986]) MUST be percent-encoded. 452 The value of a "host.ip" option MUST be represented as a string 453 that matches the "IPv4address" or "IP-literal" rule (Section 3.2.2 454 of [RFC3986]). 456 If the CRI reference contains a "port" option, the port 457 subcomponent consists of the value of that option in decimal 458 notation. Otherwise, the colon (":") character and the port 459 subcomponent are both omitted. 461 path 462 If the CRI reference is an empty sequence of options or starts 463 with a "port" option, a "path" option, or a "path.type" option 464 where the value is not 0, the conversion fails. 466 If the CRI reference contains a "host.name" option, a "host.ip" 467 option or a "path.type" option where the value is not 0, the path 468 component of the URI reference is prefixed by a slash ("/") 469 character. Otherwise, the path component is prefixed by the empty 470 string. 472 If the CRI reference contains one or more "path" options, the 473 prefix is followed by the value of each option, separated by a 474 slash ("/") character. 476 Any character in the value of a "path" option that is not in the 477 set of unreserved characters or "sub-delims" or a colon (":") or 478 commercial at ("@") character MUST be percent-encoded. 480 If the authority component is defined and the path component does 481 not match the "path-abempty" rule (Section 3.3 of [RFC3986]), the 482 conversion fails. 484 If the authority component is undefined and the scheme component 485 is defined and the path component does not match the "path- 486 absolute", "path-rootless" or "path-empty" rule (Section 3.3 of 487 [RFC3986]), the conversion fails. 489 If the authority component is undefined and the scheme component 490 is undefined and the path component does not match the "path- 491 absolute", "path-noscheme" or "path-empty" rule (Section 3.3 of 492 [RFC3986]), the conversion fails. 494 query 495 If the CRI reference contains one or more "query" options, the 496 query component of the URI reference consists of the value of each 497 option, separated by an ampersand ("&") character. Otherwise, the 498 query component is undefined. 500 Any character in the value of a "query" option that is not in the 501 set of unreserved characters or "sub-delims" or a colon (":"), 502 commercial at ("@"), slash ("/") or question mark ("?") character 503 MUST be percent-encoded. Additionally, any ampersand character 504 ("&") in the option value MUST be percent-encoded. 506 fragment 507 If the CRI reference contains a fragment option, the fragment 508 component of the URI reference consists of the value of that 509 option. Otherwise, the fragment component is undefined. 511 Any character in the value of a "fragment" option that is not in 512 the set of unreserved characters or "sub-delims" or a colon (":"), 513 commercial at ("@"), slash ("/") or question mark ("?") character 514 MUST be percent-encoded. 516 7. Security Considerations 518 Parsers of CRI references must operate on input that is assumed to be 519 untrusted. This means that parsers MUST fail gracefully in the face 520 of malicious inputs. Additionally, parsers MUST be prepared to deal 521 with resource exhaustion (e.g., resulting from the allocation of big 522 data items) or exhaustion of the call stack (stack overflow). See 523 Section 10 of [RFC7049bis] for additional security considerations 524 relating to CBOR. 526 The security considerations discussed in Section 7 of [RFC3986] and 527 Section 8 of [RFC3987] for URIs and IRIs also apply to CRIs. 529 8. IANA Considerations 531 This document has no IANA actions. 533 9. References 535 9.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 543 Resource Identifier (URI): Generic Syntax", STD 66, 544 RFC 3986, DOI 10.17487/RFC3986, January 2005, 545 . 547 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 548 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 549 January 2005, . 551 [RFC7049bis] 552 Bormann, C. and P. Hoffman, "Concise Binary Object 553 Representation (CBOR)", Work in Progress, Internet-Draft, 554 draft-ietf-cbor-7049bis-13, 8 March 2020, 555 . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 562 Definition Language (CDDL): A Notational Convention to 563 Express Concise Binary Object Representation (CBOR) and 564 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 565 June 2019, . 567 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 568 12.1.0", ISBN 978-1-936213-25-2, May 2019, 569 . 571 9.2. Informative References 573 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 574 Constrained-Node Networks", RFC 7228, 575 DOI 10.17487/RFC7228, May 2014, 576 . 578 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 579 Protocol (HTTP/1.1): Message Syntax and Routing", 580 RFC 7230, DOI 10.17487/RFC7230, June 2014, 581 . 583 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 584 Application Protocol (CoAP)", RFC 7252, 585 DOI 10.17487/RFC7252, June 2014, 586 . 588 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 589 DOI 10.17487/RFC8288, October 2017, 590 . 592 [W3C.REC-html52-20171214] 593 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 594 S. Moon, "HTML 5.2", World Wide Web Consortium 595 Recommendation REC-html52-20171214, 14 December 2017, 596 . 598 Appendix A. Change Log 600 This section is to be removed before publishing as an RFC. 602 Changes from -02 to -03: 604 * Expanded the set of supported schemes (#3). 606 * Specified creation, normalization and comparison (#9). 608 * Clarified the default value of the "path.type" option (#33). 610 * Removed the "append-relation" path type (#41). 612 * Renumbered the remaining path types. 614 * Renumbered the option numbers. 616 * Restructured the document. 618 * Minor editorial improvements. 620 Changes from -01 to -02: 622 * Changed the syntax of schemes to exclude upper case characters 623 (#13). 625 * Minor editorial improvements (#34 #37). 627 Changes from -00 to -01: 629 * None. 631 Acknowledgements 633 Thanks to Christian Amsuess, Carsten Bormann, Ari Keranen, Jim Schaad 634 and Dave Thaler for helpful comments and discussions that have shaped 635 the document. 637 Author's Address 639 Klaus Hartke 640 Ericsson 641 Torshamnsgatan 23 642 SE-16483 Stockholm 643 Sweden 645 Email: klaus.hartke@ericsson.com