Hello, 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 or not.
Change: "For implementation simplicity, recipient clients MAY track incoming <rtt/> elements per bare JID <[email protected]> to keep only one real-time message per sender." Into: "Recipient clients MAY track incoming <rtt/> elements per bare JID <[email protected]> to keep only one real-time message per sender." 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. Thanks Mark Rejhon On Tue, Jul 2, 2013 at 2:45 PM, Gunnar Hellstrom <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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? >> >> 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. > > Gunnar > >> >> Peter >> >> - -- Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJR0xu9AAoJEOoGpJErxa2pFloQAIQzQ83vaDov7lyhn33dWkmx >> G60I+YsndpRBY87j0zdOSoRxK4TiUea5+JtAeptuo97gTlL4NqM78qtmUf9PDvGj >> hCL8VQ4Odsy7iBw1vd2rwTgBeCWRK+VES+d+0QZ2+EOyT+schQv+YITaDbKsEoNf >> zUHWOILRaOrUIc9OJ6prIoQBmKw8WqKBDn8PmKmGBlnWrMBr6kpGMICSCheBrnlN >> rL0OpY4kZDMtXySsqYbSK9kAAD1RdmOMtpRNme5Mh/gSlbiBUllFhDu1oZ7tPElO >> Os5vj6kSvhAjg4nkgERDN/XnYUb8uZTC0avTD4LrEAB/iaguidwhJJ6MdE4rdvhF >> gOAzTMDiGCWG6GiOrxnzouVfoAv0uTmhiV2ZkKGbl9ADtFC3fpUPWeTCnGU1tFVr >> BBHMdNNnkmU/O9Iyus03MLmtlJ0YReD59vInQxhcJdhLb4Vmo2f52pUaLQbOfbZO >> c5Zu8W+uPtNm7Go/uELpEgvgZOIToBqMacvK1Wym4XRAoDKBdtqiwYxcr6JXRqf/ >> V58L4CQ1qXH7I4JvQlZh4A4tgtMqJ6d0KmA0TrDuDb8x0v/83CXHz0SbQfYxWDV2 >> VZOBlo6hG6gMf9paQtHSMU1MgYRyJjL9r/THdb7NMp8xSVkVV9skybHDI6918yNg >> 9yEaJC5Y5H6Sp9lAY16E >> =5xTv >> -----END PGP SIGNATURE----- > >
