[Standards] 301 feedback
markybox at gmail.com
Tue Jul 2 19:54:27 UTC 2013
Some proposed changes to address Kevin's concerns:
1. Remove phrase "For implementation simplicity" from section 4.7
There are very good reasons (already written) why bare JID is simpler,
but maybe you are right: That it is not appropriate to mention
anything about whether or not it is simpler to implement. However, I
do observe people may still ask questions about whether it is simpler
Change: "For implementation simplicity, recipient clients MAY track
incoming <rtt/> elements per bare JID <localpart at domain.tld> to keep
only one real-time message per sender."
Into: "Recipient clients MAY track incoming <rtt/> elements per bare
JID <localpart at domain.tld> to keep only one real-time message per
2. Create a new normative section in XEP-0301 modelled after section
5.1 and 5.5 of XEP-0085 to cover concerns. This could be a new
section 6 "Business Rules" similiar to a very small subset of XEP-0085
"Business Rules" section. Though I seem to faintly recall that Peter
said this wasn't needed; but I need to dig this mailing list archives.
This would preserve existing behaviour and agreements (and
consistency with combining XEP-0301 / XEP-0085 in all situations
XEP-0085 can be used), but re-add normatives that Kevin said should be
there. This would essentially remove a paragraph from section 6.2.1
and move it to a brand new section betweeen "5. Determining Support"
and "6. Implementation Notes", and also add a very small bit of MUC
information similiar to section 5.5 of XEP-0085.
On Tue, Jul 2, 2013 at 2:45 PM, Gunnar Hellstrom
<gunnar.hellstrom at omnitor.se> wrote:
> On 2013-07-02 20:28, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On 7/2/13 11:46 AM, Mark Rejhon wrote:
>>> On Tue, Jul 2, 2013 at 12:23 PM, Kevin Smith <kevin at kismith.co.uk
>>> <mailto:kevin at kismith.co.uk>> wrote:
>>> 4.2.2 - I'm aware than we've had debates in the past about how
>>> much needs to be MTI. As things currently stand, the XEP is fairly
>>> clear and straightforward, and I wonder if making all of these MTI
>>> would be
>> MTI = "Mandatory to Implement"
>> I don't want to put words in his mouth, but I think Kev might be
>> wondering why guidelines that seem implementation-specific are
>> mandated in the specification, since it could be argued that they are
>> not critical from a protocol perspective and relate more to user
>> experience than to network communication.
> I have another set of words to put in Kev's mouth.
> I think Kev meant that all shall be required to support.
> In a straightforward protocol, having options just increases risks for malfunctions and interop problems.
> On recipient side it might be a good idea, but mandating support on sender side does not make sense.
> Some specific applications simply do not need to send all these.
> I hope Kev can explain now which interpretation was right.
>> - -- Peter Saint-Andre
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> -----END PGP SIGNATURE-----
More information about the Standards