Ian Paterson wrote: > Peter Saint-Andre wrote: >> I've made a first pass at updating XEP-0115 (Entity Capabilities) in >> line with recent list discussion: >> > > This looks like a good first pass. > > - In section 1.2 "How it Works": > > 1. If Benvolio is publishing caps with a different 'node' but the same > 'ver' then I don't need to perform another disco#info. So can you make > that clear from the outset by giving Benvolio a different node attribute > to Romeo in the example? > > > - When generating the ver attribute (section 5): > > 1. It would be more secure to include a delimiter character between the > various parts of the string E. The delimiter should be a '<' character > since it may not appear in an XML attribute value.
No objections here. How about also formatting the category and type information as "category" "/" "type" since that is how we usually show them (e.g., "client/pc")? > 2. The big-endian array of bytes output by the hash function should be > converted directly to a base64 string, since converting it to a > hexadecimal string first only serves to double the length of the ver > attribute. Done. > - Discovering Capabilities (Section 6.2) > > Why should the client "pick a random JID from that list"? It shouldn't. Leftover text from the previous version. Removed. > Why is the disco#info query sent to a node of "node#ver" (see section > 1.2 too). Why should "the capabilities supported by the base > installation of the application without plugins or other add-ons" be > returned, and not the capabilities that the client currently offers > (i.e. those that correspond to the hash value)? More leftover text. Removed. > Insert a point saying that clients SHOULD (MUST?) calculate the hash of > the returned identity and features to confirm that they correspond to > value of the 'ver' attribute (to prevent caps cache poisoning). Done. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
