>Hi James,
>
> >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.)
Hannes - you are confusing the linkage between
the SIP request/PIDF-LO with the "intended
recipient" comment you made above. How exactly is
the "intended recipient" affected by the entity element?
>If this would be so clear to everyone then Dan
>would have not asked the question on the list.
you are missing Dan's question completely. Dan
asked if - once a SIP INVITE is received at the
police calltaker, would that calltaker be allowed
to forward the caller's location on to a another
organization (such as hospital for ambulance
dispatch, which he gave as a scenario). This has
zero to do with the entity attribute discussion.
>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
to indicate what - that this Location is intended for the police only?
That plays right into what Dan asked.
Linking the PIDF-LO entity attribute to the SIP
request does *nothing* to indicate who is the
intended LR of this PIDF-LO (which is the point
you appear to want explicitly identified).
>but somewhere in the documents someone has to
>say that these fields serve a special purpose in
>the entire privacy policy rule evaluation.
What are "these fields" in the above sentence referring to?
The ones in SIP?
or the ones in the PIDF-LO?
We need to understand what you are wanting before
we go any further with this discussion.
James
> >
> >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
