One document matched: draft-gudmundsson-dns-srv-iana-registry-04.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc="yes" ?>
<?rfc symrefs='yes'?>
<?rfc compact='yes' ?>
<rfc ipr='trust200902' category='std'>
<!-- ugly solution to having the date live in the file that changes with
each version -->
<front>
<title abbrev="IANA SRV registry">
Creation of a Registry for DNS SRV Record Service Prefixes
</title>
<author initials="O." surname="Gudmundsson" fullname="Olafur Gudmundsson">
<organization>
Shinkuro Inc.
</organization>
<address>
<postal>
<street> 4922 Fairmont Avenue, Suite 250 </street>
<city> Bethesda </city>
<region> MD </region>
<code> 20814 </code>
<country> USA </country>
</postal>
<email> ogud@ogud.com </email>
</address>
</author>
<author initials="A." surname="Hoenes" fullname="Alfred Hoenes">
<organization>
TR-Sys
</organization>
<address>
<postal>
<street> Gerlinger Str. 12 </street>
<city> Ditzingen </city>
<code> D-71254 </code>
<country> Germany </country>
</postal>
<email> ah@TR-Sys.de </email>
</address>
</author>
<date month="October" year="2009" />
<area>
Apps
</area>
<workgroup>
Network Working Group
</workgroup>
<keyword> DNS </keyword>
<keyword> SRV </keyword>
<keyword> IANA </keyword>
<keyword> Service location </keyword>
<abstract>
<t>
The DNS SRV record has been specified in RFC 2052 and RFC 2782.
These two RFCs did not specify an IANA registry for names of the
services using SRV records as defined by various protocols.
This document creates such a registry and populates it.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The SRV resource record (RR) was originally introduced in
<xref target="RFC2052">RFC 2052</xref> as an experimental extension
to the Domain Name System (DNS).
It proved a highly valuable addition for service location and
provisioning.
The SRV record was thus standardized in
<xref target="RFC2782">RFC 2782</xref>.
The main difference between these two versions is the use of the
underscore ("_") prefix character in names to avoid naming conflicts between
service names and regular names.
</t>
<t>
The presentation form of the SRV resource record (RR type 33),
including the recommended naming structure for its use,
is as follows <xref target="RFC2782"></xref>:
</t>
<t>
<list style="empty">
<t>
_Service._Proto.Name SRV Priority Weight Port Target
</t>
</list>
</t>
<t>
The "_Service" label indicates the name of the Service/Application that
is being offered. The "_Proto" label denotes the name of the transport
protocol to be used for the service.
"Name" is the domain name that is offering the service.
The PORT field is the port number over which the service is provided
at the Target name. The Priority and Weight fields are used for
selecting among multiple SRV records at the same owner name.
</t>
<t>
RFC 2782 says that the source of names for "Service" and "Proto" is
"Assigned Numbers" (STD2) or a locally defined repository.
</t>
<t>
<list style="hanging">
<t hangText="Note:">
The STD2 series of documents was obsoleted by
<xref target="RFC3232">RFC 3232</xref> and IANA registration
publication was handed over to on-line registries maintained by IANA.
Unfortunately it is not explicitly explained in RFC 2782 which
section of STD2 it is referring to, nor does RFC 3232 help.
<!--
OLD: By common knowledge, the corresponding IANA registry's
are the two "Port Numbers" registries.
Hmmm.
There always was one combined port number registry for TCP & UDP!
After studying 2782, the following text seems a better match:
-->
By common knowledge, RFC 2782 referred to the Keyword columns of
the "Protocol Numbers" and "Port Numbers" IANA registries.
</t>
</list>
</t>
<t>
However, upon reflection, both alternatives do not seem to make
particular sense:
</t>
<t>
<list style="symbols">
<t>
As SRV records contain the port where each server provides
the service, the outmost utility of SRV RRs is for services
that do not have a registered port number. Also, the number
of ports available is small compared to the possible number
of service names that could be registered. Therefore, the
"Port Number" registry needs a more strict registration policy
and is not the proper place for registering Service names for
use with SRV resource records.
</t>
<t>
Having locally defined lists of Service and/or Proto names
would equally allow to list the full service information
in such local databases and thus make the usage of SRV
records redundant. In any case, this scenario is not
applicable for publicly available services where potential
clients are not under the control of the authority offering
the services, and hence most probably would have no access
to the proper "locally provided" information.
The reader should be reminded that locally maintained database
solutions generally scale very poorly, and that this once was
the major momentum for the deployment of the Domain Name System.
</t>
</list>
</t>
<t>
For these reasons, this document creates a separate IANA registry
for Services that allow or specify service discovery via SRV look-up.
</t>
<!-- DISCUSS:
Should the *Protocol* be mentioned here as well ?
Preexisting practice was defining specific service/protocol
combinations only!
It also might be wise consider the new strategy being
developed in draft-ietf-tsvwg-iana-ports for registering
port+proto combinations.
-->
<!-- COMMENT:
OG thinks that the "Service" name should be the same and
unique for all "Protocol" even though an application only
envisions using TCP the registration should block any other
registrations for SCTP
-->
<t>
<list style="hanging">
<t hangText="Note:">
A couple of RFCs published in the past pretend to have registered
with IANA particular SRV Service/Protocol combinations, but
at the time of this writing, evidence shows that this did not
happen actually. Section 4.2 tries to collect this past wisdom
to initiallly populate the new registry.
</t>
</list>
</t>
<t>
This Service Registry explicitly removes the constraint that
services need a port number registration.
The registration requirement for this new registry is set low
in order to make it relatively easy to register a new service name.
</t>
<t>
To a large extent, the requirement to register port numbers can be
eliminated by encouraging SRV for service discovery and location
in all new application protocols. For this reason, there ought not
be a name conflict between what is registered in the SRV
registry defined in this document and the legacy service names
in the port numbers registry. See
<xref target='Collision'></xref> for elaborations
on such name conflicts.
</t>
<t>
In the spirit of BCP 17, <xref target="RFC2219">RFC 2219</xref>,
this registry should also help
providing an orderly substitute for the poorly specified
Well-Known Network Service Alias names.
</t>
<t>
Note: <xref target="RFC5507">RFC 5507</xref>, discusses the
use of "underscore labels" in the DNS more generally, from the
architectural point of view of the IAB.
</t>
<section 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">RFC 2119</xref> .
</t>
</section>
</section>
<section title="SRV Service Prefix Registry Considerations">
<t>
Registering a new service should be easy and painless process;
all that is needed is a pointer to a service description.
In some cases, applicants may not want to release the service/protocol
specification, and that is fine.
</t>
<!-- OG: What I wanted to say is a new colum in the table should be hard
to register but that is not realy material here so I shortened
this and got rid of the transport protocol.
-->
<!-- AH: Hmmm. -- Should be reconsidered!
That does not match preexisting practice of defining
specific service/protocol combinations only!
-->
<section title="To _ or Not To _">
<!-- AH: "transports" replaced by "protocols" below -->
<t>
The original SRV RFC used regular DNS names for service and
transport names. This was shown to cause some name conflicts.
For example, it is impossible to have the name "TCP" delegation and
also provide a service on http.tcp. For this reason, the current
SRV RFC specifies the use of underscore in front of all names for both
protocols and services. The argument for following this
nomenclature for protocols is clear and needed. On the other
hand, having a full DNS name space created on the left of each
protocol name, the argument for name collision in the
services does not apply. Arguments that the presence of
the underscore character makes it easier to spot that this is a
service are not convincing.
A possible future extension to allow IDN Service names may only
work if the underscore prefix is not used.
</t>
</section>
<section title="Service Name Maintenance">
<!-- AH: made text more precise w.r.t. characters vs. octets,
needed after introducing the idea of I18N and IDN;
I expects registrants will start thinking in
Unicode characters, and IDN will blow up
the number of octets needed significantly -->
<t>
As Service names are a DNS label, the strings can be up to 63
octets long. This is a
large enough space that reuse and reclaiming of names is not
an issue, unlike for the port space.
</t>
<!-- AH added considerations for other maintenance operations -->
<t>
However, applicants (or their provably legitimate successors)
can later request updates to the contact information and/or
references, and anyone can add another protocol for an
existing service, based on additional specification.
Such requests, when sent to IANA, must clearly be marked as
change requests.
</t>
</section>
<!-- OG: Regular expressions are a bad idea I'm told
so I'm dropping this section IANA hated this idea -->
<!-- Eliminating this section
<section title="Regular Expression in Service Registrations">
<t>
There are cases were a registrant may want to register a
collection of names that all follow a pattern like
"my-updates-21yy" or "Producer-model_number". In the first case
the registration would be for "My-updates-21[0-9][0-9]" and in
the second case "Producer-.+". These registrations should be as
specific as possible avoiding cases like "http.+" that collides
with https. If a regular expression in a request collides with
an existing string, then it should be rejected. Only
registrations with regular expressions at the end of the string
are allowed.
</t>
</section>
-->
<!-- AH: Idea:
Should there be at least one hyphen to the left of the wildcard?
Terminology (unresolved above):
A specific character also is an (elemntary) regular expression.
How about using "wildcard" or "multi-valued term(s)" above ?
-->
<section title="Name Collisions in Service Registrations" anchor='Collision' >
<t>
As this document allows registrations of NEW services without
the underscore ("_") prefix, these registrations MUST NOT
collide with pre-existing registrations that start with
or without the underscore prefix.
</t>
<!-- AH:
I recently have learned that case-insensitive comparison
is a very subtle problem in Unicode. I have proactively
changed the language to avoid phrasing that has been
challenged in other WGs.
-->
<t>
A name collision is defined to occur if two
labels compare equal under case-insensitive comparison
after stripping of the underscore prefix (if any) from both.
<!-- OG: IANA wanted this removed.
Furthermore, to provide a grace period where existing names can
be registered, for one calendar year after this document is
published as an RFC, no registrations without "_" will be
accepted.
-->
<!-- AH: I guess this remark is misplaced/outdated now. -->
</t>
<t>
In registering a new name in the SRV registry there MUST
not be a name conflict with the "PORT NUMBERS" registry keyword field.
</t>
<t>
New registraions in the "PORT NUMBERS" MUST NOT create a
name confict with the SRV registry.
</t>
</section>
</section>
<section title="SRV Protocol Labels" anchor="Subreg1">
<!-- AH: addend Labels for balance with next section and IANA Cons. -->
<!--
AH: ATTENTION!
As mentioned above, previous practice was to almost always
specify only specific combinations.
The most recent example, RFC 5389, is most convincing in
that this is really needed.
IMO, it should be considered to amalgamate this section with 4.*.
-->
<!-- AH: striked one instance of Transport,
and added text for better explanation.
Added headline for transport protocols into table for balance
-->
<t>
This section contains the known Protocol identifiers
to be entered into the SRV Protocol Labels sub-registry.
</t>
<t>
First, the IETF-specified transport protocols are listed,
with the common labels also appearing in the IANA "Protocols"
registry.
</t>
<t>
In a number of RFCs there have been examples where
services/protocols are defined to work over
"Overlay" (or "Substrate") protocols such as xmpp and http.
These are added next.
</t>
<t>
Table 1 lists the labels assigned to IETF standardized
transport protocols, and those specified for other substrate
protocols in existing RFCs published before this document.
It represents the initial contents of the SRV Protocol Labels
sub-registry.
</t>
<texttable anchor='Transport Protocol registry'>
<ttcol align='left'>Protocol</ttcol>
<ttcol align='left'>References</ttcol>
<c>Transport protocols </c> <c> </c>
<c>_tcp </c><c> <xref target="RFC0793">RFC 793</xref></c>
<c>_udp </c><c> <xref target="RFC0768">RFC 768</xref></c>
<c>_dccp </c><c> <xref target="RFC4340">RFC 4340</xref></c>
<c>_sctp </c><c> <xref target="RFC4960">RFC 4960</xref></c>
<c>Overlay protocols </c> <c> </c>
<!--
<ttcol align='left'>Overlay</ttcol>
<ttcol align='left'>References</ttcol>
-->
<c>_http </c><c> <xref target="RFC4386">RFC 4386</xref></c>
<c>_ipv6 </c><c> <xref target="RFC5026">RFC 5026</xref></c>
<c>_ldap </c><c> <xref target="RFC4386">RFC 4386</xref></c>
<c>_sip </c><c> <xref target="RFC5509">RFC 5509</xref></c>
<c>_ocsp </c><c> <xref target="RFC4386">RFC 4386</xref></c>
<c>_xmpp </c><c> <xref target="RFC3921">RFC 3921</xref></c>
</texttable>
<t>
NOTE #1: For the purpose of the _Protocol labels and this registry,
UDP-Lite <xref target="RFC3828"></xref> is treated
as indistinguishable from UDP <xref target="RFC0768"></xref>.
</t>
<t>
NOTE #2: There have been a few underscore protocol labels defined
for use by specific mail service databases such as
"_domainkey" and "_vouch"; these are not registered anywhere.
The related specifications do not employ SRV RRs however;
therefore these labels are currently regarded as out of scope.
It would be possible to register these in the registry above as
RESERVED labels, to capture their use and avoid label collisions,
if that is deemed useful.
</t>
</section>
<!-- OG: We used the names "SRV Application ..." and "SRV Service ..." --
-- interchangably I changed all to SRV Service ...
-->
<section title="SRV Service Labels">
<!-- AH: should we swap the 2 sub-sections below, 4.1 and 4.2 ? -->
<!-- AH: since effectively _Service._Protocol pairs are registered,
I have changed the headline to match the IANA Cons. Section -->
<section title="SRV Service Prefix Registration Template">
<t>
Submit registrations to TDB@TDB
</t>
<t>
[[ RFC Editor Note: final email address to be supplied by IANA! ]]
</t>
<t>
Registration of SRV Service Prefix
<list style='letters'>
<!-- AH: should we add this one? OG: YES -->
<t> Kind of request: (new) or (update) </t>
<t> Registrant name: </t>
<t> Organization: </t>
<t> Contact e-mail and international phone number: </t>
<t> Name of Service: </t>
<t> Protocol(s) used: </t>
<t> Reference to document(s) defining the service, (optional): </t>
<t> Short Service description (optional): </t>
<t> Delay publication: Y/N</t>
</list>
</t>
<t>
IANA will archive the accepted templates and make
them available via links in the registry.
</t>
<t>
<!-- OG: Stewart Chesire and IANA wanted this added -->
<!-- AH: and I have added text to reinforce the uniqueness -->
IANA will accept and act upon applications for service identifiers,
provided there is no Service name collision within the
SRV Service Prefixes registry or with the Port Numbers registry.
The publication of such assignments can be
deferred up to 30 days from the receipt of the application. Please
specify if delay is requested.
</t>
</section>
<section title="Initial SRV Service Labels Registry Contents"
anchor="Subreg2">
<!-- AH: matched title with IANA Cons. section -->
<t>
This section is expected to contain the most common service labels
defined in the IETF that are in use with and without underscore prefix.
It is expected that the template above will be used to register
other service labels that are in common use.
</t>
<t>
Table 2 specifies the initial contents of the SRV Service Labels
sub-registry.
This list is based on DNS server logs from September 2008
and strings found in RFCs (published before September 2009).
</t>
<!--
I have harvested all RFCs and added much stuff to the table below,
keeping it in collation order / fixing that where wrong ! A.H.
-->
<!-- OG: Cool thanks I harvested the recent 5xxx RFC's as well -->
<!-- OG This table does not have full references and I prefer to keep it
that way -->
<texttable anchor='table_services'>
<!-- OG: we do not need this
<preamble>
Registry format:
</preamble>
-->
<ttcol align='left'> Service label </ttcol>
<ttcol align='left'> Protocol(s) defined </ttcol>
<ttcol align='left'> Reference(s): </ttcol>
<c> _apex-edge </c> <c> _tcp </c> <c> RFC 3340 </c>
<c> _apex-mesh </c> <c> _tcp </c> <c> RFC 3340 </c>
<c> _beep</c> <c> _tcp </c> <c> RFC 3620 </c>
<c> _capwap-control</c> <c> _upd </c> <c> RFC 5415 </c>
<c> _certificates </c> <c> _tcp </c> <c> RFC 4387 </c>
<c> _crls </c> <c> _tcp </c> <c> RFC 4387 </c>
<c> _diameter </c> <c> _tcp, _sctp </c> <c> RFC 3588 </c>
<c> _dns-llq-tls </c> <c> _tcp </c> <c> </c>
<c> _dns-sd </c> <c> _upd </c> <c> </c>
<c> _dns-update </c> <c> _upd </c> <c> </c>
<c> _dvbservdsc </c> <c> _udp, _tcp </c> <c> RFC 5328 </c>
<c> _im </c> <c> _xmpp, _sip </c> <c> RFC 3921, RFC 5509</c>
<c> _iris-lwz </c> <c> _udp </c> <c> RFC 3981 </c>
<c> _jabber </c> <c> _tcp </c> <c> </c>
<c> _kerberos </c> <c> _upd, _tcp </c> <c> RFC 4120</c>
<c> _ldap </c> <c> _tcp </c> <c> RFC 3088 </c>
<c> _mihcs </c> <c> _upd, _tcp , _scp</c> <c> RFC 5679</c>
<c> _mihes </c> <c> _upd, _tcp , _scp</c> <c> RFC 5679</c>
<c> _mihis </c> <c> _upd, _tcp , _scp</c> <c> RFC 5679</c>
<c> _mip6 </c> <c> _ipv6 </c> <c> RFC 5026, RFC 5555 </c>
<c> _msrps </c> <c> _tcp </c> <c> RFC 4976 </c>
<c> _mtqp </c> <c> _tcp </c> <c> RFC 3887 </c>
<c> _pkixrep </c> <c> _http, _ldap, _ocsp </c> <c> RFC 4386 </c>
<c> _pres </c> <c> _xmpp, _sip </c> <c> RFC 3921, RFC 5509</c>
<c> _pgp </c> <c> _tcp </c> <c> RFC 4387 </c>
<c> _pgprevocations </c> <c> _tcp </c> <c> RFC 4387 </c>
<c> _rwhois </c> <c> _tcp </c> <c> RFC 2167 </c>
<c> _soap-beep </c> <c> _tcp </c> <c> RFC 3288, RFC 4227 </c>
<c> _sip </c> <c> _udp, _tcp, _sctp </c> <c> RFC 3263, RFC 4168 </c>
<c> _sips</c> <c> _tcp, _sctp </c> <c> RFC 3263, RFC 4168 </c>
<c> _sipfederation </c> <c> _tcp </c> <c> </c>
<c> _slpda </c> <c> _udp, _tcp </c> <c> RFC 3832 </c>
<c> _stun </c> <c> _udp, _tcp </c> <c> RFC 4389 </c>
<c> _stuns </c> <c> _tcp </c> <c> RFC 4389 </c>
<c> _syslog </c> <c> _tcp </c> <c> RFC 3195 </c>
<c> _tunnel </c> <c> _tcp </c> <c> RFC 3620 </c>
<c> _xmlrpc-beep </c> <c> _tcp </c> <c> RFC 3529 </c>
<c> _xmpp</c> <c> _tcp </c> <c> RFC 3921 </c>
<c> _xmpp-client </c> <c> _tcp </c> <c> RFC 3920 </c>
<c> _xmpp-server </c> <c> _tcp </c> <c> RFC 3920 </c>
<!-- AH: moved that note up into the prose.
<postamble>
List based on DNS server logs from September 2008 and strings
found in RFCs (up to July 2009).
</postamble>
-->
</texttable>
</section>
<section title="RFC Examples and Pointers">
<t>
There are a few instances where RFCs have what looks like
SRV label names but are just examples and should not be
registered. This section for completeness contains any
such instances the editors are aware off.
</t>
<t>
<list style='symbols'>
<t> _iris-* RFC 3981 appendix A </t>
<t> _mail RFC 4985 </t>
<!-- more or less an example there; is there a spec for that? -->
<t> _ntp RFC 4085 </t>
<t> _pigen RFC 3091 </t>
<!-- An RFC is an RFC, independent of the publication *date* ! -->
<t> _telnet RFC 3620 </t>
<!-- more or less an example there; do NTP folks have a draft for that? -->
<t> _ssh RFC 4592 </t>
<!-- more or less an example there; do SSH folks have a draft for that? -->
</list>
</t>
<t>
There are a few instances where RFCs hint at external
SRV usage/names but the editors have not been able to track
down the documents.
</t>
<t>
<list style='symbols'>
<t>RFC 4123 says: ITU-T H.323 Annex O also defines SRV use. </t>
<t>RFC 4280 points to 3GPP specs defining use(s?) of SRV. </t>
</list>
</t>
</section>
</section>
<section title="Relationship to Other IANA Registries">
<!-- AH: removed indentation
<list style="hanging">
-->
<t>
The SRV Service Labels registry is not a replacement for the two,
more specific registries established by
<xref target="RFC3861">RFC 3861</xref>, the
"Instant Messaging SRV Protocol Label Registry"
currently located
at <eref target='http://www.iana.org/assignments/im-srv-labels'/>
and the "Presence SRV Protocol Label Registry"
currently located at
<eref target='http://www.iana.org/assignments/pres-srv-labels'/>
</t>
<t>
Currently, there is one registration ("_xmpp") in each of these
registries, performed by <xref target="RFC3921">RFC 3921</xref>,
and another, more recent registration ("_sip"), performed by
<xref target="RFC5509">RFC 5509</xref>,
and this is reflected above.
</t>
<t>
To avoid service name collisions, future registrations
in the above two registries should always be accompanied
by registration updates for the SRV Service Prefix registry.
</t>
<t>
The IANA "Public Key Infrastructure using X.509 (PKIX) Parameters"
"PKIX SRV Protocol Labels" sub-registry currently filed at
<eref target='http://www.iana.org/assignments/pkix-parameters'/>
contains a single entry for the service label "_pkixrep"
in combination with three protocols, based on
<xref target="RFC4386">RFC 4386</xref>,
which has been included in Table 2.
Arguably, that sub-registry might be abandoned by a future
update of <xref target="RFC4386"></xref>,
in favor of making use of the new, general-purpose registry
defined in this document, since it fulfills all requirements
posed in sections 2 amd 4 of that RFC.
</t>
<!-- AH: removed indentation
</list>
-->
</section>
<section title="Security Considerations">
<t>
This draft creates a registry that should have been created a long
time ago. This in its own does not have any security implications.
However it is hoped that the registry will provide valuable
information for administrators and security policy makers, to
the benefit of the overall security community of the Internet.
</t>
</section>
<section title="IANA Considerations">
<t>
This document creates a new IANA registry with 2 sub-registries.
The registry is named "DNS SRV Service Prefixes".
The policy for creating new sub-registries is "IETF Review"
<xref target="RFC5226"></xref>.
</t>
<t>
The first sub-registry is: "SRV Protocol Labels".
Allocation policy is:
"IETF Review" <xref target="RFC5226"></xref>.
The initial content of this sub-registry is specified by
Table 1 (<xref target='Subreg1'></xref>). <!-- Section 3 -->
</t>
<!-- [AH] next para commented out now (no discussion occurred)
<t> NOTE: If Overlay is split from the Protocol sub-registry
that becomes an additional action.
Do we need "Standard Action" policy
for "Transport" protocols vs. "IETF Review" for "Substrate"
protocols?
</t>
-->
<t>
The second sub-registry is: "SRV Service Labels".
Allocation policy is:
"First Come First Served <xref target="RFC5226"></xref>,
but MUST NOT conflict with service names in the Port Number registry"
(see <xref target='Collision'></xref>).
Rules for Labels to be registered are in Section 4.
The initial content of the registry is specified by
Table 2 (<xref target='Subreg2'></xref>). <!-- Section 4.2 -->
A Template for subsequent registrations is in Section 4.1.
IANA will archive and make available all accepted registrations
via links from the registry.
</t>
<t>
This document updates the allocation procedure of the PORT NUMBERS
registry located at http://www.iana.org/assignments/port-numbers
such that service names for new registrations MUST NOT conflict with
names registered as "SRV Service Labels".
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2782" ?>
<?rfc include="reference.RFC.5226" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2052" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2219" ?>
<?rfc include="reference.RFC.3232" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.3861" ?>
<?rfc include="reference.RFC.3921" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.4386" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5026" ?>
<?rfc include="reference.RFC.5507" ?>
<?rfc include="reference.RFC.5509" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:47:04 |