>Thanks Hannes,
>
>responseTime is a bit of a concern.
>
>At a minimum, responseTime is a separate item from
>locationType. That will simplify your description a little.
Since there is no top level XML element I could only define it as a separate
XML element. That's fine but I believe it does not change a lot.
>More seriously: I'm not entirely sure how to interpret
>responseTime in the context of a SIP PA. This might work as
>you have described, but I would suggest that it complicates
>things considerably. There's discussion on this point in my
>draft here:
>
><http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
>val-req-02#section-4.6.1.1>
>
>I don't know how to solve this problem yet.
>
I am not sure I see the problems.
Imagine a SIP proxy receives a SIP message with an LbyR and wants to
retrieve location information for routing. Depending on the URI scheme (HTTP
vs. SIP) he would either use
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-03.txt
Or
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-04.txt
For
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-03.txt he
could use the 'responseTime' attribute set to "emergencyRouting".
When a 'responseTime' attribute is used with
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-04.txt
then hopefully the semantic would be the same. Instead of returning location
information that is good for dispatch location information usable for
routing would be returned.
Ciao
Hannes
>--Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Hannes Tschofenig
>> Sent: Wednesday, 15 July 2009 6:25 PM
>> To: geopriv@ietf.org
>> Subject: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-
>> 05.txt
>>
>> Hi all,
>>
>> Here is another update to
>draft-ietf-geopriv-loc-filters-05.txt based
>> on the feedback from Martin. The changes are:
>>
>> * added the <locationType> element (including the 'exact' and
>> 'responseTime'
>> attribute). I re-used the text from the HELD specification and
>> modified as appropriately.
>> * fixed the civic prefix in the example (again)
>> * modified the schema to pick up the suggestion regarding
>the <moved>
>> and the <enterOrExit> element.
>>
>> The new document is here:
>> http://www.tschofenig.priv.at/svn/Filters/draft-ietf-geopriv-loc-
>> filters-05.
>> txt
>>
>> Ciao
>> Hannes
>>
>> PS: When including the text about <locationType> element two issues
>> that might need to get discussed, namely the ability to
>carry multiple
>> PIDF- Los (or to include multiple representations of the location in
>> the same
>> PIDF-LO)
>> in a NOTIFY and the need to define some error messages
>(e.g., to tell
>> the Notifier that the requested locationType is actually not
>> available).
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>---------------------------------------------------------------
>---------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original. Any unauthorized use of
>this email is prohibited.
>---------------------------------------------------------------
>---------------------------------
>[mf2]
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
