Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 29 Oct 2004 10:36:33 +0200

hi james, nadine, henning, 

henning pointed us to some work in the simple wg. maybe you, nadine, want to
check whether the nena requirements match the currently offered
functionality.

james, i still think that this can be realized with traits (but as henning
said, it might not be necessary). the main question is whether you want to
provide the information by yourself or asserted by someone else. 

ciao
hannes

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: Donnerstag, 28. Oktober 2004 17:53
> To: Tschofenig Hannes; Abbott, Nadine B.; Peterson, Jon
> Cc: [email-masked]
> Subject: RE: [Sipping-emergency] New revision of proposed 
> ECRIT charter
> 
> At 11:20 AM 10/28/2004 +0200, Tschofenig Hannes wrote:
> >hi james,
> >
> >some data items seem to be part of the pidf-lo work.
> 
> each of items below are or are not part of the pidf-lo. No 
> other fields in a SIP message should carry them, therefore 
> this is part of the geopriv wg
> 
> >however, as nadine
> >mentioned there are additional fields:
> >- Customer Name,
> >- Class of Service--Residence, Business, Public, etc.
> >- information about/from a VoIP/Communications Service Provider
> >
> >this information is not included in the pidf-lo.
> >
> >is this use case for saml you are often talking about?
> 
> saml asserts a trait, which none of the above are, each above 
> is individual or personal, not a trait
> 
> 
> >ciao
> >hannes
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[email-masked]]
> > > Sent: Donnerstag, 21. Oktober 2004 17:33
> > > To: Abbott, Nadine B.; Peterson, Jon
> > > Cc: [email-masked]
> > > Subject: RE: [Sipping-emergency] New revision of proposed
> > > ECRIT charter
> > >
> > > Isn't most of this an extension to the PIDF-LO effort in
> > > Geopriv, and not part of ECRIT?
> > >
> > > The portion that I believe is part of SIP/PING would be the
> > > addition of a body part by the VSP (in add the contact info
> > > you want) - which has so far been frowned upon (to say the
> > > least) in these WGs
> > >
> > > At 10:57 AM 10/21/2004 -0400, Abbott, Nadine B. wrote:
> > > >Jon,
> > > >
> > > >In the North American National Emergency Number Association
> > > (NENA) VoIP
> > > >Location WG, we have been grappling with the problem of how
> > > additional
> > > >information relevant to an emergency call might be carried to the
> > > emergency
> > > >call taker.  For example, this might include information 
> about the
> > > caller
> > > >(e.g., Customer Name, Class of Service--Residence, 
> Business, Public,
> > > etc.)
> > > >and information about/from a VoIP/Communications Service Provider
> > > (e.g.,
> > > >contact information for that provider) that are relevant to an
> > > emergency
> > > >call.  We are not yet ready (before this next meeting) 
> to provide a
> > > list of
> > > >proposed requirements.
> > > >However, I wondered if you consider that the charter for 
> ECRIT, as
> > > written,
> > > >covers the issue of how such information--caller supplied and/or
> > > service
> > > >provider supplied--might be carried in SIP?
> > > >
> > > >Respectfully,
> > > >Nadine Abbott
> > > >NENA VoIP Location WG team leader
> > > >
> > > >_______________________________________________
> > > >Sipping-emergency mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/sipping-emergency
> > >
> > >
> > > cheers,
> > > James
> > >
> > >                                 *******************
> > >                  Truth is not to be argued... it is to be 
> presented
> > >
> > >
> > > _______________________________________________
> > > Sipping-emergency mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sipping-emergency
> > >
> 
> 
> cheers,
> James
> 
>                                 *******************
>                  Truth is not to be argued... it is to be presented
> 
> 
> _______________________________________________
> Sipping-emergency mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Oct 2004 08:44:34 -0400

> check whether the nena requirements match the currently offered

To amplify: vCard currently provides the name (and other information), 
but doesn't provide the service provider name and other details. 
However, it would seem trivial to add either to CIPID or vCard, as they 
may well be useful outside the emergency services context. From a data 
type perspective, these pieces of information aren't really location 
information, so stuffing them into PIDF-LO or an extension thereof seems 
a bit of a stretch.

My general inclination is to avoid emergency-only protocol features.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Oct 2004 12:17:30 -0500

What Nadine wants is the name of the organization that provided the 
location to the endpoint. This is not a decoupled action between the CIPID 
and the PIDF-LO, their are in association with each other. Revealing who 
asserts my location information (Fort_worth_VPC.org) reveals fairly 
specifically where I am in most contexts. This is a revelation of location 
information I as a user might not want in my location policy. If you 
mandate it is outside of the rules of PIDF-LO, we must generate a duplicate 
set of privacy and security requirements in this WG

At 08:44 AM 10/29/2004 -0400, Henning Schulzrinne wrote:
>To amplify: vCard currently provides the name (and other information), but 
>doesn't provide the service provider name and other details. However, it 
>would seem trivial to add either to CIPID or vCard, as they may well be 
>useful outside the emergency services context. From a data type 
>perspective, these pieces of information aren't really location 
>information, so stuffing them into PIDF-LO or an extension thereof seems a 
>bit of a stretch.
>

cheers,
James

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Oct 2004 16:05:38 -0400

That makes sense to me. If this is just meta-date for the location, it 
should be closely tied to that data.

James M. Polk wrote:
> location to the endpoint. This is not a decoupled action between the 
> CIPID and the PIDF-LO, their are in association with each other. 
> Revealing who asserts my location information (Fort_worth_VPC.org) 
> reveals fairly specifically where I am in most contexts. This is a 
> revelation of location information I as a user might not want in my 
> location policy. If you mandate it is outside of the rules of PIDF-LO, 
> we must generate a duplicate set of privacy and security requirements in 
> this WG