Subject: Re: [Ecrit] comment field in additional-data

From: Delaine Arnold-ENP <[email-masked]>
Date: Thu, 30 Aug 2012 20:52:50 -0500 (CDT)

Brian,

PIDF-LO has a field with a tag of LOC.  There is also Additional Data Associated with a Location.
These are 2 separate things.

I thought LOC was for the SP to use to populate anything they wanted, while Additional Data Associated with a Location is just what you indicated - floor plans, or any specific details about the location being responded to.

Since SPs/devices create PIDF-LO, why can't these additional comments from the SP be in the LOC data element?

Thank you,
Delaine
---------------------------------------
Delaine M. Arnold
Voice:  813-960-1698
Cell:     813-928-1692
Email:  [email-masked]

Aug 30, 2012 06:19:54 PM, [email-masked] wrote:

===========================================

Please let's not get additional location data confused with this.

The request is for free text from a service provider in the path of an emergency call, or in the case of a PIDF, the author of a PIDF.  

"Additional Location Data" is defined by NENA as information specific to a location (not a PIDF, but the location the PIDF represents).  It has things like floor plans, tenant/building owner contact data, elevator status, ..  It probably could use a comment field, but it's an entirely separate data structure, not defined in this document.

Brian

On Aug 30, 2012, at 5:31 PM, Matt Serra  wrote:

> I'll respond, as I think I'm responsible for the confusion.
> 
> Brian proposes that this new "Comment" field appear ONLY within the Additional-Data Service Provider Block and NOT within the PIDF.  This way, anyone can populate the "Comment" field.  If it were in the PIDF, only access networks could populate the new "Comment" field.
> 
> I think this field should only be used to provide incremental comments about the Service Provider, or the Services Provided, and NOT about the location.  It would be better to carry information about the location in a separate Call-Info header having the Purpose parameter set to 'emergencyLocationData' (at least this is what is documented in the NENA i3 specification).
> 
> Matt.
> 
> 
> -----Original Message-----
> From: Randall Gellens [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2012 2:52 PM
> To: Rosen, Brian; Matt Serra
> Cc: Rosen, Brian; [email-masked] Org
> Subject: Re: [Ecrit] comment field in additional-data
> 
> Would a comment in the service provider block and a comment in the PIDF be directed at different uses? Likely I'm misunderstanding one, the other, or both.  I read Brian's note on adding a comment to the service provider block as a way for a service provider to add free-form information to, for example, the contact info for the service provider ("For non-emergency requests, call the listed administrative number and ask for Marge; if it's an emergency, call the listed mobile number").  A comment in the PIDF-LO would be a way to make a remark regarding the location.
> 
> At 6:30 PM -0400 8/9/12, Brian Rosen wrote:
> 
>> Well, I think we want entities other than an access network to be 
>> able to use a comment, so the latter of your two answers is what I 
>> would say.
>> 
>> If there is a comment in additional-data, I don't think we need 
>> another in PIDF.
>> 
>> Brian
>> 
>> On Aug 9, 2012, at 5:28 PM, Matt Serra  wrote:
>> 
>>> Brian -
>>> 
>>> No objection, but a question:
>>> 
>>> We mentioned possibly putting this field into the PIDF instead. 
>>> Did we arrive on putting this into the Add'l Call Data to keep the 
>>> PIDF "clean" assuming it has no alternate use outside of 9-1-1?
>>> 
>>> I suspect the driver is also based on whether the "Comment" is 
>>> related to the address, or the provider/service as well.
>>> 
>>> Thanks.
>>> 
>>> -----Original Message-----
>>> From: Rosen, Brian [mailto:[email-masked]]
>>> Sent: Thursday, August 09, 2012 11:42 AM
>>> To: [email-masked] Org
>>> Subject: [Ecrit] comment field in additional-data
>>> 
>>> Would there be any objection to adding a field in the service 
>>> provider info block for a comment?
>>> I'm asking because we found a backwards compatibility issue in NENA, 
>>> but I think it's generally useful.  There are always a couple of 
>>> things it may be helpful to tell the call taker (human).
>>> I'd put cautionary text in that suggests using an extension mechanism 
>>> to pass actual data intended to be consumed by an automaton.  This is 
>>> just for free text to be displayed to a call taker or other PSAP 
>>> staff.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: --------------- Boling's postulate:
>    If you're feeling good, don't worry.  You'll get over it.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 31 Aug 2012 10:05:07 +0800

Delaine,

What if I want to include the extra information that Brian is talking about but the location itself is geodetic?

If the information is not specifically location information then it doesn't belong in the civic or geodetic data set.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Delaine Arnold-ENP
Sent: Friday, 31 August 2012 11:53 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] comment field in additional-data

Brian,

Thank you,
Delaine

Brian

On Aug 30, 2012, at 5:31 PM, Matt Serra  wrote:

>>> I'd put cautionary text in that suggests using an extension 
>>> mechanism to pass actual data intended to be consumed by an 
>>> automaton.  This is just for free text to be displayed to a call 
>>> taker or other PSAP staff.
>>> 
>>> 
>>>