Subject: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt)

From: Matt Serra <[email-masked]>
Date: Fri, 1 May 2015 22:21:46 +0000

Another recommendation coming out of the NENA Additional Data WG:

I raised this a few weeks ago, and I realize I may not have been clear enough the first time around.  After speaking with Randall Gellens this evening, he recommended I resubmit this suggestion for re-consideration by this work group:

The Additional Data Draft, as written, describes mechanisms to carry additional information about the call itself.

The mechanisms defined in this additional-data document are targeted for expansion.  This is alluded to in section 1, where it recognizes the existence of data that can be associated with a Caller and Location in addition to the Call.

Since it is likely that additional data blocks will be added to address Caller and Location, and that Caller and Location data may reuse some of the data-blocks identified for Call Data (minimally Provider Information and Comments) an additional field, named something like "Information About", with an initial registry value of "Call" may be warranted.  This could be expanded to include "Location", "Caller", etc. as Data Structures are added to the Emergency Call Data Types registry (10.1.10) to support other forms of data.

Potentially this new field could be located in the Provider Info block, although Randy suggested it is probably best in each of the other blocks defined in this draft standard.  This would allow any system processing the Call Info headers to readily determine what "kind" of data is being conveyed.

At one time, forms of Additional Data were to be distinguished with a unique Purpose Parameter, but that was abandoned somewhere during the development of i3 or this IETF spec - likely for good reason.  If valid, that would be another approach.

I hope I'm being more clear this time around!

Regards,

Matt.

[rave_email_signature]

  Matthew A. Serra, ENP
  Sr. Director, Product Management
  Mobile:  201.245.1557
  [email-masked]<mailto:[email-masked]>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 5 May 2015 16:00:04 -0700

At 10:21 PM +0000 5/1/15, Matt Serra wrote:

>  I raised this a few weeks ago, and I realize I may not have been 
> clear enough the first time around.  After speaking with Randall 
> Gellens this evening, he recommended I resubmit this suggestion for 
> re-consideration by this work group:
>
>  The Additional Data Draft, as written, describes mechanisms to 
> carry additional information about the call itself.
>
>  The mechanisms defined in this additional-data document are 
> targeted for expansion.  This is alluded to in section 1, where it 
> recognizes the existence of data that can be associated with a 
> Caller and Location in addition to the Call.
>
>  Since it is likely that additional data blocks will be added to 
> address Caller and Location, and that Caller and Location data may 
> reuse some of the data-blocks identified for Call Data (minimally 
> Provider Information and Comments) an additional field, named 
> something like "Information About", with an initial registry value 
> of "Call" may be warranted.  This could be expanded to include 
> "Location", "Caller", etc. as Data Structures are added to the 
> Emergency Call Data Types registry (10.1.10) to support other forms 
> of data.
>
>  Potentially this new field could be located in the Provider Info 
> block, although Randy suggested it is probably best in each of the 
> other blocks defined in this draft standard.  This would allow any 
> system processing the Call Info headers to readily determine what 
> "kind" of data is being conveyed.
>
>  At one time, forms of Additional Data were to be distinguished with 
> a unique Purpose Parameter, but that was abandoned somewhere during 
> the development of i3 or this IETF spec - likely for good reason. 
> If valid, that would be another approach.
>

I'd like to suggest that this additional information exist in the 
registration information for each block, but not in the block itself.

Currently, the registration/description of each block carries the 
following items of information (referred to as labels):

    Data Element: A unique human-readable concise name for the block
    Use:  Required, Conditional, or Optional
    XML Element:  a unique XML element name
    Description:  Human-readable description of the block
    Reason for Need:  Human-readable explanation of why the block is needed
    How Used by Call Taker:  Human-readable explanation of how block is used

I'm suggesting that we add one additional item to this list: Information About.

This would not change the contents of the blocks (and hence nor their 
XML schema), it only changes the description of the blocks.  However, 
this should make it easier for entities to establish policy as to 
which blocks they will access and which they won't.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Progress is made on alternate Fridays.