moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0157: Remove <validate/>, instead state the requirement in text

Browse Source 
Remove <validate/> from the registrar submission and instead state the
requirement that 'status-addresses' form field values must be of type
xs:anyURI in the text.
This commit is contained in:
Florian Schmaus 2020-06-15 18:30:36 +02:00
parent 51acaae1d2
commit b0077840f2
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
xep-0157.xml
View File

@ -105,6 +105,12 @@
<p>The administrators of an XMPP service may desire to advertise contact information related to that service. <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> <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> 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> <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[ <example caption='Entity queries server for information'><![CDATA[
<iq from='juliet@capulet.com/chamber' <iq from='juliet@capulet.com/chamber'
@ -205,10 +211,6 @@
var='status-addresses' var='status-addresses'
type='list-multi' type='list-multi'
label='One or more addresses for service status'> label='One or more addresses for service status'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:anyURI'>
<basic/>
</validate>
</field> </field>
<field <field
var='support-addresses' var='support-addresses'