RE: [Geopriv] Re: I-DACTION:draft-ietf-sip-location-conveyance-05.txt
"James M. Polk" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
At 06:54 PM 10/22/2006 -0500, Thomson, Martin wrote:
>Content-Type: text/plain;
> charset="utf-8"
>Content-class: urn:content-classes:message
>
>The extra PIDF-LO tag is the only feature of the draft that I have a
>problem with.
Martin
I'm not sure I understand which extra tag you are referring to
> This seems like a case where the letter of the law is taken over the
> spirit of the law.
>
>I agree with Jeroen in that a SIP proxy should not have to change its
>behaviour. What would be more sensible is to acknowledge that a SIP
>message with an unencrypted body can be seen by all proxies.
I think this is obvious by this in the draft
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation Rr ar o - - o o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation Rr ar o o o o o o -
Table 1: Summary of the Geolocation Header
where it clearly states the proxy can read the message body.
>By including a PIDF-LO in this way, you _implicitly_ give proxies
>permission to forward it. You don't need special tags for that. That
>covers the large number of proxies that don't care, that haven't been
>upgraded, or that will not be upgraded.
>
>I also don't like the idea that this updates RFC 4119 without saying it.
My co-author snuck in a RFC4119 update in -04, which was removed in
-05. Can you tell me where else you think this ID officially (or how you
read if should be officially) updates 4119?
Currently, I think -05 of this doc only updates RFC3326 with a new Reason
protocol.
There has been mention of taking the Location Error Code Registry ID and
incorporating it into this Conveyance ID, which will add to this update of
3326.
>~
>Martin
>
>* My understanding is that the "routing-query-allowed" tag only applies to
>by-value; a by-reference URI can be forwarded without concerns**.
>
>** There are now cases where this may no longer be true... FFS.
>
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:[email protected]]
> > Sent: Friday, 20 October 2006 4:38 PM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-
> > 05.txt
> >
> > "The entities receiving location MUST obey the privacy and security rules
> > in
> > the PIDF-LO as described in RFC4119, regarding retransmission and
> > retention."
> >
> > Does this mean that a SIP proxy receiving a request with a Geolocation
> > must
> > first inspect the location object before forwarding? For
> > location-by-reference, this may introduce an unacceptable delay,
> > especially
> > when the proxy does not do anything with the location information itself.
> >
> > Proxies that don't understand Geolocation will forward as usual, possibly
> > violating the forwarding policy. You may want to spend some words on this.
> > For proxies that do understand, you could consider inserting a flag in a
> > SIP
> > Geolocation header for the by-reference case, such that a dereference is
> > not
> > needed to obtain the policy
> >
> > Regards,
> > Jeroen
> >
> > [email protected] wrote:
> > >> A New Internet-Draft is available from the on-line Internet-Drafts
> > >> directories.
> > >> This draft is a work item of the Session Initiation Protocol Working
> > >> Group of the IETF.
> > >>
> > >> Title : Session Initiation Protocol Location Conveyance
> > >> Author(s) : J. Polk, B. Rosen
> > >> Filename : draft-ietf-sip-location-conveyance-05.txt
> > >> Pages : 26
> > >> Date : 2006-10-19
> > >>
> > >> This document defines an extension to the Session Initiation
> > >> Protocol (SIP) to convey geographic location information from one
> > >> SIP entity to another SIP entity. The extension covers end to end
> > >> conveyance as well as location-based routing, where proxy servers
> > >> make routing decisions based on the location of the UAC.
> > >>
> > >> A URL for this Internet-Draft is:
> > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-
> > 05.txt
> > >>
> > >> To remove yourself from the I-D Announcement list, send a message to
> > >> [email protected] with the word unsubscribe in the body
> > >> of
> > >> the message.
> > >> You can also visit
> > >> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >> to change your subscription settings.
> > >>
> > >> Internet-Drafts are also available by anonymous FTP. Login with the
> > >> username "anonymous" and a password of your e-mail address. After
> > >> logging in, type "cd internet-drafts" and then
> > >> "get draft-ietf-sip-location-conveyance-05.txt".
> > >>
> > >> A list of Internet-Drafts directories can be found in
> > >> http://www.ietf.org/shadow.html
> > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >> Internet-Drafts can also be obtained by e-mail.
> > >>
> > >> Send a message to:
> > >> [email protected].
> > >> In the body type:
> > >> "FILE /internet-drafts/draft-ietf-sip-location-conveyance-05.txt".
> > >>
> > >> NOTE: The mail server at ietf.org can return the document in
> > >> MIME-encoded form by using the "mpack" utility. To use this
> > >> feature, insert the command "ENCODING mime" before the "FILE"
> > >> command. To decode the response(s), you will need "munpack" or
> > >> a MIME-compliant mail reader. Different MIME-compliant mail readers
> > >> exhibit different behavior, especially when dealing with
> > >> "multipart" MIME messages (i.e. documents which have been split
> > >> up into multiple messages), so check your local documentation on
> > >> how to manipulate these messages.
> > >>
> > >> Below is the data which will enable a MIME compliant mail reader
> > >> implementation to automatically retrieve the ASCII version of the
> > >> Internet-Draft.
> > >>
> > >
> > >
> > >
> > >> _______________________________________________
> > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol
> > >> Use [email protected] for questions on current sip
> > >> Use [email protected] for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.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.
>------------------------------------------------------------------------------------------------
>[mf_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip