0.11

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3725 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0189.xml

@@ -24,6 +24,12 @@
   &stpeter;
   &dmeyer;
   &ianpaterson;
+  <revision>
+    <version>0.11</version>
+    <date>2009-12-17</date>
+    <initials>psa</initials>
+    <remark><p>Added back example of sending public key in a message; defined presence extension to signal key generation in progress.</p></remark>
+  </revision>
   <revision>
     <version>0.10</version>
     <date>2009-12-15</date>
@@ -323,6 +329,45 @@
   ]]></example>
 </section1>
 
+<section1 topic='Sending a Public Key Directly' anchor='send'>
+  <p>An entity might need to send its public key to another entity, for example if it has generated a new key but does not have a way to publish the new key (or does not wish to publish the key in a world-readable fashion). In this case the entity MAY include the key directly in a &MESSAGE; stanza.</p>
+  <example caption='Sending a key in a message'><![CDATA[
+<message from='peter@jabber.org/foo'
+         to='maineboy@jabber.org/bar'>
+  <pubkey xmlns='urn:xmpp:pubkey:1'>
+    <begin>2009-12-11T20:12:37</begin>
+    <end>2010-12-11T23:59:59</end>
+    <jid>peter@jabber.org</jid>
+    <key>
+      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA25/Y7oonF3+pRjZCk0cQ
+      lQFiUFvyMeUOnn01NLfqfBeT4xjahsxaYFPd+V8jIHtpO3nbkpfrBh5aLPCkqDzS
+      UFvmLaVSIMUt085kcT/Yv72BUWUGaISt7swSNfictRbVZ0k8TbXUDLIAYWN8lsie
+      NVxL13PS9pu3WNoORuKAV5RuzDS3djnjb6fti7fTwEUpQVwRrJXY6jNhv4c4zE3x
+      Pjm48gIlHbZrxuWNrXnKT6uwXnr6PJ6O3YspferJG1oA3kmOwm41yWDkalbKgkNZ
+      WeS+ahB/i9LIG+41CdekPpI0Kr0Ll9X7+zaPV6xzjlG8dYy7ZGm4eTL9STuWlPdL
+      +wIDAQAB
+    </key>
+    <print>13475c8e27399908b4447d7c52ab30822872832eba3a654f0d80e07fb4157673</print>
+  </pubkey>
+</message>
+  ]]></example>
+</section1>
+
+<section1 topic='Signalling Key Generation' anchor='generate'>
+  <p>There are several situations in which it is helpful for an entity to signal that it is currently generating a key. For example, a client that does not have access to permanent storage might generate a key on startup, but key generation might not be complete when the client sends initial presence upon establishing an XMPP session. In this case the client might signal support for the public key format in the entity capabilities data that it includes in its initial presence broadcast, but also include an indication that it is currently generating a key.</p>
+  <example caption='Key generation in progress'><![CDATA[
+<presence from='peter@jabber.org/foo'>
+  <generating xmlns='urn:xmpp:pubkey:1'/>
+</presence>
+  ]]></example>
+  <p>After key generation is complete, the entity could publish the new key to the appropriate PEP node (if available) and signal that key generation is complete so that any interested parties can request the new key.</p>
+  <example caption='Key generation completed'><![CDATA[
+<presence from='peter@jabber.org/foo'>
+  <generated xmlns='urn:xmpp:pubkey:1'/>
+</presence>
+  ]]></example>
+</section1>
+
 <section1 topic='Determining Support' anchor='support'>
   <p>To advertise its support for public keys, revocations, and attestations, when replying to &xep0030; information requests an entity MUST return features for 'urn:xmpp:pubkey:1', 'urn:xmpp:revoke:1', and 'urn:xmpp:attest:1' respectively.</p>
   <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>