Re: [Standards] Adding countrycode to XEP-0080: User Location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason wrote: > For my current useage this spec is too limiting to physical locations. > parts of related specs allow for location types that are not > representable by "country/gps etc", things like URLs, or TIME. (you can > be conceptually @ a web location, time, or some other unknown, perhaps > virtual representation of location), it would be nice if this spec were > flexible enough to accomodate such notions. > Can you possibly explain in more detail what your current usage is? I personally think there is merrit in having this namespace/XEP specifically bound to physical location. For websites your currently browsing there is User Browsing and there is also XEP 0202 for getting an entities time (although I don't know how that fits in the context of locations). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqUjH8ACgkQ0JXcdjR+9YQZ6QCfXr9W7zW+j69zGn8G/ScoxXG1 bzUAoMzpcUwQ0c0Zb4eSucI1HjSZMplb =zKiM -END PGP SIGNATURE-
Re: [Standards] Adding countrycode to XEP-0080: User Location
On Wed, 2009-08-26 at 09:55 +0900, Jason wrote: > For my current useage this spec is too limiting to physical locations. > parts of related specs allow for location types that are not > representable by "country/gps etc", things like URLs, or TIME. (you > can be conceptually @ a web location, time, or some other unknown, > perhaps virtual representation of location), it would be nice if this > spec were flexible enough to accomodate such notions. You should probably re-read the spec: all the fields are optional. You can also provide a time, a uri and you have text and description fields at your disposition if the other ones are too restrictive. I understand that this was strictly designed with Earth locations in mind though. :) Pierre-Luc signature.asc Description: This is a digitally signed message part
Re: [Standards] Adding countrycode to XEP-0080: User Location
For my current useage this spec is too limiting to physical locations. parts of related specs allow for location types that are not representable by "country/gps etc", things like URLs, or TIME. (you can be conceptually @ a web location, time, or some other unknown, perhaps virtual representation of location), it would be nice if this spec were flexible enough to accomodate such notions.
Re: [Standards] Adding countrycode to XEP-0080: User Location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/09 10:08 AM, Pierre-Luc Beaudoin wrote: > I'd like to suggest the addition of a "countrycode" child element to > XEP-0080: User Location. This element would convey a xs:string > representing the ISO 3166 two letter country code of the user's > location. That makes eminent sense. It's surprising to me that we haven't added it before! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqUFXgACgkQNL8k5A2w/vxnNACgqzLaenrazQykWPx2jHH34nUe JjYAoKWyqCIm7DVhbFnSW5xlwqxR/KbE =Bn13 -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0227 (Portable Import/Export Format for XMPP-IM Servers)
On Aug 25, 2009, at 3:40 AM, Tobias Markmann wrote:
On Tue, Aug 25, 2009 at 8:18 AM, Kevin Smith
wrote:
> 4. Do you have any security concerns related to this specification?
Only in as much as it's a great big file with everyone's passwords in.
Sure there are little servers supporting it and there doesn't seem
to be huge demand for it but maybe one should add support for other
encodings for the password. Currently it seems you have to use
plaintext there.
Because otherwise you have little mechanism agility. That is, no
ability to support mechanisms which have different mechanism specific
hashes from those you chosen to store.
For example one could also allow storage of the password via two
values(one for UTF8 and one for ISO 8859-1) of
H( { username-value, ":", realm-value, ":", passwd } ) as it is used
in Digest-MD5 mechanism.
It would be nice if XEP 227 provided a format for indicating that a
password is hashed by a particular algorithm.
However, I don't think we should require importing servers to support
any particular algorithm other than cleartext. If a server exports a
Digest-MD5 hash but the importer only accepts plain text, it's up to
the admin to resolve the problem (by resetting passwords of all users,
or by convincing the developers of the importing server to add new
features, or whatever).
That is, if you want exchange interoperability, export passwords as
plain text.
Similar method should be possible for future SCRAM mechanism.
And for SRP and ..., but each will likely be different.
-- Kurt
Re: [Standards] LAST CALL: XEP-0227 (Portable Import/Export Format for XMPP-IM Servers)
On Tue, Aug 25, 2009 at 8:18 AM, Kevin Smith wrote:
> > 4. Do you have any security concerns related to this specification?
>
> Only in as much as it's a great big file with everyone's passwords in.
Sure there are little servers supporting it and there doesn't seem to be
huge demand for it but maybe one should add support for other encodings for
the password. Currently it seems you have to use plaintext there.
For example one could also allow storage of the password via two values(one
for UTF8 and one for ISO 8859-1) of
H( { username-value, ":", realm-value, ":", passwd } ) as it is used in
Digest-MD5 mechanism.
Similar method should be possible for future SCRAM mechanism.
Tobias
[Standards] XEP 0254 suggestions
Title: Signatur After looking at PubSub queuing for our system, we have desided that this is almost what we need. I have a few suggestions to be discussed before we do an implementation and I will try and move this to Draft or even Final soon. 1) Priority queue. As an added namespaced attribute to (described in XEP-0060) a priority would be set, and in case there are already unhandled (not yet locked) items in the queue, this item is added in a priority queue manner. This gives the following questions. What are priorities? I suggest a list of 5 from "Highest, High, Default, Low, Lowest". What happens if a priority is not set? I suggest, based on the above that a Default is chosen if none is set. Should starvation prevention be implemented? Implementation specific. Should timeout be different based on priority? Implementation specific. 2) Handler & Monitor subscriptions. As an extension of the current proposition, I would like to add "Monitor" subscriptions, that work in the same way, "normal" PubSub (XEP-0060) works, each monitor subscriber gets a normal notification, the component does NOT lock the item to any monitor. So, for each item that is published, any number of monitors are notified, one handler is notified and item is locked to this handler. Since items in a PubSub queue is deleted "quickly" by the handler, Payload must be sent along with notifications, for all monitors to be able to get it without This gives the following questions. How to distinguish monitor and handler? Via subscription options when subscription is done. Should monitor subscriptions be kept when client is offline? Possibly set via subscription options. 3) I suggest renaming subscription option "pubsub#queue_requests" to "pubsub#max_concurrent_locks" as I belive this describes the purpose better. 4) An ad-hoc command should be added for the component to get a readout of the current queue size (number of items on a named queue at this very moment, locked an not yet locked) this could be implementation specific as well, but s std. could be deviced. -- Med venlig hilsen / Best regards Mads Randstoft mads randstoft java developer wireless factory aps galionsvej 52 dk-1437 københavn k mobile: +45 31 31 96 07 office: +45 70 20 12 92 fax: + 45 32 95 83 02 m...@wirelessfactory.com www.wirelessfactory.dk
Re: [Standards] XEP-0215 and STUN/TURN
Evgeniy Khramtsov wrote: Hello. I'm thinking of XEP-0215 implementation. In fact, the XEP is very simple to implement (at least on server), but that leads to configuration overkill. I imagine a system administrator maintaining a server with N nodes in a cluster and H virtual hosts. He wants to configure a stun, stuns, turn and turns server in external discovery. In that case he need to create N*3*H*3*H records in the configuration file: a stun and turn takes 3 sections per virtual host (udp, tcp and tls) each and requires to configure it on every node. If N=2 and H=2 (a cluster of 2 nodes and 2 virtual hosts) he needs to create 72 records! Of course a server software may provide a technique to reduce the overhead, but that may cause a configuration file complexity. Personally, I'm interesting in a short-term credentials allocation for a TURN server. I think DNS is the right place to discover stun/turn services since corresponding specifications provide SRV records for that. I think we can move the secret allocation part in a separate request. Example: Or something like that. What do you think? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
