diff options
Diffstat (limited to 'doc/rfc/rfc8262.txt')
| -rw-r--r-- | doc/rfc/rfc8262.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc8262.txt b/doc/rfc/rfc8262.txt new file mode 100644 index 0000000..326af3a --- /dev/null +++ b/doc/rfc/rfc8262.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 8262 I. Sedlacek +Updates: 5368, 5621, 6442 Ericsson +Category: Standards Track October 2017 +ISSN: 2070-1721 + + + Content-ID Header Field in the Session Initiation Protocol (SIP) + +Abstract + + This document specifies the Content-ID header field for usage in the + Session Initiation Protocol (SIP). This document also updates RFC + 5621, which only allows a Content-ID URL to reference a body part + that is part of a multipart message-body. This update enables a + Content-ID URL to reference a complete message-body and metadata + provided by some additional SIP header fields. + + This document updates RFC 5368 and RFC 6442 by clarifying their usage + of the SIP Content-ID header field. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8262. + + + + + + + + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 1] + +RFC 8262 Content-ID in SIP October 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Identifying a Body Part . . . . . . . . . . . . . . . . . 3 + 1.2. Referencing a Body Part . . . . . . . . . . . . . . . . . 3 + 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 + 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4 + 1.4.1. Example 1: SIP INVITE . . . . . . . . . . . . . . . . 4 + 1.4.2. Example 2: SIP REFER . . . . . . . . . . . . . . . . 6 + 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.6. Backward Compatibility . . . . . . . . . . . . . . . . . 7 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Content-ID Header Field . . . . . . . . . . . . . . . . . . . 8 + 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4.1. User Agent (UA) Procedures . . . . . . . . . . . . . 9 + 3.4.2. Proxy Procedures . . . . . . . . . . . . . . . . . . 9 + 3.4.3. Example: Referencing the Message-Body of a SIP + Message . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10 + 5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 11 + 6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + +Holmberg & Sedlacek Standards Track [Page 2] + +RFC 8262 Content-ID in SIP October 2017 + + +1. Introduction + +1.1. Identifying a Body Part + + A SIP message consists of a start-line, one or more header fields, an + empty line indicating the end of the header fields, and an optional + message-body as specified in [RFC3261]. + + The message-body can be a non-multipart message-body or a multipart + message-body as specified in [RFC3261]. + + [RFC5621] defines generic handling of a multipart message-body in a + SIP message. + + A multipart message-body contains zero, one, or several body parts + encoded using the format define in [RFC2045]. + + A body part in the multipart message-body is described using header + fields such as Content-Disposition, Content-Encoding, and Content- + Type, which provide information on the content of the body part as + specified in [RFC5621]. A body part in the multipart message-body + can also contain a Content-ID header field with an ID value uniquely + identifying the body part as specified in [RFC2045]. + +1.2. Referencing a Body Part + + A SIP header field can reference a body part using a Content-ID URL + as specified in [RFC5621]. + + The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies + how to identify the body part referenced by a Content-ID URL. The + Content-ID URL value is included in the Content-ID header field of + the body part. + + Examples of SIP header fields referencing a body part using a + Content-ID URL are: + + o [RFC6442] specifies how a Geolocation header field references a + body part using a Content-ID URL for providing location + information. + + o [RFC5368] specifies how a Refer-To header field references a body + part using a Content-ID URL to provide a list of targets. + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 3] + +RFC 8262 Content-ID in SIP October 2017 + + +1.3. Problem Statement + + How to uniquely identify a complete message-body of a SIP message + using a Content-ID header field and how to reference a complete + message-body using a Content-ID URL are not currently specified. + + Note: In [RFC5621], the Content-ID URL references a specific body + part only. + + Some existing specifications, such as [RFC5368], contain examples + that show usage of a SIP Content-ID header field referencing a + complete message-body, even though such usage has never been + specified. Many implementors have interpreted these examples to + indicate that such usage is allowed by the corresponding + specification, despite the absence of language allowing it. This + document updates the normative language in the affected documents to + explicitly allow such usage. + +1.4. Consequences + + The examples below show the consequences of the problem described + above. + +1.4.1. Example 1: SIP INVITE + + If a User Agent Client (UAC) sends an INVITE request that conveys + location by value (as specified in [RFC6442]) and decides not to + include a Session Description Protocol (SDP) offer, then the UAC + needs to include only one MIME entity in the INVITE request. This + MIME entity can be, for example, of the 'application/pidf+xml' MIME + type. + + However, due to [RFC6442] requiring inclusion of a Geolocation header + field referencing the body part with the location information, the + UAC includes a multipart message-body with a single body part in the + INVITE request, and includes the location information of + 'application/pidf+xml' MIME type and an associated Content-ID header + field in the body part. + + + + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 4] + +RFC 8262 Content-ID in SIP October 2017 + + + Example message (SIP INVITE): + + INVITE sips:bob@biloxi.example.com SIP/2.0 + Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 + Max-Forwards: 70 + To: Bob <sips:bob@biloxi.example.com> + From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl + Call-ID: 3848276298220188511@atlanta.example.com + Geolocation: <cid:target123@atlanta.example.com> + Geolocation-Routing: no + Accept: application/sdp, application/pidf+xml + CSeq: 31862 INVITE + Contact: <sips:alice@atlanta.example.com> + Content-Type: multipart/mixed; boundary=boundary1 + Content-Length: ... + + --boundary1 + Content-Type: application/pidf+xml + Content-ID: <target123@atlanta.example.com> + + <?xml version="1.0" encoding="UTF-8"?> + <presence + xmlns="urn:ietf:params:xml:ns:pidf" + xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" + xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" + xmlns:gml="http://www.opengis.net/gml" + xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" + entity="pres:alice@atlanta.example.com" + > + <dm:device id="target123-1"> + <gp:geopriv> + <gp:location-info> + <gml:location> + <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> + <gml:pos>32.86726 -97.16054</gml:pos> + </gml:Point> + </gml:location> + </gp:location-info> + <gp:usage-rules> + <gbp:retransmission-allowed>no + </gbp:retransmission-allowed> + <gbp:retention-expiry>2010-11-14T20:00:00Z + </gbp:retention-expiry> + </gp:usage-rules> + <gp:method>802.11</gp:method> + </gp:geopriv> + + + + +Holmberg & Sedlacek Standards Track [Page 5] + +RFC 8262 Content-ID in SIP October 2017 + + + <dm:deviceID>mac:1234567890ab</dm:deviceID> + <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> + </dm:device> + </presence> + --boundary1-- + +1.4.2. Example 2: SIP REFER + + If a UAC sends a REFER request including a list of targets as + specified in [RFC5368], then the UAC needs to include only one MIME + entity in the REFER request. This MIME entity is of the + 'application/resource-lists+xml' MIME type. + + However, due to [RFC5368] requiring inclusion of a Refer-To header + field referencing the body part containing the list of targets, the + UAC includes a multipart message-body with a single body part in the + REFER request and includes the list of targets of 'application/ + resource-lists+xml' MIME type and an associated Content-ID header + field in the body part. + + Example message (SIP REFER): + + REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 + Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 + Max-Forwards: 70 + To: "Conference 123" <sip:conf-123@example.com> + From: Carol <sip:carol@chicago.example.com>;tag=32331 + Call-ID: d432fa84b4c76e66710 + CSeq: 2 REFER + Contact: <sip:carol@client.chicago.example.com> + Refer-To: <cid:cn35t8jf02@example.com> + Refer-Sub: false + Require: multiple-refer, norefersub + Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY + Allow-Events: dialog + Accept: application/sdp, message/sipfrag + Content-Type: multipart/mixed; boundary=boundary1 + Content-Length: ... + + --boundary1 + Content-Type: application/resource-lists+xml + Content-Disposition: recipient-list + Content-ID: <cn35t8jf02@example.com> + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 6] + +RFC 8262 Content-ID in SIP October 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <resource-lists + xmlns="urn:ietf:params:xml:ns:resource-lists" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + > + <list> + <entry uri="sip:bill@example.com?method=BYE"/> + <entry uri="sip:joe@example.org?method=BYE"/> + <entry uri="sip:ted@example.net?method=BYE"/> + </list> + </resource-lists> + --boundary1-- + +1.5. Solution + + In order to solve the problems described above, this document: + + o Specifies and registers the Content-ID header field as a SIP + header field. + + o Specifies that, when used as a SIP header field, the Content-ID + header field identifies the complete message-body and the metadata + provided by some additional SIP header fields of the SIP message. + + o Updates [RFC5621] to enable a Content-ID URL to reference a + complete message-body and the metadata provided by some additional + SIP header fields. + + o Updates [RFC5368] and [RFC6442] by adding text that explicitly + states that a SIP Content-ID header field can be used. + +1.6. Backward Compatibility + + If an existing specification only defines the usage of a multipart + message-body to carry a single body part to be referenced by a + Content-ID URL, implementations MUST NOT carry the MIME entity in a + non-multipart message-body unless the specification is updated to + explicitly allow it. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + +Holmberg & Sedlacek Standards Track [Page 7] + +RFC 8262 Content-ID in SIP October 2017 + + +3. Content-ID Header Field + +3.1. Introduction + + This section defines the usage of the Content-ID header field for + SIP. + +3.2. Syntax + + The ABNF [RFC5234] for the Content-ID header field is: + + Content-ID = "Content-ID" HCOLON msg-id + + msg-id = "<" id-left "@" id-right ">" + + Note: id-left and id-right are specified in [RFC5322]. HCOLON is + defined in [RFC3261]. + + Note: When used in a SIP header field, the msg-id syntax has been + simplified, compared to the syntax in [RFC5322], to disallow the use + of comments and to adopt to the SIP usage of leading white space. + + The value of the Content-ID header field value must be unique in the + context of a given SIP message, including any embedded MIME + Content-ID header field values. Note that the SIP Content-ID header + field value is not expected to be unique among all SIP messages; it + has no meaning outside of the message in which it is included. + +3.3. Semantics + + The Content-ID header field included in the header fields of a SIP + message identifies the message-body of the SIP message and the + metadata provided by: + + o A MIME-Version header field, if included in the header fields of + the SIP message. + + o Any 'Content-' prefixed header fields (including the Content-ID + header field itself) included in the header fields of the SIP + message. + + The Content-ID header field can be included in any SIP message that + is allowed to contain a message-body. + + Note: The message-body identified by the Content-ID header field can + be a non-multipart message-body or a multipart message-body. + + + + + +Holmberg & Sedlacek Standards Track [Page 8] + +RFC 8262 Content-ID in SIP October 2017 + + +3.4. Procedures + +3.4.1. User Agent (UA) Procedures + + A UA MAY include a Content-ID header field in any SIP message that is + allowed to contain a message-body. + + A UA MUST NOT include a Content-ID header field in any SIP message + that is not allowed to contain a message-body. + + A UA MUST set the value of the Content-ID header field to a value + that is unique in the context of the SIP message. + +3.4.2. Proxy Procedures + + A proxy MUST NOT add a Content-ID header field in a SIP message. + + A proxy MUST NOT modify a Content-ID header field included in a SIP + message. + + A proxy MUST NOT delete a Content-ID header field from a SIP message. + +3.4.3. Example: Referencing the Message-Body of a SIP Message + + The figure shows an example from [RFC5368], where the SIP Content-ID + header field is used to reference the message-body (non-multipart) of + a SIP message. + + REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 + Via: SIP/2.0/TCP client.chicago.example.com + ;branch=z9hG4bKhjhs8ass83 + Max-Forwards: 70 + To: "Conference 123" <sip:conf-123@example.com> + From: Carol <sip:carol@chicago.example.com>;tag=32331 + Call-ID: d432fa84b4c76e66710 + CSeq: 2 REFER + Contact: <sip:carol@client.chicago.example.com> + Refer-To: <cid:cn35t8jf02@example.com> + Refer-Sub: false + Require: multiple-refer, norefersub + Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY + Allow-Events: dialog + Accept: application/sdp, message/sipfrag + Content-Type: application/resource-lists+xml + Content-Disposition: recipient-list + Content-Length: 362 + Content-ID: <cn35t8jf02@example.com> + + + + +Holmberg & Sedlacek Standards Track [Page 9] + +RFC 8262 Content-ID in SIP October 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + <list> + <entry uri="sip:bill@example.com?method=BYE" /> + <entry uri="sip:joe@example.org?method=BYE" /> + <entry uri="sip:ted@example.net?method=BYE" /> + </list> + </resource-lists> + +4. Update to RFC 5368 + + This section updates the second paragraph in Section 7 of [RFC5368] + by allowing usage of either a MIME Content-ID header field or a SIP + Content-ID header field to label the body part or the message-body + carrying the URI list. + + OLD TEXT: + + The Refer-To header field of a REFER request with multiple REFER- + Targets MUST contain a pointer (i.e., a Content-ID Uniform + Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to + the body part that carries the URI list. The REFER-Issuer SHOULD + NOT include any particular URI more than once in the URI list. + + NEW TEXT: + + The Refer-To header field of a REFER request with multiple REFER- + Targets MUST contain a pointer (i.e., a Content-ID Uniform + Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to + the body part or message-body that carries the URI list. The + REFER-Issuer SHOULD NOT include any particular URI more than once + in the URI list. The REFER request can use either a MIME Content- + ID header field [RFC4483] or a SIP Content-ID header field + [RFC8262] to label the body part or the message-body. + + + + + + + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 10] + +RFC 8262 Content-ID in SIP October 2017 + + +5. Update to RFC 5621 + + This section updates Section 9.1 of [RFC5621] by allowing a Content- + ID URL to reference a message-body and the related metadata + (Section 3.3) in addition to allowing a reference to a body part. + + OLD TEXT: + + Content-ID URLs allow creating references to body parts. A given + Content-ID URL [RFC2392], which can appear in a header field or + within a body part (e.g., in an SDP attribute), points to a + particular body part. + + NEW TEXT: + + Content-ID URLs allow the creation of references to body parts or + message-bodies (and the header fields describing the message- + bodies). A given Content-ID URL [RFC2392], which can appear in a + header field or within a body part (e.g., in an SDP attribute), + points to a particular body part or the message-body (and the + header fields describing the message-body). + +6. Update to RFC 6442 + + This section updates the second paragraph in Section 3.1 of [RFC6442] + by allowing usage of either a MIME Content-ID header field or a SIP + Content-ID header field to label the body part or the message-body + carrying the location data. + + OLD TEXT: + + In Figure 1, Alice is both the Target and the LS that is conveying + her location directly to Bob, who acts as an LR. This conveyance + is point-to-point: it does not pass through any SIP-layer + intermediary. A Location Object appears by-value in the initial + SIP request as a MIME body, and Bob responds to that SIP request + as appropriate. There is a 'Bad Location Information' response + code introduced within this document to specifically inform Alice + if she conveys bad location information to Bob (e.g., Bob "cannot + parse the location provided", or "there is not enough location + information to determine where Alice is"). + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 11] + +RFC 8262 Content-ID in SIP October 2017 + + + NEW TEXT: + + In Figure 1, Alice is both the Target and the LS that is conveying + her location directly to Bob, who acts as an LR. This conveyance + is point-to-point: it does not pass through any SIP-layer + intermediary. A Location Object appears by-value in the initial + SIP request as a MIME body, and Bob responds to that SIP request + as appropriate. Either a MIME Content-ID header field [RFC4483] + or the SIP Content-ID header field [RFC8262] MUST be used to label + the location information. There is a 'Bad Location Information' + response code introduced within this document to specifically + inform Alice if she conveys bad location information to Bob (e.g., + Bob "cannot parse the location provided", or "there is not enough + location information to determine where Alice is"). + +7. Security Considerations + + The Content-ID header field value MUST NOT reveal sensitive user + information. + + If the message-body associated with the Content-ID header field is an + encrypted body, it MUST NOT be possible to derive a key that can be + used to decrypt the body from the Content-ID header field value. + +8. IANA Considerations + + This specification registers a new SIP header field according to the + procedures defined in [RFC3261]. + +8.1. Header Field + + The header field described in Section 3 has been registered in the + "Header Fields" sub-registry of the "Session Initiation Protocol + (SIP) Parameters" registry by adding a row with these values: + + Header Name: Content-ID + + compact: + + Reference: RFC 8262 + + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 12] + +RFC 8262 Content-ID in SIP October 2017 + + +9. References + +9.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, + <https://www.rfc-editor.org/info/rfc2045>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, + <https://www.rfc-editor.org/info/rfc2392>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in + Session Initiation Protocol (SIP) Messages", RFC 4483, + DOI 10.17487/RFC4483, May 2006, + <https://www.rfc-editor.org/info/rfc4483>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [RFC5621] Camarillo, G., "Message Body Handling in the Session + Initiation Protocol (SIP)", RFC 5621, + DOI 10.17487/RFC5621, September 2009, + <https://www.rfc-editor.org/info/rfc5621>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + + + + +Holmberg & Sedlacek Standards Track [Page 13] + +RFC 8262 Content-ID in SIP October 2017 + + +9.2. Informative References + + [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., + and H. Khartabil, "Referring to Multiple Resources in the + Session Initiation Protocol (SIP)", RFC 5368, + DOI 10.17487/RFC5368, October 2008, + <https://www.rfc-editor.org/info/rfc5368>. + + [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance + for the Session Initiation Protocol", RFC 6442, + DOI 10.17487/RFC6442, December 2011, + <https://www.rfc-editor.org/info/rfc6442>. + +Authors' Addresses + + Christer Holmberg + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + Email: christer.holmberg@ericsson.com + + + Ivo Sedlacek + Ericsson + Sokolovska 79 + Praha 18600 + Czech Republic + + Email: ivo.sedlacek@ericsson.com + + + + + + + + + + + + + + + + + + + + +Holmberg & Sedlacek Standards Track [Page 14] + |