[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

Kevin Smith kevin at kismith.co.uk
Tue Jul 2 20:28:58 UTC 2013

On Tue, Jul 2, 2013 at 9:03 PM, Mark Rejhon <markybox at gmail.com> wrote:
> On Wed, Jul 25, 2012 at 6:21 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
>>>> 6.2.1 - I suspect this should be more prominent than buried inside
>>>> Implementation Notes
>>> [Comment & Question]
>>> I'm glad you think this section is important enough to be part of the
>>> Protocol.  Activation Methods is quite an important inclusion in the
>>> specification, even though some people may disagree (Gunnar prefers real
>>> time text to be activated at all times, for example -- and technically I
>>> agree -- but realistcally, implementers want to choose their own activation
>>> mechanisms).
>>> Perhaps I could split it into a "5.1. Business Rules" section (ala XEP-0085)
>>> but I'm not sure that this is appropriate.
>>> Alternatively, I can add it as a "6. Business Rules" (bumping Implementation
>>> Notes as a section 7)
>>> Peter, David, et cetra from XSF, any comments?
>> I checked some other XEPs and decided it's probably fine where it is.
> Kevin,
> This is the answer you wrote on Wed, Jul 25, 2012 --
> That's why it's still sitting in section 6.2.1 today.
> Is there new information today that makes it higher priority today to
> remove it from 6.2.1 now,
> and create an XEP-0085 style "Business Rules" section (similiar to its
> 5.1 and 5.5 sections)?

The point I was making wasn't concerned so much where it was (although
it seems I was torn about this a year ago, as well :)), but that it
needs to be normative - opinions differ on whether that means things
need to be in different bits of the XEP. I think just using 2119
language is probably fine.

My concern is making sure that implementing 311 doesn't give clients
carte blanche to be bad XMPP citizens by spamming people with many
stanzas they don't support, and for that I think the 'only send init
and then stop unless they confirm (or advertise support)' bit needs to
be normative. :)


More information about the Standards mailing list