rfc9749xml2.original.xml   rfc9749.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.
3.6) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY RFC8620 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
20.xml">
<!ENTITY RFC8030 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
30.xml">
<!ENTITY RFC8292 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
92.xml">
<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml">
<!ENTITY RFC7515 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
15.xml">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-jmap-webpush-vapid-10" category="std" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
consensus="true" submissionType="IETF"> -ietf-jmap-webpush-vapid-10" number="9749" category="std" consensus="true" submi
<front> ssionType="IETF" version="3" xml:lang="en" tocInclude="true" updates="" obsolete
<title>Use of VAPID in JMAP WebPush</title> s="" symRefs="true">
<front>
<title abbrev="Use of VAPID in JMAP Web Push">Use of Voluntary Application S
erver Identification (VAPID) in JSON Meta Application Protocol (JMAP) Web Push</
title>
<seriesInfo name="RFC" value="9749"/>
<author initials="D." surname="Gultsch" fullname="Daniel Gultsch"> <author initials="D." surname="Gultsch" fullname="Daniel Gultsch">
<organization></organization>
<address> <address>
<email>daniel@gultsch.de</email> <email>daniel@gultsch.de</email>
</address> </address>
</author> </author>
<date year="2025" month="March"/>
<date year="2025" month="January" day="10"/> <area>ART</area>
<workgroup>jmap</workgroup>
<area>Internet</area>
<workgroup>JMAP</workgroup>
<abstract> <abstract>
<t>This document defines a method for JSON Meta Application Protocol (JMAP
<?line 45?> ) servers to advertise their
capability to authenticate Web Push notifications using the Voluntary
<t>This document defines a method for JMAP servers to advertise their capability Application Server Identification (VAPID) protocol.</t>
to authenticate WebPush notifications using the Voluntary Application Server Id
entification protocol.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 49?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name>
<t>JMAP <xref target="RFC8620"/> specifies how clients can subscribe to events u
sing a protocol that is compatible with WebPush <xref target="RFC8030"/>. Some p
ush services require that the application server authenticates all push messages
using the Voluntary Application Server Identification protocol <xref target="RF
C8292"/>. To facilitate that, the client (or user agent in WebPush terminology)
needs the VAPID public key of the application server to pass it along to the pus
h service when retrieving a new endpoint.</t>
</section>
<section anchor="conventions-used-in-this-document"><name>Conventions Used in Th
is Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
<?line -8?></t>
</section>
<section anchor="discovering-support-for-vapid"><name>Discovering Support for VA
PID</name>
<t>The JMAP capabilities object is returned as part of the standard JMAP session
object (see Section 2 of <xref target="RFC8620"/>). Servers supporting this spe
cification MUST add a property called "urn:ietf:params:jmap:webpush-vapid" to th
e capabilities object. The value of this property is an object that MUST contain
the following information:</t>
<t><list style="symbols">
<t>applicationServerKey: "String" <vspace blankLines='1'/>
The ECDSA public key that the push service will use to authenticate the applicat
ion server, in its uncompressed form (as described in <xref target="X9.62"/> Ann
ex A) and encoded using base64url encoding <xref target="RFC7515"/>. Current sys
tems use the P-256 curve <xref target="FIPS186"/>.</t>
</list></t>
<t>Informative Note: The format of the application server key was chosen to ensu
re compatibility with the browser API (<xref target="PUSH-API"/>, Section 7.2),
allowing the key to be directly copied and used without additional transformatio
n. Additionally, as noted in <xref target="RFC8292"/>, Section 3.2, the X9.62 en
coding simplifies key comparisons and is more compact than alternative formats.<
/t>
</section>
<section anchor="issuing-push-notifications"><name>Issuing Push Notifications</n
ame>
<t>Every time the server sends a push message to a PushSubscription URL it MUST
authenticate the POST request using the protocol outlined in <xref target="RFC82
92"/>. This includes both StateChange events and PushVerification notifications.
To authenticate the request, the server MUST use a JWT signed by the private ke
y corresponding to the application server key. This application server key MUST
be the one that was advertised in the capabilities object at the time the PushSu
bscription was created.</t>
</section>
<section anchor="key-rotation"><name>Key Rotation</name>
<t>When a server needs to replace its VAPID key, it MUST update the sessionState
per <xref target="RFC8620"/>. The client MUST monitor the JMAP session object f
or changes to the VAPID key and MUST recreate its push subscription when it dete
cts such a change.</t>
<t>After key rotation, the server MAY continue to send push notifications for ex
isting push subscriptions using the old application server key for a transitiona
l period. This allows clients time to recreate their respective push subscriptio
ns. At the end of the transitional period (or immediately for implementations th
at do not have one), the server MUST destroy push subscriptions that use the old
key.</t>
<t>When destroying push subscriptions that include the data type <spanx style="v
erb">PushSubscription</spanx>, the server MAY issue one final StateChange push n
otification using the old URL and application server key to notify the client of
changes to the PushSubscription data type. This prompts the client to make a <s
panx style="verb">PushSubscription/changes</spanx> method call. The response to
this call will contain an updated sessionState, which refers to a session object
that contains the new VAPID key.</t>
<t>A race condition can occur when the server updates its VAPID key after the cl
ient has refreshed the session object but before calling the PushSubscription/se
t method. This situation causes the server to send a PushVerification object to
a push resource URL that is now associated with an outdated VAPID key. Consequen
tly, the push service will reject the PushVerification with a 403 (Forbidden) st
atus code, as specified in <xref target="RFC8292"/>.</t>
<t>To alleviate this problem, the client MUST check if the sessionState in the r
esponse from the PushSubscription/set method points to a session object with an
applicationServerKey that matches their expectations. If there is a mismatch, th
e client MAY retry creating the PushSubscription. Additionally, the client MAY d
estroy the PushSubscription from the earlier, failed attempt.</t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>During the key rotation process, synchronization issues between the client an
d server may arise. Specifically, a client might restrict a push subscription wi
th the push service to an outdated key, while the server sends the PushVerificat
ion object authenticated with the newly rotated key. This mismatch leads to the
push service rejecting the PushVerification request with HTTP status code 403, a
s specified in <xref target="RFC8292"/>, Section 4.2.</t>
<t>Per the requirements of <xref target="RFC8620"/>, Section 7.2, the server MUS
T NOT retry the rejected PushVerification request. Consequently, the PushVerific
ation object will not be delivered to the client.</t>
<t>To mitigate such issues, the client is responsible for detecting and resolvin
g any synchronization discrepancies, as outlined in the 'Key Rotation' section o
f this document.</t>
<t>The inclusion of the <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</
spanx> property in the JMAP capabilities object is limited to providing informat
ion about the server's support for Voluntary Application Server Identification (
VAPID). This property does not reveal sensitive information, nor does it introdu
ce new security or privacy risks beyond those inherent to JMAP and WebPush. The
security considerations for JMAP (<xref target="RFC8620"/>, especially Section 8
.6 and Section 8.7 of that document), WebPush (<xref target="RFC8030"/>) and VAP
ID (<xref target="RFC8292"/>) apply to this document.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<section anchor="registration-of-the-jmap-capability-for-vapid"><name>Registrati
on of the JMAP Capability for VAPID</name>
<t>This specification requests IANA to register a new capability in the JMAP Cap
abilities registry with the following data:</t>
<t>Capability Name: <spanx style="verb">urn:ietf:params:jmap:webpush-vapid</span
x></t>
<t>Specification document: this document</t>
<t>Intended use: common</t> <t>JMAP <xref target="RFC8620"/> specifies how clients can subscribe to ev
ents using a protocol that is compatible with Web Push <xref target="RFC8030"/>.
Some push services require that the application server authenticate all push me
ssages using the VAPID protocol <xref target="RFC8292"/>. To facilitate that, th
e client (or user agent in Web Push terminology) needs the VAPID public key of t
he application server to pass along to the push service when retrieving a new en
dpoint.</t>
</section>
<section anchor="conventions-used-in-this-document">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section anchor="discovering-support-for-vapid">
<name>Discovering Support for VAPID</name>
<t>The JMAP capabilities object is returned as part of the standard JMAP s
ession object (see <xref section="2" sectionFormat="of" target="RFC8620"/>). Ser
vers supporting this specification <bcp14>MUST</bcp14> add a property called <tt
>urn:ietf:params:jmap:webpush-vapid</tt> to the capabilities object. The value o
f this property is an object that <bcp14>MUST</bcp14> contain the following info
rmation:</t>
<t>Change Controller: IETF</t> <dl spacing="compact" newline="true">
<dt><tt>applicationServerKey</tt>: "String"</dt>
<dd>The Elliptic Curve Digital Signature Algorithm (ECDSA) public key
that the push service will use to
authenticate the application server, in its uncompressed form (as
described in Section 2.3.3 of <xref target="SEC1"/>) and encoded using
base64url encoding <xref target="RFC7515"/>. Current systems use the
P-256 curve <xref target="FIPS186"/>.</dd>
</dl>
<t>Security and privacy considerations: this document, Section 6</t> <aside>
<t>Informative Note: The format of the application server key was chosen
to ensure compatibility with the browser API (Section 7.2 of <xref target="PUSH-
API"/>), allowing the key to be directly copied and used without additional tran
sformation. Additionally, as noted in <xref section="3.2" sectionFormat="of" tar
get="RFC8292"/>, the X9.62 encoding (which is compatible with SEC1 encoding) sim
plifies key comparisons and is more compact than alternative formats.</t>
</aside>
</section>
<section anchor="issuing-push-notifications">
<name>Issuing Push Notifications</name>
<t>Every time the server sends a push message to a <tt>PushSubscription</t
t> URL, it <bcp14>MUST</bcp14> authenticate the POST request using the protocol
outlined in <xref target="RFC8292"/>. This includes both <tt>StateChange</tt> ev
ents and <tt>PushVerification</tt> notifications. To authenticate the request, t
he server <bcp14>MUST</bcp14> use a JSON Web Token (JWT) signed by the private k
ey corresponding to the application server key. This application server key <bcp
14>MUST</bcp14> be the one that was advertised in the capabilities object at the
time the <tt>PushSubscription</tt> was created.</t>
</section>
<section anchor="key-rotation">
<name>Key Rotation</name>
<t>When a server needs to replace its VAPID key, it <bcp14>MUST</bcp14> up
date the <tt>sessionState</tt> per <xref target="RFC8620"/>. The client <bcp14>M
UST</bcp14> monitor the JMAP session object for changes to the VAPID key and <bc
p14>MUST</bcp14> recreate its push subscription when it detects such a change.</
t>
<t>After key rotation, the server <bcp14>MAY</bcp14> continue to send push
notifications for existing push subscriptions using the old application server
key for a transitional period. This allows clients time to recreate their respec
tive push subscriptions. At the end of the transitional period (or immediately f
or implementations that do not have one), the server <bcp14>MUST</bcp14> destroy
push subscriptions that use the old key.</t>
<t>When destroying push subscriptions that include the data type <tt>PushS
ubscription</tt>, the server <bcp14>MAY</bcp14> issue one final <tt>StateChange<
/tt> push notification using the old URL and application server key to notify th
e client of changes to the <tt>PushSubscription</tt> data type. This prompts the
client to make a <tt>PushSubscription/changes</tt> method call. The response to
this call will contain an updated <tt>sessionState</tt>, which refers to a sess
ion object that contains the new VAPID key.</t>
</section> <t>A race condition can occur when the server updates its VAPID key after
</section> the client has refreshed the session object but before calling the <tt>PushSubsc
ription/set</tt> method. This situation causes the server to send a <tt>PushVeri
fication</tt> object to a push resource URL that is now associated with an outda
ted VAPID key. Consequently, the push service will reject the <tt>PushVerificati
on</tt> with a 403 (Forbidden) status code, as specified in <xref section="4.2"
sectionFormat="of" target="RFC8292"/>.</t>
<t>To alleviate this problem, the client <bcp14>MUST</bcp14> check if the
<tt>sessionState</tt> in the response from the <tt>PushSubscription/set</tt> met
hod points to a session object with an <tt>applicationServerKey</tt> that matche
s their expectations. If there is a mismatch, the client <bcp14>MAY</bcp14> retr
y creating the <tt>PushSubscription</tt>. Additionally, the client <bcp14>MAY</b
cp14> destroy the <tt>PushSubscription</tt> from the earlier, failed attempt.</t
>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>During the key rotation process, synchronization issues between the cli
ent and server may arise. Specifically, a client might restrict a push subscript
ion with the push service to an outdated key, while the server sends the <tt>Pus
hVerification</tt> object authenticated with the newly rotated key. This mismatc
h leads to the push service rejecting the <tt>PushVerification</tt> request with
a 403 (Forbidden) status code, as specified in <xref section="4.2" sectionForma
t="of" target="RFC8292"/>.</t>
<t>Per the requirements of <xref section="7.2" sectionFormat="of" target="
RFC8620"/>, the server <bcp14>MUST NOT</bcp14> retry the rejected <tt>PushVerifi
cation</tt> request. Consequently, the <tt>PushVerification</tt> object will not
be delivered to the client.</t>
<t>To mitigate such issues, the client is responsible for detecting and re
solving any synchronization discrepancies, as outlined in <xref target="key-rota
tion"/> of this document.</t>
<t>The inclusion of the <tt>urn:ietf:params:jmap:webpush-vapid</tt> proper
ty in the JMAP capabilities object is limited to providing information about the
server's support for VAPID. This property does not reveal sensitive information
, nor does it introduce new security or privacy risks beyond those inherent to J
MAP and Web Push. The security considerations for JMAP <xref target="RFC8620"/>
(especially Sections <xref section="8.6" sectionFormat="bare" target="RFC8620"/>
and <xref section="8.7" sectionFormat="bare" target="RFC8620"/>), Web Push <xre
f target="RFC8030"/>, and VAPID <xref target="RFC8292"/> apply to this document.
</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<section anchor="registration-of-the-jmap-capability-for-vapid">
<name>Registration of the JMAP Capability for VAPID</name>
<t>IANA has registered the following new capability in the "JMAP Capabil
ities" registry:</t>
<dl spacing="compact" newline="false">
<dt>Capability Name:</dt><dd><tt>urn:ietf:params:jmap:webpush-vapid</t
t></dd>
<dt>Intended Use:</dt><dd>common</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Security and Privacy Considerations:</dt><dd>RFC 9749, <xref targe
t="security-considerations"/></dd>
<dt>Reference:</dt><dd>RFC 9749</dd>
</dl>
</section>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references">
<name>References</name>
<references title='References' anchor="sec-combined-references"> <references anchor="sec-normative-references">
<name>Normative References</name>
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.186-4">
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organ
ization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="FIPS" value="186-4"/>
</reference>
<reference anchor="X9.62" >
<front>
<title>Public Key Cryptography for the Financial Services Industry: The Elli
ptic Curve Digital Signature Algorithm (ECDSA)</title>
<author >
<organization>American National Standards Institute</organization>
</author>
<date year="2005" month="November"/>
</front>
<seriesInfo name="ANSI" value="X9.62-2005"/>
</reference>
&RFC8620;
&RFC8030;
&RFC8292;
&RFC2119;
&RFC8174;
&RFC7515;
</references>
<references title='Informative References' anchor="sec-informative-reference <reference anchor="FIPS186" target="https://doi.org/10.6028/NIST.FIPS.18
s"> 6-5">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>NIST</organization>
</author>
<date year="2023" month="February"/>
</front>
<seriesInfo name="NIST FIPS" value="186-5"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</reference>
<reference anchor="PUSH-API" target="https://www.w3.org/TR/push-api/"> <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
<front> <front>
<title>Push API</title> <title>SEC 1: Elliptic Curve Cryptography
<author initials="" surname="Peter Beverloo"> </title>
<organization></organization> <author>
</author> <organization>Standards for Efficient Cryptography Group</organiza
<author initials="" surname="Martin Thomson"> tion>
<organization></organization> </author>
</author> <date year="2009" month="May"/>
<author initials="" surname="Marcos Caceres"> </front>
<organization></organization> <refcontent>Version 2.0</refcontent>
</author> </reference>
<date year="2024" month="September"/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
620.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
292.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
515.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<reference anchor="PUSH-API" target="https://www.w3.org/TR/push-api/">
<front>
<title>Push API</title>
<author initials="P" surname="Beverloo" role="editor">
<organization/>
</author>
<author initials="M" surname="Thomson" role="editor">
<organization/>
</author>
<author initials="M" surname="Caceres" role="editor">
<organization/>
</author>
<date year="2024" month="September"/>
</front>
<refcontent>W3C Working Draft</refcontent>
</reference>
</references>
</references> </references>
</references>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA6VZ0XbbuBF951dMlYe1eyxZVhwn0enpVms7jXYTR43k3e5b
IHIkYgMCLABKq/r4X/ot/bKeGYAUacm77WleIlEkOLhz587FuN/vJ156hWPo
3TsEs4IfJ7PpDUgN33+czOAnXM4ql/eSzKR3oqD7MitWvi/Rr/q/FKLsb3FZ
Vi7vb0Qps/7FsJdkwuMYRsPRq/7won8xTBJhUYxhqj1ajT7Zrse8fOKqZSGd
k0b7XYljmN4u3iWp8GNwPktkacfQ87ZyfjQcvh2OekkiKp8bO06gnwBojuhG
aIkK/lop79I8AcBCSDWGjK//ZR2uDzJMEm1sIbzc4DgBeDedzS/eXNFHgBqF
G7mWXiiYy7UWvrIIcy90JmwGJzfz+WmP726i4H99MHY9ht6d8NJooWCqnZe+
8gxo/bwDoTNYYJpro8x6Byd30/kiLlhDdvGyP3wdAhJ2jX4Mvdz70o3PzzMj
B8auzy+Gg6vh6M05PT2gPQwu3lz1L8M6Dq1EJ/XK1MHRHWPoNff8/e3gatTd
86xaKpnCD7iDa7srvVlbUeY7WBkLPkd4J7XQqSRU0G5kig6mOquct7sxLHKE
W6Vk6WUK15XdIBxiOFFrY6XPCzi5vb6ZT34TxkmBVqZCQ4PnHsIG2S5sw1f9
i4tnAJjczadj6PG++3RrL0no9xYTZvfz9/3JbPoUFpfDZDY9HqvUju5Bjxa+
ww1aZUzvya8fhfVSwyI3hTP6yK+pcXAtUrTouhsaXfaHb4/zYLvdDrYvmQqL
z+dceqKU570kSfr9Poil81akPkkWuXSQmbQqUHvIcCU1OhBQoM9NxtnlGndo
N2gdeAMi26D10iHlXVpIRSmWUkm/418rn6P2MhUea2UAbbxc0SVptIPKSb1m
0vxoVKW9sDuYlKWKNzCB0MI0o3Xqx6C0xpvUqEHYQiGzTGGSvCDFsCarUror
STjah4c/fH53/eZqNHx8BFdiKlcSHeRmC6mSqL0D4o6rli61cokUOG74eghO
NK8DnwsP0kFqilJ4uVQIW+nzZm/xXcOXw8fHAcxNgUB4M2JcBhb/UUmLYSHa
tWjtNeDaQc2BUCqsUaBzYo3/L2R1jKO3I4pxYWAlUsoY5YjCOuOlAzRwYixU
joJa01epm616tIUMwnQKGjFzISTuBmUQiK+4I0F7Zp/eQCmcA+lBKENbMnxr
GzHY5qjBorcSNyEZGreAOiuN1H4AlPRroylfzKd7hxlwCUkHN5HLRG3kaLaG
RKH38X6+6J2F/+HuE3/+fPu3++nn2xv6PH8/+fCh+ZDEO+bvP91/uNl/2j95
/enjx9u7m/Dw3acFdC4lvY+Tn3tnLOe9T7PF9NPd5EOPovSdihOWybdEkNT4
SoseMxAuyTBQk3f23fXs3/+6uIx5HF1cvH18rJN68fry8ZExC28zWu3iV5/j
LhFlicLSKkSrVJQku+4MhAOXm62GHC0OCC2HEatC7EAoZ2D/bDdqqRNltki1
75BWKpWQGm71WkmXh1XOSGXo5qASTVeFAoWWeu0GyZ++VVIj9N98++eEknoj
XWo2aCnp86osjfWsQEywkFAu70ZxqKjN8hdMuUIt+spqhg9KYX3NQ1c356hk
7CXq504cIsyR1QNG9EhbPE4HsbQcuBBQqEPpalmJ/GZWiSwLylGi9TtIhVKY
Qa+yekxWaFwKKwo3Jkc07jiiXl0HR3Y24O65EarCsCHp9q+QZBjqrbDAcCCp
0V5w1hBWRimzpbCbhmb0OEn+2K7PsMkfcDeG3txTAnpJAqFvUy9uV3ejY92i
lUqRbBz0gONKcEakkqS3moTVoqMipvjgRDjosP/hgfvy4yNMtMZfYXLKREed
mgyzqI1L4fDqsrIqXKdLIZGvX128ItW7rqwlOrqd81i4EGuOMOuPXl1Byqbk
4SH6vcfHQZJM9wYA7gz13AXjSdd+Q+NYc4SDNDcONbcW7cjg1B0k9EpuIrTE
0potye1kNoWTh4faZzw+njW8fD0YnZ5R/YZE+qhsQTgyaTH1agepKSWxXxMm
mPEbTOWJljKaJG+Fdg0LBjBpflI7lgRtfA36vmXsA3k5GIVewRnZQ+1kUarQ
ZCkw3qmVjtSZwpEOClMjEJhKckROP8AbQnID7ufOVbQmt5y7tnNIktsN2h14
WYTcRcQdanLOnZ7JPOQ15qHLl7yB+88fqPmEcn1K09mn+YLbNTrfarlNGzWV
J8E6wGcQWo/UqaoydLA0Pic/6vE6F3qNtbcgKCiiH9HulaPjjbg5H8QVQzpr
75l3QBwW8P1PC3ByTYEtdzFiuaGHQy6sRVcazYmKOnOctnEfz3Ca37gMERkd
/QwRvTGEGUTNOSbQUTSa3B2khmvGovCYMQ/oqPHZeBF83U9kCkQdTzQfBiyW
SqTIUhJ8yFfcnTUprsqsBjHqPqcFSrQdnQ8iGw0QP1kYLX082xzrG9SXUs6u
q0Ft3s+J5lUshh1xfEEvO1umTUny3R5TTz0mzUHEdQdJMln5CL6NQHQ5MPmZ
pV7qivlOdRDe0jXcFCv+Kh03r4Mo2u7SqOy59NMiIghIrSYlWmmymjWkTq7x
1yHPZo9AsAFERdKSDR4JZACTQBLaRxTYIy9khyqLAjMpPKoQGgkQkjmJe2Z2
ZoaQgFxsmLKnhxWUofPW7I6hwivUXYKAoQqJRIyPPYNnODIENeCnM+EF0PQC
vjyl/ZeDjErnqlBhKxkPto2QHCT3Se5I3oh8z+TQm/Dwru33zeopkQ9Ks4k/
5rq0pii9a6/iDRTiK8nRwRbP4/Jf6lMlGaNQcUGZgmtgZ0M/BS9RexihYxVn
nRI+g20u0xwsrupz6dMS5TTEZUKsdI5oqpTqCyyJR0riyBulU6FJ08qG0mxl
JsTgukIDggu0BUMuyIeuLLocs7bu1EEtKw9LXHE3FErVyTvAzKGPcEXMnfSV
iEFWDl07uLr2xWF7qbEwdX+06ExlU2Su1IdbbbYgnDOpZKDZmxAUlQ/I70Gj
k5ejfqQ9WYbjPtBiTAAeBhTWhsvhSzh5Z+xSZhnqUzLpvqJTdobhbBJP7YfN
NkmoRyqFGxl0JRByqbDonGODE84x/QpyddgCYqtqGLiypvi9VACfQI+zrcbs
mKsOOBfCp3lInCRBJiGs2/6UI7TIjh4K6fjm7n4mP/OpeBe65HPMeWrqnqxQ
C97ROm8wQGGVJJe+EpLOMMJ7LErPfXmOaWXJwRITZIa2Nmc3lW2707plUXJS
dO4M3E6nuTVa/jP8wErnYIl+i7HaYqSkYZHbfBi10uEA5vWRK7jV+uZCrnNP
ifRWktE41mhrs93hKqWxRXJ2DttcqiPm8iiVa2fT8mvZ/lUatyqiEBaPhVwn
FxSKzB2dgIT6aWe4897aovKr3i8Ws3b1UGX9dgXt7fzlYDRIklmUsDioKrh/
PzkId84ih22U5h+Bm2EhCh+PmN0Y+TEVeQ5dFhTq4nTUQSU3aElZTYsuQRIK
6eWaKptdVOBWh/48IuBq5ykeuYZgvHjIpDOWRhVGTnp3wNZMutRiSVNuDPOT
9nmA3vNN27J+Ay4iVp/a6/HJIIwy2CC45gaEL78/KPjSOvrrvTd9ZiCiZCF9
AKu0ZiOzJ1MAEEs6H+6T+U0z5ghzl/9h1njCLeJ0bxBClJlBPlSCxQ0KRdVE
bm6D7TjOaDoUbpVknMI8N7RrV6uNseFYk+7ASveVZGNnNPVY42g1Us/gQxgS
ymecWwar0SyUdmRrP+I+6fKdjaokqWmo/2Zwxevuv78OuWOrGZJ7etaMS0/a
o+Ewswh99KRdjafcMXaNA2qx5AVMJ3eTA5198QI+41rSCN+36MObuN4P4zuT
s4OBVaxEF17BRp2WpLEv496a6reZdt1mWnjEtmYZ+2ETWcZxkrTiCX8a/G9I
niTzTqw1JOMuQjSh8ajDDAjHNF0o6KgYvfK1ISIphTb+zTBpOheloiZTlw5P
XrGXvavkP85ys2AIHQAA
</rfc> </rfc>
 End of changes. 24 change blocks. 
306 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.48.