One document matched: draft-moritz-6lowapp-dpws-enhancements-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">
<!ENTITY I-D.frank-6lowapp-chopan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-frank-6lowapp-chopan-00.xml">
<!ENTITY I-D.ietf-6lowpan-nd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6lowpan-nd-07.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-moritz-6lowapp-dpws-enhancements-00" ipr="noDerivativesTrust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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="Abbreviated Title">DPWS for 6LoWPAN</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Guido Moritz" initials="G.M." role=""
surname="Moritz">
<organization>University of Rostock</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>18051 Rostock</city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone>+49 381 498 7269</phone>
<email>guido.moritz@uni-rostock.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="December" year="2009" />
<!-- 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>General</area>
<workgroup>6LoWAPP</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>DPWS</keyword>
<keyword>6LoWPAN</keyword>
<keyword>6LoWAPP</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 draft describes adaptions and enhancements for deploying the Devices Profile for Web Service (DPWS) in 6LoWPAN networks. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In August 2008 a technical committee (TC) at OASIS was formed for the Web Services Discovery and Web Services Devices Profile<xref target="WS-DD">(WS-DD)</xref>. WS-DD standardizes a lightweight subset of the Web services protocol suite that makes it easy to find, share, and control devices on a network.</t>
<t>The work of this TC is based on the former DPWS, WS-Discovery, and SOAP-over-UDP specifications.
DPWS makes use of existing Web services protocols, but also adds several extensions to enable Web services based communication on embedded devices also. Thereby, DPWS includes features like (1) discovery of devices and metadata exchange with services even in dynamic changing environments (2) eventing about state changes by WS-Eventing (3) security and integrity for discovery, metadata exchange and service usages. Because DPWS bases on existing Web services standards, it is fully capable of being integrated in the Web services framework.</t>
<t>
This draft describes several adaptions and enhancements to expand DPWS deployments to 6LoWPAN networks, but is far away from a comprehensive specification. It only presents a basis for further discussions. Main scope is the definition of a profile, to describe: message compression and bidirectional message reduction, while staying fully compliant with existing WS-DD specifications. The deployment of this profile is fully transparent for existing DPWS implementations and describes extension to be considered by 6LoWPAN networks only.
</t>
<t>
Readers of this draft should have a basic knowledge about the specifications <xref target="DPWS">DPWS</xref>, <xref target="WS-Discovery">WS-Discovery</xref>, <xref target="SOAP-over-UDP">SOAP-over-UDP</xref> and related standards like SOAP, HTTP, XML and XML Schema.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>
<list hangIndent="8" style="hanging">
<t hangText="DPWS"><vspace blankLines="0" />In the remainder of this draft, DPWS is used as general term for the WS-DD specifications <xref target="DPWS">DPWS</xref>, <xref target="WS-Discovery">WS-Discovery</xref>, and <xref target="SOAP-over-UDP">SOAP-over-UDP</xref>.</t>
<t hangText="DPWS specification"><vspace blankLines="0" />Points to the <xref target="DPWS">DPWS</xref> specification directly.</t>
<t hangText="Device"><vspace blankLines="0" />A device is an endpoint implementing DPWS device functionalities as specified by <xref target="WS-DD">WS-DD</xref>.</t>
<t hangText="Client"><vspace blankLines="0" />A client is an endpoint implementing DPWS client functionalities as specified by <xref target="WS-DD">WS-DD</xref>.</t>
<t hangText="Hello"><vspace blankLines="0" />The Hello message of a device as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="Bye"><vspace blankLines="0" />The Bye message of a device as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="Probe"><vspace blankLines="0" />The Probe message of a client as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="Probe Match"><vspace blankLines="0" />The Probe Match message of a device as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="Resolve"><vspace blankLines="0" />The Resolve message of a client as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="Resolve Match"><vspace blankLines="0" />The Resolve Match message of a device as defined in <xref target="WS-Discovery">WS-Discovery</xref>.</t>
<t hangText="WSDL"><vspace blankLines="0" />Acronym for the document describing the services in <xref target="WSDL">Web Services Description Language</xref> format.</t>
<t hangText="Edge Router"><vspace blankLines="0" />Edge Routers are the routers that connect LoWPANs to an IPv6 infrastructure via backhaul or backbone links when such an infrastructure is available. (Defined in <xref target="I-D.ietf-6lowpan-nd">6LoWPAN Neighbor Discovery</xref></t>
</list>
</t>
</section>
</section>
<section title="Discovery optimizations">
<t>DPWS describes two different modes for discovery of devices: ad-hoc mode and managed mode. In managed mode, a registry called Discovery Proxy is applied to suppress multicast messages. This section describes adaptions for both of these modes.</t>
<section title="General adaptions">
<t>
A DEVICE MUST include the transport specific addresses in its Hello and Probe Match messages.
</t>
<t>
In accordance to DPWS, embedding of a transport specific address in Hello and Probe messages is not mandatory. This behavior is counterproductive for WSN, with the constraints for energy consumption and limited bandwidth. Thus, the optional fields for the transport specific addresses are now mandatory to avoid Resolve messages.
</t>
<t>A DEVICE SHOULD include all device types in Hello and Probe Match messages.</t>
<t>In the current version of DPWS it is not mandatory to include the type field in the Hello and Probe Match messages. A client MAY infer to services provided by the device with the help of the device type. Inclusion of the device type can avoid further discovery and metadata exchange messages. </t>
<t>A SERVICE SHOULD NOT provide the WSDL file for CLIENTS at run time.</t>
<t>Providing the WSDL during the discovery phase is optional in DPWS. WSDL are used in general at development time only for code generation. These WSDL files have a size of several kB in most analyzed scenarios. The expensive and memory consuming storage of these WSDL files on the device and on the client node is not applicable for WSN. Furthermore, the exchange itself consumes a high bandwidth.</t>
</section>
<section title="Discovery addressing">
<t>
<list style="symbols">
<t>All SOAP-over-UDP messages inside the 6LoWPAN network MUST use the port 61616 as target port. (Exact port to be defined)</t>
<t>Devices inside the 6LoWPAN network MUST listen to the IPv6 multicast address: FF02::C0. (Exact address to be defined)</t>
<t>Clients inside the 6LoWPAN network MUST listen to the IPv6 multicast address: FF02::C1. (Exact address to be defined)</t>
</list>
</t>
<t>In RFC4944, a UDP port compression is described which works most efficient when using ports in a specific range. Thus, the used ports should be changed to fit in this range. The ports have to be mapped on the edge router of the 6LoWPAN network for incoming and outgoing SOAP-over-UDP messages.</t>
<t>DPWS defines one IPv4 and one IPv6 multicast addresses to be used for discovery message exchange. But DPWS differentiates between device and client roles. Usage of one and the same address for addresses exclusively to be processed by clients or devices implies overhead in sending and receiving these messages to all DPWS nodes independent of their role. Inside 6LoWPAN networks, different addresses have to be used. The mapping into compliant addresses is done by the edge router of the 6LoWPAN network.</t>
<t>For a transparent integration, in ad-hoc mode, edge routers of 6LoWPAN networks SHOULD forward incoming and outgoing link-local scope multicast discovery messages.</t>
</section>
<section title="Discovery proxy">
<t>In managed mode, a device and service registry is applied. It is possible, to use more than one discovery proxy in a network. In managed mode, one discovery proxy SHOULD be deployed at the edge router to hide expensive external multicast messages from the 6LoWPAN network and omit multicast flooding.</t>
</section>
<section title="Heartbeat message">
<t>Wireless Sensor Networks are unreliable due to low power radio communication and limited battery capacities. <!--DPWS implements a Service-oriented Architecture which requires permanent availability of services. -->Clients and discovery proxies might use a heartbeat message to ask for a device and its status. This heartbeat message can use a pull exchange pattern or a push mechanism similar to eventing functionalities. DPWS defines Directed Probe and includes WS-Eventing, which might fulfill the requirements of the heartbeat message or if a new message has to be defined. The device MUST answer to this heartbeat signal with a unicast Hello including the WS-Discovery Metadata Version indicating state changes of the device or the services.</t>
<t>
The definition of the heartbeat mechanisms may be out of scope of a specification and might be included in a domain specific profile (e.g. healthcare scenarios). But the mechanism is required by the device registry described in this draft.
</t>
</section>
<section title="Device registry">
<t>For simple services as provided in 6LoWPAN networks (basic sensors), device metadata messages are almost the most bandwidth consuming messages. Metadata of a device (Model, Manufacturer, Version Number, etc.) of a device are stable in most cases over lifetime of a device. A device registry located at the edge router of a 6LoWPAN network MAY store information about device metadata exchanged through this edge router by sniffing messages. External metadata exchanged requests to devices in the 6LoWPAN network MAY be answered representative by the device registry. This is transparent to the devices and the clients. The device registry is a hidden intermediate in contrast to the discovery proxy. To provide end-to-end reliability and a guaranty about correct data for the response, the device registry SHOULD invoke the device by using the heartbeat message mechanism described in this draft, before answering the client. The heartbeat message and the response are much smaller compared to the device metadata messages.</t>
</section>
</section>
<section title="Message compression">
<t>Because DPWS bases on SOAP and thus on XML for data representation, XML compression techniques and/or encoding concepts have to be used to reduce message sizes.
</t>
<section title="HTTP compression">
<t>
DPWS for 6LoWPAN requires HTTP header compression. While <xref target="I-D.frank-6lowapp-chopan">CHOPAN</xref> describes a general and generic HTTP compression, this draft focuses on a more DPWS specific compression scheme as described here.</t>
<t>DPWS uses SOAP-over-HTTP binding for unicast messaging. All messages are using the POST method of HTTP in version 1.1. The transport specific addresses (target host) can be elided and derived from transport layer. In accordance to HTTP 1.1, all connection marked not explicit as close are keep-alive connections. But keep-alive connections are not applicable for WSN. The SOAPAction field is mandatory when using the SOAP-over-HTTP binding, but can be empty. Because DPWS includes usage of WS-Addressing, the SOAPAction field is redundant. The content-type of SOAP-over-HTTP is always application/soap+xml; charset=utf-8. To sum up, only few fields are left, which are analyzed by devices and clients and which provide useful information. A specific compression scheme is required to omit unnecessary HTTP header fields and allow a compression (optimized binary format) of the remaining required fields. The fields which have to be left are:</t>
<t>Content-length: This is required to allow resource constrained sensor nodes to know about length of data to be analyzed and thus e.g. required memory allocations.</t>
<t>HTTP Status Codes: The status code may be analyzed in error and fault cases. Status code 200/OK can be implied if this field is missing, to use it only in error/fault cases.</t>
</section>
<section title="SOAP compression">
<t>Different XML specific and XML non-specific compression schemes are already known. The following table presents an overview about existing schemes and compressors, including the EXI format of the W3C. The table shows resulting sizes of different compressors applied to DPWS messages. The values present the sizes of the SOAP envelopes (excluding HTTP headers) after compression and in the last line pure XML messages for comparison. The messages were recorded in a realistic scenario, implemented by using compliant DPWS toolkits. An overall number of 18 different message types are included in the evaluations and the table shows the averages over all these message types. Most of the compressors suffer from the simple XML structures. Sensor nodes will not provide complex services and thus simple message have to be assumed. These measurements might provide a basis for further discussions on message size optimizations.</t>
<t>For the measurements of EXI schema-informed format, separated results are presented: optimized and default. The default format used XML schema files as defined in DPWS without optimizations. This includes an inconsistency of different namespaces and versions used by DPWS and among Web services specifications (especially WS-Addressing and WS-Eventing). For the optimized format, some improvements are added. Most values of the XML tags and attributes in DPWS are well-known URIs. If these values are included in the XML schema files and with corrected dependencies, the average message size is reduced significantly as presented in the table.</t>
<texttable anchor="XML-compression" title="DPWS SOAP envelope compression comparison">
<ttcol align="center" align='left'>Compressor</ttcol>
<ttcol align="center">Average in Byte</ttcol>
<ttcol align="center">Average in %</ttcol>
<ttcol align="center">Minimum in Byte</ttcol>
<ttcol align="center">Maximum in Byte</ttcol>
<c>EXI schema-informed (optimized)</c><c>153,72</c><c>19,97</c><c>66,00</c><c>349,00</c>
<c>EXI schema-informed (default)</c><c>206,61</c><c>26,49</c><c>122,00</c><c>415,00</c>
<c>EXI schema-less</c><c>315,67</c><c>40,31</c><c>192,00</c><c>633,00</c>
<c>gzip (C=9)</c><c>419,83</c><c>54,54</c><c>271,00</c><c>749,00</c>
<c>XMLPPM</c><c>427,44</c><c>55,61</c><c>274,00</c><c>755,00</c>
<c>gzip (C=1)</c><c>437,83</c><c>56,96</c><c>297,00</c><c>799,00</c>
<c>Xmill (C=9)</c><c>457,89</c><c>59,46</c><c>300,00</c><c>824,00</c>
<c>Xmill (C=1)</c><c>463,56</c><c>60,14</c><c>303,00</c><c>852,00</c>
<c>bzip2 (C=1)</c><c>472,94</c><c>61,41</c><c>304,00</c><c>852,00</c>
<c>bzip2 (C=9)</c><c>474,78</c><c>61,82</c><c>315,00</c><c>852,00</c>
<c>Fast Infoset</c><c>561,89</c><c>69,70</c><c>315,00</c><c>1301,00</c>
<c>XML</c><c>814,89</c><c>100,00</c><c>418,00</c><c>2089,00</c>
</texttable>
</section>
<section title="Compression integration">
<t>This section describes a general point, which might be discussed more in general in 6LoWAPP. </t>
<section title="Payload compression">
<t>Many protocols (like DPWS) already provide concepts for discovery of devices (ad-hoc networking), data dissemination, eventing, etc. 6LoWPAN protocols allow a seamless connectivity of IP networks with wireless sensor networks, without the need for application layer gateways. These gateways must be aware of application layer data and need an understanding of semantics of payload. The communication with existing networking devices or other existing implementations must be transparent for these external hosts. Application layer data compression and encoding should only affect the 6LoWPAN network and communication inside the network, like 6LoWPAN does with IPv6 headers. But payload on application layer is not self-contained in one packet like IP, TCP and UDP headers. Defining new extension to be implemented by the external nodes is not a proper solution and violates the core concept of 6LoWPAN protocols.</t>
<t>New possibilities for application layer data encoding must be found, to allow efficient data encoding for traffic inside the 6LoWPAN network without affecting external communication. A new Encoding Router (ER) role might be defined. This ER is located at the edge router and not only translates compressed network and transport layer protocols, but also standardized application layer encoding and compression (e.g. EXI format in compliant XML/SOAP envelopes). This requires no understanding of semantics of the payload, but allows a seamless connectivity. The deployment of an ER might violate the layered model, because the ER must receive external message as representative to the 6LoWPAN nodes, encodes the messages and forwards them (outgoing traffic vice versa). But protocols might require correct transport layer addresses for origin and target hosts. Thus, adaptions to transport layer header fields (TCP and UDP) are required at runtime to hide the transparent intermediate ER.<!-- Not every ER might implement all application layer encoding protocols. Application layer packet inspection techniques must be deployed, to allow a decision system based on encoding capabilities of the ER. --></t>
</section>
<section title="TCP vs. UDP">
<t>TCP makes use of mechanisms like sliding window and flow control, to optimize throughput. These mechanisms are questionable in wireless sensor networks. Hence, the above described Encoding Router (ER) might also allow an throughput optimized external communication all the way to the ER and more optimized mechanisms in the 6LoWPAN networks. To reduce TCP overhead, also UDP might be used inside 6LoWPAN networks instead. But most application layer protocols base on TCP because of the required end-to-end reliability. The usage of the lightweight UDP for internal communication instead of TCP would require additional mechanisms to assure end-to-end reliability between endpoints. Also definition of an extension for UDP to provide this functionality is possible, but reinventing TCP must be omitted.</t>
</section>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>The new defined discovery addresses have to be registered at IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>No security issues have been identified in this draft.</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"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&I-D.frank-6lowapp-chopan;
&I-D.ietf-6lowpan-nd;
<!-- A reference written by by an organization not a person. -->
<reference anchor="WS-DD"
target="www.oasis-open.org/committees/ws-dd/">
<front>
<title>OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC</title>
<author>
<organization>OASIS Open</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="DPWS"
target="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01">
<front>
<title>OASIS Devices Profile for Web Services (DPWS) Version 1.1</title>
<author fullname="Dan Driscoll" surname ="Driscoll">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="Antoine" surname ="Mensch">
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="WS-Discovery"
target="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<front>
<title>OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1</title>
<author fullname="Vipul Modi" surname ="Modi">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="Devon Kemp" surname ="Kemp">
<organization>Canon Inc.</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="SOAP-over-UDP"
target="http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.html">
<front>
<title>OASIS SOAP-over-UDP Version 1.1</title>
<author fullname="Ram Jeyaraman" surname ="Jeyaraman">
<organization>Microsoft Corporation</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="EXI-format"
target="http://www.w3.org/TR/2009/CR-exi-20091208/">
<front>
<title>W3C Efficient XML Interchange (EXI) Format 1.0 Candidate Recommendation</title>
<author fullname="John Schneider" surname ="Scheider">
<organization>AgileDelta, Inc.</organization>
</author>
<author fullname="Takuki Kamiya" surname ="Kamiya">
<organization>Fujitsu Laboratories of America, Inc.</organization>
</author>
<date month="December" year="2009" />
</front>
</reference>
<reference anchor="WSDL"
target="http://www.w3.org/TR/2009/CR-exi-20091208/">
<front>
<title>W3C Web Services Description Language (WSDL) 1.1</title>
<author fullname="Erik Christensen" surname ="Christensen">
<organization>Microsoft</organization>
</author>
<author fullname="Francisco Curbera" surname ="Curbera">
<organization>IBM Research</organization>
</author>
<author fullname="Greg Meredith" surname ="Meredith">
<organization>Microsoft</organization>
</author>
<author fullname="Sanjiva Weerawarana" surname ="Weerawarana">
<organization>IBM Research</organization>
</author>
<date month="March" year="2001" />
</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). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:50:04 |