[Standards] 301 feedback

Mark Rejhon markybox at gmail.com
Tue Jul 2 19:54:27 UTC 2013


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 <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
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
<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?
>>
>> 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-----
>
>



More information about the Standards mailing list