-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/6/12 1:52 AM, Gunnar Hellström wrote: > Joe Hildebrand skrev 2012-04-03 09:30: >> On 4/3/12 4:49 AM, "Gunnar >> Hellström"<gunnar.hellst...@omnitor.se> wrote: >> >>> I see a small possibility in XEP-0080. The last element is an >>> URI. That could be used as a pointer to a location by reference >>> in the RFC 4119 format. >>> >>> It seems that RFC 6442 prefers location by reference for the >>> SIP case, so that may be the case for XMPP as well. >> I like this idea. Whether you used the URI element of XEP-80, >> or created a new XEP for a protocol that only had this URI, >> moving the access control and privacy outside XMPP will make this >> easier to specify. >> > Good, then I suggest to use that URI element is proposed to be able > to be used similarly as the locationURI parameter of the > Geolocation header specified for SIP in RFC 6442, section 4.1. > > A first assumption could be that it will be sufficient with a new > version of XEP-0080, that just adds this detail of usage of the > URI element. > > Before it is decided to do it as such a simple change, without > real change of format, a check should be done if all other > required conditions around its usage will be satisfied, compared to > the usage of the locationURI parameter of RFC 6442. > > At a brief glance, I notice: > > 1. RFC 6442 points to a set of specifications that need to be > studied for getting the intended usage. It is e.g. RFC 4119, RFC > 5491, RFC 5985, GML 3.1.1. > > 2. RFC 6442 allows any number of locationURI parameters, > comma-separated. XEP-0080 has just one element for one URI. Is that > a problem for any real case? > > 3. RFC 6442 specifies a response on location conveyance for SIP, > that can be used for indication of errors. It needs to be checked > if a corresponding function is needed in XMPP, and how it is > achieved. > > 4. Both RFC 6442 and XEP-0080 have ways to indicate end of > conveyance of location information. It should be checked if they > map sufficiently to each other. > > 5. There is a risk that a message is sent with a URI pointing to > something else and not intended to be used according to RFC 6442 > locationURI, because URI is an existing element of XEP-0080, and > existing applications may use the element in another way. Does > this cause any risks or conflicts?
Yes, there is existing usage. For example, in XEP-0080 you will see an example of <uri>http://www.esbnyc.com/</uri> for the Empire State Building. I don't know how widely this kind of thing is used, but currently the <uri/> element is not limited to the special kind of location-uri from RFC 6442. > If all these checks come out positive, then it may be possible to > just add to the usage description of the URI element in XEP-0080, > otherwise either a new element is needed, or a new XEP. If we really decide to go down this path, I would recommend only a new element. 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/ iEYEARECAAYFAk+E17QACgkQNL8k5A2w/vxJ+QCeJGOxGADUJ5DZAPhqTTerNthh pZgAn31BFesm6iPMV1v7ZVLRquYT7YS3 =rDXo -----END PGP SIGNATURE-----
