One document matched: draft-ietf-geopriv-local-civic-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902">
<front>
<title abbrev="Civic Extensions">Specifying Civic Address Extensions in PIDF-LO</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 242 212938</phone>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="R." surname="Barnes" fullname="Richard Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>NeuStar, Inc.</organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<author initials="R." surname="George" fullname="Robins George">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgan District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<phone>+86 755 2878 8314</phone>
<email>robinsg@huawei.com</email>
</address>
</author>
<date month="March" year="2011"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Extension</keyword>
<keyword>Local</keyword>
<keyword>Civic</keyword>
<keyword>Location</keyword>
<keyword>GEOPRIV</keyword>
<abstract>
<t>New fields are occasionally added to civic addresses. A backwardly-compatible mechanism for adding civic address elements to the Geopriv
civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address
forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Geopriv civic location specifications (<xref target="RFC4776"/>, <xref target="RFC5139"/>) define an XML and binary representtations for civic addresses that
allow for the expression of civic addresses. Guidance for the use of these formats for the civic addresses in different countries is included in <xref target="RFC5774"/>.
</t>
<t>Subsequent to these specifications being produced, use cases for extending the civic address format with new elements have emerged. Extension elements do not
readily fit existing elements, as recommended in <xref target="RFC5774"/>.
</t>
<t>The <xref target="RFC5139">XML format for civic addresses</xref> provides a mechanism that allows for the addition of standardized or privately understood
elements. A similar facility for private extension is not provided for <xref target="RFC4776">the DHCP format</xref>, though new specifications are able to define new CAtypes (civic address types).
</t>
<t>A recipient of a civic address in either format currently has no option other than to ignore elements that it does not understand. This results
in any elements that are unknown to that recipient being discarded if a recipient performs a translation between the two formats. In order for a new
extension to be preserved through translation by any recipient, the recipient has to understand the extension and know how to correlate an XML element with a CAtype.
</t>
<t>This document describes how new civic address elements are added. Extension always starts with the definition of XML elements.
A mechanism for carrying the extension in the DHCP format is described. A new XML namespace containing a small number of additional civic elements is also defined and can be used
as a template to illustrate how other extensions can be defined as required.
</t>
<t>These mechanisms ensure that any translation between formats can be performed consistently and without loss of information.
Translation between formats can occur without knowledge of every extension that is present.
</t>
<t>These additions described in this document are backwardly compatible. Existing implementations may cause extension information to be lost,
but the presence of extensions does not affect an implementation that conforms to either <xref target="RFC4776"/> or <xref target="RFC5139"/>.
</t>
<section title="Motivating Example">
<t>One instance where translation might be necessary is where a device receives location configuration using <xref target="RFC4776">DHCP</xref>.
Conversion of DHCP information to an XML form is necessary if the device wishes to use the DHCP-provided information in a range of applications, including
<xref target="RFC4079">location-based presence services</xref>, and <xref target="RFC5012">emergency calling</xref>.
</t>
<figure title="Conversion Scenario"><artwork><![CDATA[
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
]]></artwork></figure>
<t>The Device that performs the translation between the DHCP and XML formats might not be aware of some of the extensions that are in use.
Without knowledge of these extensions and how they are represented in XML, the Device is forced to discard them.
</t>
<t>These extensions could be useful - or critical - to the ultimate consumers of this information. For instance, an extension
element might provide a presence watcher with important information in locating the Device or an extension might be significant in choosing a particular call route.
</t>
</section>
<section anchor="terminology" title="Terminology">
<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"/>.
</t>
</section>
</section>
<section anchor="extend" title="Specifying Civic Address Extensions">
<t>The civic schema in <xref target="RFC5139"/> defines an ordered structure of elements that can be combined to describe a civic address.
The XML extension point at the end of this sequence is used to extend the address.
</t>
<t>New elements are defined in a new <xref target="XMLNS">XML namespace</xref>. This is true of address elements with significance within private or
localized domains, as well as those that are intended for global applicability.
</t>
<t>New elements SHOULD use the basic <spanx style="verb">caType</spanx> schema type defined in <xref target="RFC5139"/>. This type provides an optional <spanx style="verb">xml:lang</spanx> attribute.
</t>
<t>For example, suppose the (fictitious) Central Devon Canals Authority wishes to introduce a new civic element called "bridge". The authority defines an XML namespace that includes a "bridge" element. The namespace needs to be a unique URI, for example <spanx style="verb">http://devon.canals.org.uk/civic</spanx>.
</t>
<t>A civic address that includes the new "bridge" element is shown in <xref target="localcivic2"/>.
</t>
<figure anchor="localcivic2" title="Extended Civic Address Example">
<artwork><![CDATA[
<civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cdc="http://devon.canals.org.uk/civic">
<country>UK</country>
<A1>Devon</A1>
<A3>Monkokehampton</A3>
<RD>Deckport</RD>
<STS>Cross</STS>
<cdc:bridge>21451338</cdc:bridge>
</civicAddress>
]]></artwork>
</figure>
<t>An entity that receives this location information might not understand the extension address element. As long as the added element is able to be safely ignored, the remainder of the civic address can be used. The result is that the information is not as useful as it could be, but the added element does not prevent the use of the remainder of the address.
</t>
<t>The address can be passed to other applications, such as a <xref target="RFC5222">LoST server</xref>, without modification. If the application understands the added elements, it is able to make use of that information. For example, if this civic address is acquired using <xref target="RFC5985">HELD</xref>, it can be included in a LoST request directly.
</t>
</section>
<section title="Translating Unsupported Elements">
<t>Unsupported civic address elements can be carried without consequence only as long as the format of the address does not change. When converting between the XML and DHCP formats, these unsupported elements are necessarily discarded: the entity performing the translation has no way to know the correct element to use in the target format.
</t>
<t>All extensions MUST be defined using the mechanism described in this document. Extensions that use numeric CAtypes or other mechanisms cannot be safely translated between XML and DHCP representations.
</t>
<t>An entity that does not support these extension mechanisms is expected to remove elements it doesn't understand when performing conversions.
</t>
<section title="XML to DHCP Format Translation">
<t>Extensions to the <xref target="RFC5139">XML format</xref> are defined in a new <xref target="XMLNS">XML namespace</xref>.
</t>
<t>Extensions in the XML format can be added to a DHCP format civic address using an extension CAtype.
</t>
</section>
<section title="Extension Civic Address Type (CAtype)">
<t>The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: please replace XX here and in the figure below with the assigned code] includes three values that uniquely identify the XML extension and its value: a namespace URI, the local name of the XML element, and the text content of that element. These three values are all included in the value of the CAtype, each separated by a single whitespace character.
</t>
<figure anchor="extCAtype" title="XML Civic Address Extension CAtype">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAtype (XX) | Length | Namespace URI ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Namespace URI (continued) ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | XML element local name ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | Extension type value ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text <xref target="RFC3629"/>. A maximum of 255 octets is allowed. Octets consumed by the namespace URI and local name reduce the space available for values.
</t>
<t>This conversion only works for elements that have textual content and an optional <spanx style="verb">xml:lang</spanx> attribute. Elements with complex content or other attributes - aside from namespace bindings - MUST be ignored if they are not understood.
</t>
</section>
<section title="DHCP to XML Format Translation">
<t>The registration of a new CAtype following the process in <xref target="RFC4776"/> means that a recipient that does not know the equivalent XML is unable to produce a complete XML representation of the DHCP civic address. For this reason, this document ends the registration of new numeric CAtypes. No new registrations of numeric CAtypes can be made.
</t>
<t>In lieu of making new numerical CAtype assignments, this document creates a new extensionCA type which is defined in a manner that lets new civic elements be described in
DHCP form by carrying the name space and type name of the extension in parameters of the extensionCA type.
</t>
<t>When converting to XML, the namespace prefix used for the extension element is selected by the entity that performs the conversion.
</t>
</section>
<section title="Conversion Example">
<figure anchor="extended" title="XML Example with Multiple Extensions">
<preamble>The following example civic address contains two extensions:</preamble>
<artwork><![CDATA[
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.net/ns"
xmlns:ap="http://example.com/airport/5.0">
<country>US</country>
<A1>CA</A1>
<post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
]]></artwork>
</figure>
<figure anchor="localcivicdhcp" title="Converted DHCP Example with Multiple Extensions">
<preamble>This is converted to a DHCP form as follows:</preamble>
<artwork><![CDATA[
country = US
CAtype[0] = en-US
CAtype[1] = CA
CAtype[XX] = http://postsoftheworld.net/ns lamp 2471
CAtype[XX] = http://postsoftheworld.net/ns lamp AQ-374-4(c)
CAtype[XX] = http://example.com/airport/5.0 airport LAX
CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley
CAtype[XX] = http://example.com/airport/5.0 concourse G
CAtype[XX] = http://example.com/airport/5.0 gate 36B
]]></artwork>
</figure>
</section>
</section>
<section title="Civic Extensions">
<t>We use this new extension method to define some additional civic address elements which are needed to correctly encode civic locations in several countries.
The definition of these new civic address elements also serves as an example of how to define additional elements using the mechanisms described in this document.
</t>
<section title="Pole Number">
<t>In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the
label on the lamp post also carries the local emergency service number, such as "110", encouraging callers to use the pole number to identify their location.
</t>
<t>
<figure anchor="lamppost" title="Lamp post with emergency number">
<artwork><![CDATA[
_.-----,===.
| | (''''')
| | `---'
| |
| | ,---------,
| | ,---, |Emergency|
| | /|,-.|----->| Number |
| | / |110| '---------'
| | / |`-'|
|_|/ | 2 | ,---------,
| | | 1 | |Lamp Post|
| | | 2 |----->| Number |
|-| | 1 | '---------'
| |\ | 0 |
| | \ | 1 |
| | \ | 4 |
| | \|,,,|
_ | |
``-..|.|
``--.._
`'--.._
]]></artwork>
</figure>
</t>
</section>
<section title="Mile Post">
<t>On some roads, and many trails, railroad rights of way and other linear features, a post with a mile or kilometer distance from one
end of the feature may be found (a "milepost"). There are other cases of poles or markers with numeric indications that are not the
same as a "house number" or street address number.
</t>
</section>
<section title="Street Type Prefix">
<t>The civic schema defined in <xref target="RFC5139"/> allows the definition of address "123 Colorado Boulevard", but it does not allow for the easy expression
of "123 Boulevard Colorado". Adding a street-type prefix, allows street named in this manner to be more easily represented.
</t>
</section>
<section title="House Number Prefix">
<t>The civic schema defined in <xref target="RFC5139"/> provides house number suffix element, allowing one to express an address like "123A Main Street", but it does not contain
a corresponding house number prefix. The house number prefix element allows the expression of address such as "Z123 Main Street".
</t>
</section>
<section anchor="schema" title="XML Extension Schema">
<t>
<figure>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
<!-- Post Number -->
<xs:element name="PN" type="ca:caType"/>
<!-- Milepost -->
<xs:element name="MP" type="ca:caType"/>
<!-- Street-Type prefix -->
<xs:element name="STP" type="ca:caType"/>
<!-- House Number Prefix -->
<xs:element name="HNP" type="ca:caType"/>
</xs:schema>
]]></artwork>
</figure>
</t>
</section>
<section title="Extension examples">
<t>
<figure title="XML Example with Post Number and Mile Post">
<artwork><![CDATA[
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>I5</RD>
<cae:MP>248</cae:MP>
<cae:PN>22-109-689</cae:PN>
</civicAddress>
]]></artwork>
</figure>
<figure title="XML Example with Street prefix and House Number Prefix">
<artwork><![CDATA[
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>Colorado</RD>
<HNO>223</HNO>
<cae:STP>Boulevard</cae:STP>
<cae:HNP>A</cae:HNP>
</civicAddress>
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This document defines a formal way to extend the existing Geopriv civic address schema. No security threats are introduced by this document.</t>
<t>Security threats applicable to the civic address formats are described in <xref target="RFC4776"/> (DHCP) and <xref target="RFC5139"/> (XML).
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document alters the "CAtypes" registry established by <xref target="RFC4776"/>.
</t>
<section title="CAtype Registration for Extensions">
<t>IANA has allocated a CAtype code of XX for the extension CAtype.
</t>
<t>[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]
</t>
</section>
<section title="End of Numeric CAtype Registration">
<t>No further registration of numeric CAtypes is permitted, and the register created as part of <xref target="RFC4776"/> is cloased. New registrations in this registry use the registration template in <xref target="register"/>.
</t>
</section>
<section title="URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'">
<t>This document calls for IANA to register a new XML namespace, as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Civic Address Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the procedures in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.Winterbottom@andrew.com).</t>
<t>The XML for this schema can be found as the entirety of <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
<section anchor="register" title="Registration Template">
<t>New registrations in the "CAtypes" registry require the following information:
<list style="hanging">
<t hangText="CAtype:">The assigned numeric CAtype. All new registrations use the value XX. [[IANA/RFC-Editor: update XX] Existing registrations use their assigned value.
</t>
<t hangText="Namespace URI:">A unique identifier for the XML namespace used for the extension element.
</t>
<t hangText="Local Name:">The local name of an XML element that carries the civic address element.
</t>
<t hangText="Description:">A brief description of the semantics of the civic address element.
</t>
<t hangText="(Optional) Example:">One or more simple examples of the element.
</t>
<t hangText="Contact:">Contact details for the person providing the extension.
</t>
<t hangText="(Optional) Specification:">A reference to a specification for the civic address element.
</t>
<t hangText="(Optional) Schema:">A reference to a formal schema (XML schema, RelaxNG, or other form) that defines the extension.
</t>
</list>
</t>
<t>Registrations from <xref target="RFC4776"/> and <xref target="RFC5139"/> are registered with the following form:
<list style="hanging">
<t hangText="CAtype:">(The existing CAtype.)
</t>
<t hangText="Namespace URI:">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
</t>
<t hangText="Local Name:">(The contents of the PIDF column.)
</t>
<t hangText="Description:">(The existing description for the element, including a note about the equivalent NENA field, if present.)
</t>
<t hangText="Contact:">The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org).
</t>
<t hangText="Specification:">RFC4776 and RFC5139
</t>
<t hangText="Schema:">urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
</t>
</list>
</t>
<t>Registration of the schema defined in this document in <xref target="schema"/>.
<list style="hanging">
<t hangText="CAtype:">The assigned numeric CAtype value is XX. [[IANA/RFC-Editor: update XX]
</t>
<t hangText="Namespace URI:">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
</t>
<t hangText="Local Name:">PN, MP, STP, HNP
</t>
<t hangText="Description:">PN: Post number that is attributed to a lamp post or utility pole.
</t>
<t hangText="Description:">MP: Mile Post a marker indicating distance to or from a place (often a town).
</t>
<t hangText="Description:">STP: Street Type Prefix.
</t>
<t hangText="Description:">HNP: House Number Prefix.
</t>
<t hangText="Contact:">The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org).
</t>
<t hangText="Specification:"> RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
</t>
<t hangText="Schema:">urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
</t>
</list>
</t>
</section>
<section title="Registration Policy and Expert Guidance">
<t>The "CAtypes" registry is altered to operate on a registration policy of "Expert Review", and optionally "Specification Required" <xref target="RFC5226"/>.
</t>
<t>The registration rules for "Specification Required" are followed only if a registration includes a reference to a specification. Registrations can be made without a specification reference.
</t>
<t>All registrations are reviewed to identify potential duplication between registered elements. Duplicated semantics are not prohibited in the registry, though it is preferred if existing elements are used. The expert review is advised to recommend the use of existing elements following the guidance in <xref target="RFC5774"/>. Any registration that is a duplicate or could be considered a close match for the semantics of an existing element SHOULD include a discussion of the reasons that the existing element was not reused.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to anyone who has tried to extend the civic schema and found it a little unintuitive.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"?>
<!-- <reference anchor="XML"
target="http://www.w3.org/TR/2008/REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="E." surname="Maler" fullname="Eve Maler">
<organization />
</author>
<author initials="F." surname="Yergeau" fullname="François Yergeau">
<organization />
</author>
<author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization />
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization />
</author>
<author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
<organization />
</author>
<date month="November" day="26" year="2008" />
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126" />
<format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-20081126" />
</reference>
-->
<reference anchor="XMLNS"
target="http://www.w3.org/TR/2006/REC-xml-names11-20060816">
<front>
<title>Namespaces in XML 1.1 (Second Edition)</title>
<author initials="D." surname="Hollander" fullname="Dave Hollander">
<organization />
</author>
<author initials="A." surname="Layman" fullname="Andrew Layman">
<organization />
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization />
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization />
</author>
<date month="August" day="16" year="2006" />
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-names11-20060816" />
<format type="HTML" target="http://www.w3.org/TR/2006/REC-xml-names11-20060816" />
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4079.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5774.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:29:28 |