>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-conveyance-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?
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..
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.
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
