Re: [Standards] roster views
On Mar 2, 2009, at 10:00 AM, Mickael Remond wrote: Tory Patnoe wrote: Rather than redefining roster, a well-defined PEP node might be better and simpler as an address book. The "address-book" node would hold a single address per node item. My understanding is that we are talking about roster not address book in this case - the main difference being that roster plays a role on presence whereas the address book is more a place holder for contact pieces of information. Implementations could always treat this PEP node as special, and treat changes to it as having side-effects to presence access control list similar to modifying your roster today.
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mar 2, 2009, at 3:15 PM, Peter Saint-Andre wrote: Uhm.. is that meaningful? Usually for location queries external references are more useful than your address (e.g. your MAC moves with your notebook, so what is the purpose of doing a query with it?) I meant your locally-assigned IPv4 or IPv6 address, not your MAC address. My bad. Actually, I meant the local ethernet (MAC) address of your active network connection(s). There are network elements that keep track of the ethernet addresses they have seen, and can glean location information from that connectivity information. Imagine that your switch's ARP map was query-able, and you knew where each switch port was punched down in a given office. Also imagine a network of wireless access points that can triangulate on you, given your ethernet address. I had a couple of other suggestions for -255, as well: 1) Need a "discovering support" section. I might want to find a location service using disco#items/disco#info, as implied by "run as a component on the same or a different machine from the XMPP server itself". 2) For components outside your core XMPP service, it would be nice to direct a presence to them first, so that they get notified when you go offline. 3) Some location services may be able to publish your XEP-80 location to PEP on your behalf. If so, they should return an empty result:
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
>>> It seems that we'd need this because your ethernet address might be >>> different from your wifi address even in the same location (e.g., where >>> I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi >>> address is 00:23:6c:88:d4:1d). >>> >> >> Uhm.. is that meaningful? Usually for location queries external >> references are more useful than your address (e.g. your MAC moves with >> your notebook, so what is the purpose of doing a query with it?) > > I meant your locally-assigned IPv4 or IPv6 address, not your MAC > address. My bad. I think the intent was to pass in WiFi beacons (or MAC addresses of visible access points) rather than the assigned IP. That said, HELD (part of the IETF GeoPriv effort) attempts to provide mechanisms to determine location from IP: http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-12 seth
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre wrote: > > I meant your locally-assigned IPv4 or IPv6 address, not your MAC > address. My bad. Penitenziagite! :D Yep, now I get the point and it makes sense >> Besides that there is one more reference we are starting using: RFID >> addresses, which allow to pinpoint the exact position of the device. The only problem is that there are few different id schemes (e.g EPC, 96bits; iso 15693, 64 bits and other proprietary). Somewhere there urn schemes allowing the mapping between the different standards, but a solution like this should be general enough: rfid idscheme:id (need to do some more research for confirming) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
Fabio Forno wrote: > On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre wrote: >> I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that > > [...] >> It seems that we'd need this because your ethernet address might be >> different from your wifi address even in the same location (e.g., where >> I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi >> address is 00:23:6c:88:d4:1d). >> > > Uhm.. is that meaningful? Usually for location queries external > references are more useful than your address (e.g. your MAC moves with > your notebook, so what is the purpose of doing a query with it?) I meant your locally-assigned IPv4 or IPv6 address, not your MAC address. My bad. > Besides that there is one more reference we are starting using: RFID > addresses, which allow to pinpoint the exact position of the device. Yes, that too would be useful. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre wrote: > I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that [...] > It seems that we'd need this because your ethernet address might be > different from your wifi address even in the same location (e.g., where > I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi > address is 00:23:6c:88:d4:1d). > Uhm.. is that meaningful? Usually for location queries external references are more useful than your address (e.g. your MAC moves with your notebook, so what is the purpose of doing a query with it?) Besides that there is one more reference we are starting using: RFID addresses, which allow to pinpoint the exact position of the device. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mar 02, 2009, at 20:23, Peter Saint-Andre wrote: I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that it would be good to add a reference type for an Ethernet address, such as: It seems that we'd need this because your ethernet address might be different from your wifi address even in the same location (e.g., where I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi address is 00:23:6c:88:d4:1d). My MacPro has two Ethernet ports built-in, bringing the total number of MAC addresses to 3. Some servers might have even more. andy
[Standards] XEP-0255 (Location Query): ethernet reference type?
I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that it would be good to add a reference type for an Ethernet address, such as: 00.31.55.f9.1d.de ethernet It seems that we'd need this because your ethernet address might be different from your wifi address even in the same location (e.g., where I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi address is 00:23:6c:88:d4:1d). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] roster views
Hello Tory, Tory Patnoe wrote: > Rather than redefining roster, a well-defined PEP node might be better > and simpler as an address book. The "address-book" node would hold a > single address per node item. My understanding is that we are talking about roster not address book in this case - the main difference being that roster plays a role on presence whereas the address book is more a place holder for contact pieces of information. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] roster views
On Sat, 2009-02-28 at 14:46 +0100, Fabio Forno wrote: > On Sat, Feb 28, 2009 at 10:59 AM, Waqas Hussain wrote: > > Partial roster activation is a much much more attractive feature for > > me than partial roster retrieval. I would probably never consider > > using partial roster retrieval for my jabber account. > > Partial retrieval will become useful by using the roster as general > purpose address book, as we discussed in Brussels. In that case it > becomes essential to be able to query it or do partial retrievals. > During the meeting we made also made additional use cases: each roster > item could have additional data (vcards, certificates, ...) and that > information should be retrieved only upon specific requests, not > everytime you get the roster. In other words if we want to extend the > roster we need some mechanism for filtering retrieval in two > dimensions: > - filtering the contacts that are retrieved > - filtering the additional information sent with each contact Rather than redefining roster, a well-defined PEP node might be better and simpler as an address book. The "address-book" node would hold a single address per node item. I do see limitations to using PEP as an address book though. To prevent all clients from querying all items at startup, they should cache the results and then query for any changes since their last known state. I don't see a way in PEP/PubSub to do that kind of retrieval though. Also I would be nice for a address-book type feature if PEP/PubSub allowed queries based on the content of an item. Say all users in group XYZ. Tory -- Tory Patnoe Sr. Software Developer Cisco/Webex/Jabber xmpp: tpat...@corp.jabber.com
