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

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jul 2015 11:06:47 -0700

My apologies, version -30 omitted this change.  It's been added to -31.

At 3:49 PM -0700 5/5/15, Randall Gellens wrote:

>  At 10:05 PM +0000 5/1/15, Matt Serra wrote:
>
>>   Our NENA Additional Data WG made an observation that we'd like to 
>> submit for the groups consideration:
>>
>>   We noted section 4.1 describes the usage for the "Data Provider 
>> Information Block" as "SHOULD" and "MAY" provide.
>>
>>   We'd like to propose that the group consider making the usage of 
>> this block "Conditional": MUST be provided if the data-provider 
>> inserts any other block, otherwise MAY be provided.
>>
>>   This would ensure that the provider of all data inserted into the 
>> Call Info header identifies themselves.
>
>  This seems reasonable to me: if an entity adds any blocks, it MUST 
> add a Provider Info block.  If it touches the call in some way but 
> does not add any blocks, it MAY add a Provider Info block (to 
> indicate that it did touch the call, which might be useful for 
> after the fact problem tracking).
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  Americans have an abiding belief in their ability to control reality
>  by purely material means.... airline insurance replaces the fear of
>  death with the comforting prospect of cash.
>             ==Cecil Beaton, It Gives Me Great Pleasure, 1955.
>
>  _______________________________________________
>  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: ---------------
In the '80's my gut feeling was that airlines were crap.  I hated
spending time on planes.  I thought we could create the kind of
airline I'd like.  So we got a secondhand 747 and gave it a go.
    --Richard Branson, founder of Virgin Atlantic. May 2006

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jul 2015 11:13:41 -0700

As a simplification to the mechanism I described in my reply on May 
5th, the categorization of a block as providing information about the 
call, the caller, or the location has been added to the Additional 
Data Blocks registry in the document as a new column.  The text has 
been updated to clarify that, while all blocks defined in the 
document provide data about the call, any new blocks added to the 
registry in the future must be categorized.

Also, I realize that in my previous reply I neglected to address 
Matt's statement that the unique 'purpose' value of each block was 
dropped.  This was not dropped, it remains an integral aspect of the 
mechanism; the unique 'purpose' value is how entities know if they 
are capable of processing a block and if they wish to access the 
block.

The changes described here were accidently omitted from version -30 
but have been added to -31.

At 4:00 PM -0700 5/5/15, Randall Gellens wrote:

>  At 10:21 PM +0000 5/1/15, Matt Serra wrote:
>
>>   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!
>
>  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
>  Progress is made on alternate Fridays.
>

-------------- Randomly selected tag: ---------------
Why is it that we rejoice at a birth and grieve at a funeral?  It is
because we are not the person involved.                 --Mark Twain