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?
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.
/Gunnar
