Re: [Standards] Nodeprep question
On 11/20/07, Mickaël Rémond <[EMAIL PROTECTED]> wrote: > > I end up wondering why this other types of fractions are often accepted by > nodeprep libraries: > 1/4: 188 > 1/2: 189 > 3/4: 190 > Fraction Slash: 8260 Fraction slash normalizes to itself, and all slashes in given fractions normalize to "Fraction Slash". Since this slash isn't used for separating server and resource parts of a JID it's harmless (in fact it's not so harmless as another source of phishing). > 1/8: 8539 > 3/8: 8540 > 5/8: 8541 > 7/8: 8542 > Division slash: 8725 > > Any pointers are appreciated. All pointers are listed in RFC 3290 reference list. You need to read at least RFC3454. -- Sergei Golovan
Re: [Standards] Nodeprep question
On 11/20/07, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > > > Some libraries extend it to caracters such as c/o (8453). The rational > > behind that is that it contains a fraction. > > I think they do wrong. You forgot about Unicode normalization. -- Sergei Golovan
Re: [Standards] XEP-0115: version 1.5 revisited
...coming back. You cache the name, and add the version. (Optionally, if the name string contains the version string, a'la 'Exodus 0.9.1' and version '0.9.1' you just use the name unmodified.) Hmm. What if you have this? AND... Then do you display the following? Software: Exodus 0.9.1 0.9.1 "If the name string contains the version string..." strcasestr(clientname,version) == 1 Thus, you just use 'Exodus 0.9.1' (the name field) since the version string is a substring of the name. I agree it's not necessarily ideal, but this is how many of us deal with things ANYWAY when sorting out version information. I still think, regardless, if we are adding version into presence, it is silly to kill the old ver field, then put the value into a new v field. If we aren't adding version into presence, that's another thing, but I would expect that users will request this -- showing what version of a client the other person is on has been one of our own most-common requests. I agree there is no solid engineering reason for it, but it is functionality clients presently can have, and removing functionality will always generate end-user bug report/feature request tickets. And sometimes features are driven by 'what users want' rather than by any solid engineering goal. (Is there a real engineering benefit to avatars? No, but users demonstrably wanted them.) Just my $0.02, though. :) -- Rachel Blackman <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0115: version 1.5 revisited
OK, I'm still trying to get to closure here... :) Rachel Blackman wrote: >> A version is only interesting if you know the software that it goes with. >> Unfortunately all we have is a URI, which means for any sane display I >> need a >> table of URI->"software name" mappings, and thus I can only display >> versions >> for software I know about. That seems limiting. > > Not really; you can just cache the identity part of a disco query when > you cache the list of features. Usually the identity contains the > client name, and you are already generally getting that when you do your > disco query. In general, I see things like... > > > > ...coming back. You cache the name, and add the version. (Optionally, > if the name string contains the version string, a'la 'Exodus 0.9.1' and > version '0.9.1' you just use the name unmodified.) Hmm. What if you have this? AND... Then do you display the following? Software: Exodus 0.9.1 0.9.1 [sic] That seems bad. Let's keep the version information in one place. I think it's safest to put it in the disco#info 'name' attribute and nowhere else (that is, if people really want this information -- the more I think about it, the less convinced I am that it is useful or important to provide the version information in caps). This way we don't clog up the caps data with version information, we don't need to add a new 'v' attribute to caps, and we can leave the naming to disco as it (perhaps) should have been all along. > Granted, this becomes an issue if you have two clients with identical > hashes but different names, so Justin's suggestion of an 'n' field in > the caps is not without merit. But users do like this information -- > and it can be useful to know that someone is on the Gmail web client, > rather than Google Talk itself -- so having SOME way to convey it in a > sensible and bandwidth-efficient manner (i.e., avoiding our old-school > iq:version flood) is a good idea. Well, as Justin said, a client can maintain a mapping of node -> name (derived from disco#info results) if it really cares, right? Then if you want to advertise different builds of the same or similar client, you could include different nodes (http://www.google.com/talk/win vs. http://www.google.com/talk/web or whatever). So folks, let's keep things in perspective: 1. What really matters here is the capabilities (in 1.4+, the 'ver' attribute). 2. The node is nice to have for certain use cases because it can give you a mapping to a client name (via disco#info) if you want it. 3. The version information may be desirable in certain odd situations, but I have not heard a compelling argument for it (most people want to show the software name but are not all that interested in the exact version). If you really really need the version, use XEP-0092 (but for Pete's sake don't flood every person in your roster for the damn version because no one really cares about it!). Therefore I argue for removing version from caps (i.e., not adding it back in version 1.5 -- we already removed it from 1.4). An updated copy (1.5pre8) of XEP-0115 is here: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html The SVN diffs are here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1403 Do we have consensus? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] [Fwd: [Council] meeting agenda, 2007-11-21]
FYI Original Message Date: Mon, 19 Nov 2007 17:04:28 -0700 From: Peter Saint-Andre <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Council] meeting agenda, 2007-11-21 The next meeting of the XMPP Council will be held on Wednesday, November 21, at 19:00 UTC. A proposed agenda is here: http://www.xmpp.org/council/agendas/2007-11-21.html Agenda bashing is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0168 (Resource Application Priority)
Version 0.6 of XEP-0168 (Resource Application Priority) has been released. Abstract: This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than messaging. Changelog: Documented optional pubsub transport for RAP data. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0168.xml?r1=1384&r2=1398 URL: http://www.xmpp.org/extensions/xep-0168.html
[Standards] XEP-0045 v. 1.23pre3
I'm trying to clean up a number of specs for which we have "interim" versions hanging around in SVN. Another such spec is XEP-0045 (Multi-User Chat). The version in SVN is 1.23pre3. The changelog since 1.22 is: *** Added optional outsider role, including outsider use cases and admin management of outsider role; defined getmemberlist room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full; defined service discovery extension field for associated LDAP group; specified that room config fields can be listed in extended room information; specified message format for affiliation change notifications if user is not in the room. *** A rendered copy is here: http://www.xmpp.org/extensions/tmp/xep-0045-1.23.html The SVN diff since 1.22 is here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0045.xml?r1=741&r2=1396 Basically this incorporates all feedback received since April, other than the "direct invitations" use case, which I'll work to add in 1.24. /psa
Re: [Standards] XEP-0155: text
Peter Saint-Andre wrote: > In working on a mapping [1] of XMPP chat sessions to the Message Session > Relay Protocol [2], I discovered that the use of a element in > XEP-0155 is problematic: > > http://www.xmpp.org/extensions/xep-0155.html > > This usage is disallowed when initiating a session negotiation but > allowed when rejecting a session request, completing the negotiation, or > cancelling the negotiation. Consider Example 3 in the current spec: > > Example 3. Contact declines offer and specifies reason > > from='[EMAIL PROTECTED]/balcony' > to='[EMAIL PROTECTED]/orchard'> > ffd7076498744578d10edabfe7f4a866 > > > > urn:xmpp:ssn > > 0 > > > Sorry, can't chat now! How about tonight? > > > For one thing, I think this violates the message stanza profiles we have > started to define in XEP-0226: > > http://www.xmpp.org/extensions/xep-0226.html > > This makes client-side processing more complex (does the client show the > as a normal message?). It also complicates handling of such a > message by a SIP gateway. > > I think it would be much better to define a data form field called > "reason" and to include the text there: > > Example 3'. Contact declines offer and specifies reason > > from='[EMAIL PROTECTED]/balcony' > to='[EMAIL PROTECTED]/orchard'> > ffd7076498744578d10edabfe7f4a866 > > > > urn:xmpp:ssn > > 0 > > > Sorry, can't chat now! How about tonight? > > > > > OK I've checked these changes into SVN: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0155.xml?r1=863&r2=1394 The rendered version is here: http://www.xmpp.org/extensions/tmp/xep-0155-1.2.html Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Nodeprep question
Dnia 19-11-2007, Pn o godzinie 22:27 +0100, Mickaël Rémond pisze: > Nodeprep adds forbidden characters to usual stringprep tables. Among > those characters we find "/" (47). IIUC the only reason that slash '/' character is forbidden in a node part is, that it is a resource delimiter. So encountering '/' in the JID means that the resource has just started. > Some libraries extend it to caracters such as c/o (8453). The rational > behind that is that it contains a fraction. I think they do wrong. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
[Standards] Nodeprep question
Hello,
I am trying to find the rules (or the logic) behing nodeprep
processing as done by many libraries.
Nodeprep adds forbidden characters to usual stringprep tables. Among
those characters we find "/" (47).
Some libraries extend it to caracters such as c/o (8453). The rational
behind that is that it contains a fraction.
Is there somewhere a complete list of such unicode characters that are
implicitely forbidden by the following section of the Nodeprep RFC:
"In addition, the following Unicode characters are also prohibited:
#x22 (")
#x26 (&)
#x27 (')
#x2F (/)
#x3A (:)
#x3C (<)
#x3E (>)
#x40 (@)
"
I end up wondering why this other types of fractions are often
accepted by nodeprep libraries:
1/4: 188
1/2: 189
3/4: 190
Fraction Slash: 8260
1/8: 8539
3/8: 8540
5/8: 8541
7/8: 8542
Division slash: 8725
Any pointers are appreciated.
Cheers :)
--
Mickaël Rémond
http://www.process-one.net/
[Standards] XEP-0100 v. 1.1pre3
Today I updated XEP-0100 (Gateway Interaction) to address some feedback that Ian Paterson provided back in August: http://mail.jabber.org/pipermail/standards/2007-August/016441.html The diff and updated version are here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?r1=1156&r2=1390 http://www.xmpp.org/extensions/tmp/xep-0100-1.1.html This will be on the agenda for the next Council meeting: http://www.xmpp.org/council/agendas/2007-11-21.html Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
