Re: [Standards] XEP-0115 1.4pre2
Dave Cridland wrote: > On Wed Jul 11 15:59:39 2007, Peter Saint-Andre wrote: >> http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html > > This looks good. > > For maximum pedantry, you might note that the base64 encoding used MUST > NOT contain whitespace (which RFC 4648 says is the default anyway) and > MUST set padding bits to 0 (which RFC 4648 says applications MAY require). Done: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1039&r2=1059 /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0004: Data Forms - Open Issues
On 12 Jul 2007, at 16:37, Peter Saint-Andre wrote: Tobias Markmann wrote: I just noticed that it doesn't define whether duplicates are allowed in jid-multi or not either. What's the point of duplicates? IMHO the jid-multi field SHOULD NOT include duplicates and duplicates MUST be ignored. That was my opinion too, but might it be worth making that explicit? (I couldn't find mention when I looked). /K
Re: [Standards] XEP-0004: Data Forms - Open Issues
Peter Saint-Andre wrote: > Tobias Markmann wrote: >> I just noticed that it doesn't define whether duplicates are allowed in >> jid-multi or not either. > > What's the point of duplicates? IMHO the jid-multi field SHOULD NOT > include duplicates and duplicates MUST be ignored. http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0004.xml?r1=1053&r2=1058 /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0004: Data Forms - Open Issues
Tobias Markmann wrote: > I just noticed that it doesn't define whether duplicates are allowed in > jid-multi or not either. What's the point of duplicates? IMHO the jid-multi field SHOULD NOT include duplicates and duplicates MUST be ignored. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0004: Data Forms - Open Issues
I just noticed that it doesn't define whether duplicates are allowed in jid-multi or not either. On 7/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Peter Saint-Andre wrote: > http://www.xmpp.org/extensions/tmp/xep-0004-2.9.html > > http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0004.xml?r1=851&r2=1031 We had a discussion [1] about ordering of items in the jdev room today so I've made an adjustment [2] to clarify that as well. /psa [1] http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-07-10.html#12:26:19 [2] http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0004.xml?r1=1031&r2=1033
Re: [Standards] XEP-0115 1.4pre2
Dave Cridland wrote: For maximum pedantry, you might note that the base64 encoding used MUST NOT contain whitespace (which RFC 4648 says is the default anyway) and MUST set padding bits to 0 (which RFC 4648 says applications MAY require). These requirements mean that the resultant base64 from any given input has precisely one form, and so can be used for direct comparison. Yes, this is important to specify. - Ian
Re: [Standards] XEP-0115 1.4pre2
On Wed Jul 11 15:59:39 2007, Peter Saint-Andre wrote: http://www.xmpp.org/extensions/tmp/xep-0115-1.4.html This looks good. For maximum pedantry, you might note that the base64 encoding used MUST NOT contain whitespace (which RFC 4648 says is the default anyway) and MUST set padding bits to 0 (which RFC 4648 says applications MAY require). These requirements mean that the resultant base64 from any given input has precisely one form, and so can be used for direct comparison. Implementations MAY choose to decode the base64 and compare hashes directly (and if you mandate this, then you can skip the para above). Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
