One document matched: draft-groves-clue-latent-config-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-groves-clue-latent-config-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CLUE and latent config">CLUE and latent configurations</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Christian Groves" initials="C" role="editor"
surname="Groves">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Melbourne</city>
<region></region>
<code></code>
<country>Australia</country>
</postal>
<email>Christian.Groves@nteczone.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Weiwei Yang" initials="W"
surname="Yang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<email>tommy@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Roni Even" initials="R"
surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Tel Aviv</city>
<region></region>
<code></code>
<country>Isreal</country>
</postal>
<email>roni.even@mail01.huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>CLUE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document proposes to use Latent Configurations as described by the SDP media capability negotiation framework [RFC6871] for the description and negotiation of CLUE encodings.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>One of the issues faced in CLUE is how to describe the encodings associated with the Advertised Captures. It was recently decided that this encoding information would not be described in CLUE itself. This means that other methods such as the use of SDP are required to transmit this encoding information. When considering the use of SDP (and in particular the use of SDP Offer/Answer) it should be recognized that there is a semantic difference between a CLUE encoding and an SDP media stream description. Given the nature of a CLUE exchange the encoding represents a Capture/Stream that may occur in the future (i.e. no resources are reserved) whereas a SDP Offer typically relates to resources that are available at that point in time. This does lead to complications when trying to describe CLUE encodings using standard SDP O/A mechanisms.</t>
<t>An alternate approach to using the standard SDP O/A mechanisms for describing CLUE encodings is to use the "SDP Capability Negotiation framework" <xref target="RFC5939" /> and in particular to use the SDP Media Capabilities Negotiation <xref target="RFC6871" />. <xref target="RFC6871" /> defines "Latent Configurations" as a means to describe media streams that may be used in the future.</t>
</section>
<section title="Latent Configurations and CLUE">
<t>The sections below discuss different aspects and benefits of using Latent Configurations to describe CLUE encodings.</t>
<section title="Semantics">
<t>[RFC6501] defines a Latent Configuration as:
<list hangIndent="4" style="hanging">
<t>A latent configuration indicates which combinations of capabilities could be used in a future negotiation for the session and its associated media stream components. Latent configurations are neither ready for use nor offered for actual or potential use in the current offer/answer exchange. Latent configurations merely inform the other side of possible configurations supported by the entity. Those latent configurations may be used to guide subsequent offer/answer exchanges, but they are not offered for use as part of the current offer/answer exchange.</t>
</list></t>
<t>From the above description it can be seen that the semantic of a Latent Configurations closely matches a CLUE message flow. I.e. A set of possible Captures/Encodings (e.g. configurations) are Advertised, the receiver can choose particular Captures/Encodings and then the actual media stream is subsequently established. Therefore the authors believe that use of latent configurations is a good semantic fit with CLUE to describe the encodings.</t>
</section>
<section title="Messaging">
<t>It has been recognized that CLUE Advertisements may contain a large number of Captures and as there may be multiple encodings per capture potentially a larger number of encodings.</t>
<t>Section 4.2 of CLUE signaling draft <xref target="I-D.kyzivat-clue-signaling" /> indicates the CLUE Provider uses an "m" line for each separate encoding and utilizes the "a=inactive", "a=sendonly" and "a=recvonly" to manage when the media flows are instantiated.</t>
<t>This means that ports must be allocated for these "m" lines and the SDP Offer/Answer <xref target="RFC3264" /> rules regarding maintaining these "m" lines must be followed.</t>
<t>This results in potentially very large SDP descriptions containing superfluous information that must be maintained for the life of the session.</t>
<t>Latent Configurations allow a Provider to advertise potential media without allocating multiple "m" lines or allocating ports for the configurations. The SDP O/A model doesn't apply to Latent Configurations which means that less data is sent over the life of a session.</t>
<t>This allows a Provider to offer a basic media stream for immediate use (i.e. an audio "m" line) and a list of latent configurations for later use without the need for additional m-lines. This is described by <xref target="RFC6871" />:
<list hangIndent="4" style="hanging">
<t>A new attribute ("a=lcfg") specifies latent media stream configurations when no corresponding media line ("m=") is offered. An example is the offer of latent configurations for video even though no video is currently offered. If the peer indicates support for one or more offered latent configurations, the corresponding media stream(s) may be added via a new offer/answer exchange.</t>
<t>AND</t>
<t>The "lcfg" attribute is defined as a media-level attribute since it specifies a possible future media stream. However, the "lcfg" attribute is not necessarily related to the media description within which it is provided. Each media line in an SDP description represents an offered simultaneous media stream, whereas each latent configuration represents an additional stream that may be negotiated in a future offer/answer exchange.</t></list></t>
<t>The use of Latent Configurations also means that resources aren't tied up and can be allocated when they are needed. i.e. from <xref target="RFC6871" />:
<list hangIndent="4" style="hanging">
<t>A latent configuration represents a future capability; hence, the "pt=" parameter is not directly meaningful in the "lcfg" attribute because no actual media session is being offered or accepted. It is permitted in order to tie any payload type number parameters within attributes to the proper media format.</t></list></t>
<t>Therefore the authors believe that Latent Configurations provide a clear benefit in terms of messaging size and complexity over normal SDP Offer/Answer mechanism for Advertising CLUE encodings.</t>
</section>
<section title="Correlation">
<t>One of the issues recognized in the CLUE work it that there needs to be a correlation between the Captures signaled in CLUE and the encodings defined in SDP. The encoding identity (EncodeID) is used as an identity in CLUE. This same identity is then assigned to the encoding in SDP. Currently <xref target="I-D.kyzivat-clue-signaling" /> indicates that the label attribute [RFC4574] is used to identify the encoding and that it is set per "m" line.</t>
<t>This same method can be used with Latent configurations as they allow the use of SDP attributes in the configurations' description. Section 3.3.8/<xref target="RFC6871" /> shows an example of the use of "label" with a latent configuration, e.g.</t>
<figure align="left">
<preamble></preamble>
<artwork align="left"><![CDATA[
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=acap:41 label:13
a=acap:42 content:slides
]]></artwork>
</figure>
<t>The use of Latent Configurations does not require any new SDP attributes to be defined in order for it to be used for CLUE encodings.</t>
</section>
<section title="Returning an Answer">
<t>A consumer upon receiving an SDP Offer containing CLUE related latent configurations from the Provider could immediately send an SDP answer with the configurations that it could support, i.e. section 3.3.6.1/<xref target="RFC6871" />:
<list hangIndent="4" style="hanging">
<t>Potential and/or latent configuration attributes may be returned within an answer SDP to indicate the ability of the answerer to support alternative configurations of the corresponding stream(s).</t></list></t>
<t>The consumer would then send a CLUE Configure indicating the Capture Encodings it wants. The Provider can then subsequently offer actual media streams for the encodings.</t>
</section>
<section title="Interworking">
<t>One aspect to be considered is the level of adoption of the SDP media capabilities negotiation framework in network entities. Whilst the framework is not widely deployed it is supported by 3GPP (e.g. <xref target="SDO-3GPP.24.292" />) and is supported by the ITU-T (e.g. <xref target="ITU.H248.80.2014" /> and <xref target="ITU.T38.2010" />.</t>
<t>It must also be recognized that CLUE itself is something completely new and clients and network equipment must be upgraded to support CLUE signaling. Thus this equipment could also be upgraded to support Latent Configurations at the same time.</t>
<t>In cases where a CLUEfull client sends SDP requesting a CLUE channel and a number of latent configurations to a client that doesn't support CLUE or the media capability framework, the receiving client will ignore the attributes associated with the latent configuration as per normal SDP behavior. Thus there are no interworking issues in this case.</t>
<t>In cases where a CLUEfull client sends SDP requesting a CLUE channel and a number of latent configurations to a client that doesn't support CLUE but DOES support the media capability framework, the receiving client would ignore the CLUE related attributes but could respond with what latent configurations it could support. This would allow the sender to decide if it wanted to offer subsequent media streams. Again there are no interworking issues in this case.</t>
<t>In either of the above cases the session between the clients wouldn't be forced to maintain "m" lines for media that would never be used.</t>
</section>
<section title="Relation to BUNDLE">
<t>At its core BUNDLE is about using SDP to describe that several "m" lines use the same IP Address/Port for the transport of RTP media. If SDP O/A is being used to describe CLUE encodings then there is a potential interaction in that the CLUE encoding "m" lines would all be subject the BUNDLE procedures whether or not they were actually used for media.</t>
<t>The use of Latent Configurations would simplify this interaction because Latent Configurations do not allocate or specify ports. They would not be subject to BUNDLE procedures. Once the use of BUNDLE is established (i.e. for the base media streams), then only the media streams (Capture Encodings) that have been chosen by the Consumer can be added to the BUNDLE.</t>
</section>
<section title="Open Issues">
<t>There are several issues that need to be clarified in <xref target="RFC6871" /> with respect to latent configurations.
<list hangIndent="4" style="numbers">
<t>Latent configurations are specified as media level attributes and thus may be associated with any m-line in an SDP O/A as they don't really pertain to a particular media. There appears to be no guidance as to with m-line they should be associated with in the case of multiple m-line in a SDP Offer.</t>
<t>It's not clear from <xref target="RFC6871" /> what happens to latent configurations when an endpoint decides to instantiate the latent configuration as an m-line through an updated SDP Offer. Section 3.4.4/<xref target="RFC6871" /> discusses modifying the session but has minimal information. It is assumed by the authors that the latent configuration is removed once instantiated.</t>
<t>It needs to be clarified whether <xref target="RFC6871" /> indicates that the SDP Answerer SHOULD reply with the latent configurations it supports or whether this is optional. If it's optional what does it mean?</t>
<t><xref target="RFC6871" /> allows an SDP Answerer to reply with additional latent configurations. However it doesn't specify what action the SDP Offerer should take. This needs to be clarified.</t>
</list></t>
</section>
</section>
<section title="Example">
<t> This section describes an example session establishment utilizing CLUE and latent configurations. The Provider offers a base audio stream, a CLUE channel (according to <xref target="I-D.ietf-mmusic-sctp-sdp" /> and several latent configurations related to video captures.</t>
<figure align="left" anchor="fig_1" title="Initial Offer">
<preamble></preamble>
<artwork align="left"><![CDATA[
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0 ; Base audio stream
a=rtpmap:0 PCMU/8000
; CLUE channel establishment request
m=application 49172 SCTP 49172
a=setup:actpass
a=connection:new
a=sctpmap:49172 CLUE 1
;Offered configurations
a=rmcap:1 H264/90000 ; this is needed for the m=
a=rmcap:2 VP8/90000
a=tcap:1 RTP/AVPF ; for the t=
a=acap:5 sendonly
a=acap:1 label:encoding1
a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100,2:101
a=acap:2 label:encoding2
a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102,2:103
a=acap:3 label:encoding3
a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104,2:105
a=acap:4 label:encoding4
a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106,2:107
]]></artwork>
</figure>
<t>The receiver is CLUE capable and responds indicating support of the CLUE channel and indicates the IP Address/Port where the Provider should establish a connection to. It also indicates that it only supports H264 encoding.</t>
<figure align="left" anchor="fig_2" title="Answer">
<preamble></preamble>
<artwork align="left"><![CDATA[
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
; Accepted SCTP CLUE connection
m=application 54321 SCTP 54321
c=IN IP4 192.0.2.1
a=setup:passive
a=connection:new
a=sctpmap:54321 CLUE 1
;Accepted configurations
a=rmcap:1 H264/90000 ; this is needed for the m=
a=tcap:1 RTP/AVPF ; for the t=
a=acap:5 sendonly
a=acap:1 label:encoding1
a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100
a=acap:2 label:encoding2
a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102
a=acap:3 label:encoding3
a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104
a=acap:4 label:encoding4
a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106
]]></artwork>
</figure>
<t>Author's note: In the signaling document the grouping framework <xref target="RFC5888" /> is used to indicate the "m" lines that are under CLUE control. It's not clear whether a=group:CLUE and a=mid is needed at this stage or during the updated-Offer. It could be assumed that the above latent configurations are related to CLUE due to the fact they appear under the m=application SCTP/CLUE line.</t>
<t>On receipt of the SDP Answer the Provider establishes the SCTP connection, performs CLUE version and capability negotiation (not shown) and then sends the initial CLUE Advertisement. In it the Provider advertises a single Capture Scene described by three video captures (i.e. Left,Centre,Right) or a video capture of the entire scene.</t>
<t>Author's note: According to the current CLUE protocol work <xref target="I-D.presta-clue-protocol" />, it's the consumer that sends the first Advertisement. The author believes that the Provider should send the first Advertisement to align with the Offer.</t>
<figure align="left" anchor="fig_3" title="Advertisement">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------------------|---------------------------------+
| Capture Scene #1 | |
+-----------------------|---------------------------------+
| VC1 | CaptureArea=Left |
| | EncodingGroup=EG1 |
| VC2 | CaptureArea=Centre |
| | EncodingGroup=EG2 |
| VC3 | CaptureArea=Right |
| | EncodingGroup=EG3 |
| VC4 | CaptureArea=All |
| | EncodingGroup=EG4 |
| CSE(VC1,VC2,VC3) | |
| CSE(VC4) | |
+-----------------------|---------------------------------+
| EncodingGroups | |
+-----------------------|---------------------------------+
| EG1 | EncodeID=encoding1 |
| EG2 | EncodeID=encoding2 |
| EG3 | EncodeID=encoding3 |
| EG4 | EncodeID=encoding4 |
+=======================+=================================+
]]></artwork>
</figure>
<t>On receipt of the Advertisement the Consumer determines that it wants the three video captures representing left/centre/right. It sends a CLUE Configure to the Provider:</t>
<figure align="left" anchor="fig_4" title="Configure">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------------------+---------------------------------+
| VC1 | encoding1 |
| VC2 | encoding2 |
| VC3 | encoding3 |
+-----------------------|---------------------------------+
]]></artwork>
</figure>
<t>On receipt of the CLUE Configure the Provider determines that the Consumer wants to see VC1, VC2 and VC3 according to encoding1, encoding2 and encoding3 respectively. The Provider then issues an updated SDP Offer for three additional video streams. Note: The latent configurations have been removed but the latent configuration related to VC4/encoding4 could also be maintained if still available. The grouping framework <xref target="RFC5888" /> is used to indicate that the additional video streams are under CLUE control.</t>
<figure align="left" anchor="fig_5" title="Updated Offer">
<preamble></preamble>
<artwork align="left"><![CDATA[
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
a=group:CLUE 1 2 3
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0 ; Base audio stream
a=rtpmap:0 PCMU/8000
; CLUE channel estab. Req.
m=application 49172 SCTP 49172
a=setup:actpass
a=connection:new
a=sctpmap:49172 CLUE 1
;Additional video streams
m=video 49174 RTP/AVPF 100
a=rtpmap:100 H264/90000
a=label:encoding1
a=mid:1
a=sendonly
m=video 49176 RTP/AVPF 102
a=rtpmap:102 H264/90000
a=label:encoding2
a=mid:2
a=sendonly
m=video 49178 RTP/AVPF 104
a=rtpmap:104 H264/90000
a=label:encoding3
a=mid:3
a=sendonly
]]></artwork>
</figure>
<t>The Consumer then receives the Updated Offer and confirms with an updated Answer. Media flow for the 3 video streams then starts to flow.</t>
</section>
<section title="Summary">
<t>The authors believe that the use of Latent Configurations is an ideal way to indicate CLUE encoding information. It is proposed that the use of Latent Configuration is the preferred way of describing CLUE encoding information.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>It is not expected that the proposed changes present the need for any IANA registrations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>It is not expected that the proposed changes present any addition security issues to the current framework.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.RFC.2629.xml"?>
<?rfc include="reference.RFC.3264.xml"?>
<?rfc include="reference.RFC.5888.xml"?>
<?rfc include="reference.RFC.5939.xml"?>
<?rfc include="reference.RFC.6871.xml"?>
<?rfc include="reference.I-D.presta-clue-protocol.xml"?>
<?rfc include="reference.I-D.ietf-mmusic-sctp-sdp.xml"?>
<?rfc include="reference.I-D.kyzivat-clue-signaling.xml"?>
<?rfc include="reference.SDO-3GPP.24.292.xml"?>
<reference anchor="ITU.T38.2010">
<front>
<title>Procedures for real time Group 3 facsimile communication between terminals using IP Networks</title>
<author><organization>International Telecommunications Union</organization></author>
<date month="" year="2010"/></front>
<seriesInfo name="ITU-T" value="Recommendation T.38"/>
</reference>
<reference anchor="ITU.H248.80.2014">
<front>
<title>Usage of the revised SDP offer / answer model with H.248</title>
<author><organization>International Telecommunications Union</organization></author>
<date month="" year="2014"/></front>
<seriesInfo name="ITU-T" value="Recommendation H.248.80"/>
</reference>
<!-- <reference anchor="I-D.ietf-clue-framework">
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author initials="A" surname="Romanow">
<organization></organization>
</author>
<author initials="M" surname="Duckworth">
<organization></organization>
</author>
<author initials="A" surname="Pepperell">
<organization></organization>
</author>
<author initials="B" surname="Baldino">
<organization></organization>
</author>
<date year="draft-ietf-clue-framework-09 (work in progress)" />
</front>
</reference> -->
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:01 |