>At 01:22 AM 9/18/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Hi James,
>>
>> >At 11:28 AM 9/17/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> >
>> >>This is the technical side and I am sure there are folks who would
>> >>disagree with my view since this intented recipient story
>never got
>> >>well document in the SIP location conveyance document (see
>>
>>>http://tools.ietf.org/html/draft-ietf-sipcore-location-convey
>ance-01).
>> >
>> >Hannes
>> >
>> >Please remind me what this "intented recipient"
>> >story is that Conveyance has failed to capture.
>>
>>I noted that in my mail to Dan. Still, I believe there are aspects in
>>the entire retransmission-allowed story unanswered (and Martin raised
>>those as well).
>>
>> >I'm drawing a blank on this point at the moment, and working on -02
>> >at the now.
>>You should have responded to the comments a long, long time
>ago already
>>(given that folks are waiting for the document).
>
>SIP has a Request-URI value, a To: and a Route:
>header value. Leaving aside the idea that intermediary servers
>are valid Location Recipients, if none of these SIP values
>identify the intended (destination) recipient, then who/what
>is the SIP message (carrying location) intended for?
BUT none of the specifications say that there is a relationship between these fields and the location object. (If I recall it correctly then Keith or John had some questions about the entity element in the PIDF-LO as well.)
If this would be so clear to everyone then Dan would have not asked the question on the list.
See also the comment Martin has raised about the relationship between the basic policy and the extended policy rules.
>
>The PIDF-LO has no element or attribute indicating the
>intended recipient - therefore, saying a doc fails to expand
>on, explain or describe something it perhaps should isn't a
>good reason for not answering my query now - in a different WG..
I am insisting to have a separate field but somewhere in the documents someone has to say that these fields serve a special purpose in the entire privacy policy rule evaluation.
>
>You remind me of a girlfriend saying "if you don't know what
>you did wrong, then I'm not going to tell you now!" geez...
>
>That attitude only guarantees you will never get what you want
>in the doc, which is sad - given that it isn't an RFC yet.
>
>For the record, in SIP:
>- Alice can tell Bob her location;
>- Alice can tell any intermediary between her and Bob her location;
>- Alice can deny any intermediary between her and Bob from
>learning her location;
>- Alice can even tell Bob about Carol's location, if Alice
>knows Carol's location *and* Carol's retransmission-allowed
>was set to yes when Alice received it.
>
>Each of the above scenarios are independent of the PIDF-LO or
>location URI conveyance choice.
>
>What SIP *cannot* do is have Alice instruct Bob to tell Carol
>about Alice's location -- with or without Alice's
>retransmission-allowed set to yes or no.
These examples are the reasons why some of the policy is in practice difficult to understand since we always talk about "Alice" and "Bob" and not about Request-URI value,
a To: and a Route: header value and the scenarios that are important to us.
To come back to Dan's example: Am I allowed (only from a technical point of view) to forward a call that arrived at a police.example.com to fire.example.com when the call was targeted at urn:service.sos? What about the case where the call was sent to urn:service.sos.police? What about the case where the call was targeted to urn:service.sos.police but that service does not exist and only urn:service.sos is available? What happens if the end host uses LoST and determines that it has to send the emergency call to esrp.example.com but then the call gets send to a bridge inside the ESINet where police.example.com and fire.example.com is connected to?
Instead of always talking about "MUST adhere to the privacy policy" it might be useful to indicate to the reader what that actually means.
Ciao
Hannes
>
>James
>
>
>>Ciao
>>Hannes
>>
>>
>> >Thanks
>> >
>> >James
>> >
>> >
>> >>Ciao
>> >>Hannes
>> >>
>> >>PS: Please note that there are differences between location and
>> >>caller-id information as well (from a technical and legal point of
>> >>view).
>> >>
>> >> >-----Original Message-----
>> >> >From: geopriv-bounces@ietf.org
>> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Dan Mongrain
>> >> >Sent: 17 September, 2009 19:01
>> >> >To: GEOPRIV
>> >> >Subject: [Geopriv] Question regarding
><retransmission-allowed> and
>> >> >calltransfers
>> >> >
>> >> >I have just read RFC 5606 regarding using
><retransmission-allowed>
>> >> >and have a question when used in an emergency calling situation.
>> >> >
>> >> >An emergency call is made and the PSAP answering the call
>> >is operated
>> >> >by the police department. It is determined that police,
>fire and
>> >> >ambulance are required to be dispatched. The fire
>> >department and the
>> >> >ambulance company can be deemed as separate parties from the
>> >> >police department (the ambulance company can be a
>private company).
>> >> >
>> >> >1. If the <retransmission-allowed> flag is set to no, is
>> >> >forwarding the PIDF-LO onto both fire and ambulance a breach of
>> >> >the use of the flag?
>> >> >2. The RFC implies that the LR must respect the flag only
>> >if it has a
>> >> >legal obligation to do so. Can it be assume that
>because a caller
>> >> >has no reasonable expectation to privacy when making an
>emergency
>> >> >call (at least in North America) then forwarding of the
>PIDF-LO is
>> >> >allowed?
>> >> >
>> >> >Thanx,
>> >> >
>> >> >Dan Mongrain, ing.
>> >> >Ingénieur système
>> >> >Systems Engineer
>> >> >
>> >> >dmongrain@plantcml.com
>> >> >
>> >> >75 boul. de la Technologie
>> >> >Gatineau, QC J8Z 3G4
>> >> >OFFICE 819.778.2053
>> >> >DIRECT 819.776.7906
>> >> >FAX 819.772.8905
>> >> >MOBILE 819.712.0491
>> >> >www.plantcml.com
>> >> >
>> >> >_______________________________________________
>> >> >Geopriv mailing list
>> >> >Geopriv@ietf.org
>> >> >https://www.ietf.org/mailman/listinfo/geopriv
>> >> >
>> >>_______________________________________________
>> >>Geopriv mailing list
>> >>Geopriv@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/geopriv
>> >
>> >
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
