Merge branches 'feature/xep-0156' and 'feature/xep-0157' into premerge

xep-0156.xml

@@ -25,6 +25,12 @@
   &hildjj;
   &stpeter;
   &lance;
+  <revision>
+    <version>1.3.0</version>
+    <date>2020-06-23</date>
+    <initials>fs</initials>
+    <remark><p>Fix reference to RFC 6415 and organize requirements more clearly. This raises the JSON requirement from MAY (OPTIONAL) to SHOULD (effectively), to accustom web-based software.</p></remark>
+  </revision>
   <revision>
     <version>1.2.0</version>
     <date>2019-02-20</date>
@@ -200,6 +206,7 @@ _xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
   <section2 topic='Business Rules' anchor='httpbizrules'>
     <p>The following business rules apply:</p>
     <ol start='1'>
+      <li>Services implementing this XEP MUST offer the information in the Extensible Resource Descriptor (XRD) format and SHOULD additionally provide the JRD format (both formats are specified in &rfc6415;).</li>
       <li>HTTP queries for host-meta information MUST be used only as a fallback after the methods specified in <cite>RFC 6120</cite> have been exhausted.</li>
       <li>A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in <cite>RFC 6120</cite>.</li>
       <li>The order of XMPP related link entries in the host-meta file SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.</li>
@@ -208,7 +215,6 @@ _xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
 
   <section2 topic='Examples' anchor='httpexamples'>
     <p>The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in <cite>XEP-0124</cite> and <cite>XEP-0206</cite> and the second indicates support for the XMPP Over WebSocket connection method defined in &rfc7395;.</p>
-    <p>As specified in <cite>RFC 6120</cite> &sect;3, support for the XML encoding of the host-meta resource is REQUIRED while alternative representations such as JSON are OPTIONAL.</p>
     <example caption='Result for /.well-known/host-meta'><![CDATA[<?xml version='1.0' encoding='utf-8'?>
 <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
   ...
@@ -219,7 +225,7 @@ _xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
   ...
 </XRD>
 ]]></example>
-    <p>It is possible to use an alternative JSON format for host-meta information, in which case the above example would be presented as:</p>
+    <p>It is possible to use additionally a JSON-based format for host-meta information. The JSON representation of the host metadata is named JRD and specified in Appendix A of &rfc6415;. The above XRD example would be presented in JRD as:</p>
     <example caption='Result for /.well-known/host-meta.json'><![CDATA[{
   ...
   "links": [

xep-0157.xml

@@ -28,6 +28,12 @@
     <email>jajcus@jajcus.net</email>
     <jid>jajcus@jabber.bnet.pl</jid>
   </author>
+  <revision>
+    <version>1.1.0</version>
+    <date>2020-05-25</date>
+    <initials>mb, fs</initials>
+    <remark><p>Add 'status-addresses' value in registrar, with example.</p></remark>
+  </revision>
   <revision>
     <version>1.0.1</version>
     <date>2018-07-21</date>
@@ -99,6 +105,12 @@
   <p>The administrators of an XMPP service may desire to advertise contact information related to that service.
     <note>Many existing Jabber/XMPP server implementations use the bare domain &DOMAINBARE; of the server (e.g., "example.org") as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name is delivered to the JIDs of the server administrators. (Currently, this functionality does not apply to &IQ; or &PRESENCE; stanzas.) Unfortunately, using the "domain.tld" address as a way to direct messages to the server administrators may result in overloading of the bare domain address (i.e., it may be desirable to send messages to the server's address without having those messages delivered to the server admins, for example if the server doubles as a &xep0060; service). Therefore, it is instead RECOMMENDED to support service discovery of contact addresses as specified herein.</note>
   This contact information may include email addresses, web URLs, and JabberIDs for specific roles and functions such as the service administrators, abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains SHOULD support the electronic mailboxes required by <cite>RFC 2142</cite>. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
+
+  <p>Values of 'status-addresses' form field MUST be valid URIs, i.e. comply with the 
+  'xs:anyURI' datatype of &w3xmlschema2;. Values of the 'abuse-addresses', 
+  'admin-addresses', 'feedback-addresses', 'sales-addresses',
+  'security-addresses' and 'support-addresses' SHOULD be valid URIs.</p>
+
   <p>To illustrate this usage, consider the following example of a disco#info request sent to the mythical shakespeare.lit XMPP server:</p>
   <example caption='Entity queries server for information'><![CDATA[
 <iq from='juliet@capulet.com/chamber'
@@ -139,6 +151,9 @@
       <field var='security-addresses'>
         <value>xmpp:security@shakespeare.lit</value>
       </field>
+      <field var='status-addresses'>
+        <value>https://status.shakespeare.lit</value>
+      </field>
       <field var='support-addresses'>
         <value>http://shakespeare.lit/support.php</value>
         <value>xmpp:support@shakespeare.lit</value>
@@ -192,6 +207,11 @@
       var='security-addresses'
       type='list-multi'
       label='One or more addresses for communication related to security concerns'/>
+  <field
+      var='status-addresses'
+      type='list-multi'
+      label='One or more addresses for service status'>
+  </field>
   <field
       var='support-addresses'
       type='list-multi'