Subject: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry

From: Matt Serra <[email-masked]>
Date: Fri, 10 Jul 2015 20:58:43 +0000

Randall & WG:

The NENA Add'l Data WG reviewed some of the recent changes (through v32) this past Monday.

We have two  comments (and a NIT) on the recently added Emergency Call Data Types Registry (section 10.1.9)

1.  To support future growth, we suggest the "Data About" field support multiple values per token.  As defined here, only one value per token is allowed.  This does not support cases where a Token could be used to communicate more than one form of data, but less than "All" forms of data.  Here is the current text. Proposed changes _from_ this:

" The value MUST be _either_ "The Call", "The Caller", "The Location", or  "All".  New values are created by extending this registry in a subsequent RFC."

_To_ this:

" The value MUST be _one or more of_ "The Call", "The Caller", "The Location".  New values are created by extending this registry in a subsequent RFC."

2. Our group was a confused by what affect the values in this registry have on the XML, noting the text describing "Data About" can be interpreted to imply Data About is passed in the XML so it can be inspected by the PSAP:  "Indicates if the data describes the call, the caller, or  the location (or is applicable to all), which helps PSAPs and other entities determine if they wish to process the block."

Additionally, please consider changing the _following text_ for clarity:

"Note that the _values_ from this registry are part of the 'EmergencyCallData' compound value; when used as a value of the 'purpose' parameter of the Call-Info header, the _values_ listed in  this registry are prefixed by 'EmergencyCallData.' per _the the_  'EmergencyCallData' registration"

To this:

"Note that the _tokens_ from this registry are part of the 'EmergencyCallData' compound value; when used as a value of the 'purpose' parameter of the Call-Info header, the _tokens_ listed in  this registry are prefixed by 'EmergencyCallData.' per _the_  'EmergencyCallData' registration"

Finally, a NIT: you will see the last phrase if the above passage repeats the word "the"

Regards,

Matt.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 19 Jul 2015 03:23:32 -0700

At 8:58 PM +0000 7/10/15, Matt Serra wrote:

>  We have two  comments (and a NIT) on the recently added Emergency 
> Call Data Types Registry (section 10.1.9)
>
>  1.  To support future growth, we suggest the "Data About" field 
> support multiple values per token.  As defined here, only one value 
> per token is allowed.  This does not support cases where a Token 
> could be used to communicate more than one form of data, but less 
> than "All" forms of data.  Here is the current text. Proposed 
> changes _from_ this:
>
>  " The value MUST be _either_ "The Call", "The Caller", "The 
> Location", or  "All".  New values are created by extending this 
> registry in a subsequent RFC."
>
>  _To_ this:
>
>  " The value MUST be _one or more of_ "The Call", "The Caller", "The 
> Location".  New values are created by extending this registry in a 
> subsequent RFC."

This field is merely a hint to help guide PSAPs or other entities in 
deciding if they wish to access a block or not; they need to consider 
the block's contents, not just this field.  This is why the field 
only exists in the registry, and is not contained within the block. 
So, I'm not sure that's it's helpful to try and make this field too 
precise.

I changed the "All" to "Multiple" to indicate that the block can be 
considered as applying to more than one category, and I added 
clarifying text that explains that this is merely a hint and not 
contained in the block.  Does this seem OK?

>
>  2. Our group was a confused by what affect the values in this 
> registry have on the XML, noting the text describing "Data About" 
> can be interpreted to imply Data About is passed in the XML so it 
> can be inspected by the PSAP:  "Indicates if the data describes the 
> call, the caller, or  the location (or is applicable to all), which 
> helps PSAPs and other entities determine if they wish to process 
> the block."
>
>  "Note that the _values_ from this registry are part of the 
> 'EmergencyCallData' compound value; when used as a value of the 
> 'purpose' parameter of the Call-Info header, the _values_ listed in 
> this registry are prefixed by 'EmergencyCallData.' per _the the_ 
> 'EmergencyCallData' registration"
>
>  To this:
>
>  "Note that the _tokens_ from this registry are part of the 
> 'EmergencyCallData' compound value; when used as a value of the 
> 'purpose' parameter of the Call-Info header, the _tokens_ listed in 
> this registry are prefixed by 'EmergencyCallData.' per _the_ 
> 'EmergencyCallData' registration"

OK

>  Finally, a NIT: you will see the last phrase if the above passage 

Thanks.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Politics is the art of making the inevitable appear to be a
matter of wise human choice.                 --Quentin Crisp

---

From: Matt Serra <[email-masked]>
Date: Mon, 20 Jul 2015 17:33:56 +0000

Randall:

I do think "multiple" is a step in the right direction, and given the scope of the current document, will work.  If we to this registry in a way that injects more ambiguity, I think we should revisit allowing for more than one value in the "Data About" field, even if just comma delimited.

Thanks for accepting in the other comments in this email, plus the comment about the "Data Provider String" usage sent under separate cover.  Can I assume we'll see those edits in a version '33'?

Regards,

Matt.

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Sunday, July 19, 2015 6:24 AM
To: Matt Serra; [email-masked]
Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry

At 8:58 PM +0000 7/10/15, Matt Serra wrote:

> per token is allowed.  This does not support cases where a Token could 
> be used to communicate more than one form of data, but less than "All" 
> forms of data.  Here is the current text. Proposed changes _from_ 
> this:
>

This field is merely a hint to help guide PSAPs or other entities in deciding if they wish to access a block or not; they need to consider the block's contents, not just this field.  This is why the field only exists in the registry, and is not contained within the block. 
So, I'm not sure that's it's helpful to try and make this field too precise.

I changed the "All" to "Multiple" to indicate that the block can be considered as applying to more than one category, and I added clarifying text that explains that this is merely a hint and not contained in the block.  Does this seem OK?

> can be interpreted to imply Data About is passed in the XML so it can 
> be inspected by the PSAP:  "Indicates if the data describes the call, 
> the caller, or  the location (or is applicable to all), which helps 
> PSAPs and other entities determine if they wish to process the block."
>

OK

Thanks.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Politics is the art of making the inevitable appear to be a
matter of wise human choice.                 --Quentin Crisp

---

From: Randall Gellens <[email-masked]>
Date: Mon, 20 Jul 2015 13:12:35 -0700

Hi Matt,

I'm submitting -33 now, it should appear within the hour.  It has these edits.

At 5:33 PM +0000 7/20/15, Matt Serra wrote:

>  Randall:
>
>  I do think "multiple" is a step in the right direction, and given 
> the scope of the current document, will work.  If we to this 
> registry in a way that injects more ambiguity, I think we should 
> revisit allowing for more than one value in the "Data About" field, 
> even if just comma delimited.
>
>  Thanks for accepting in the other comments in this email, plus the 
> comment about the "Data Provider String" usage sent under separate 
> cover.  Can I assume we'll see those edits in a version '33'?
>
>  Regards,
>
>  Matt.
>
>  Subject: Re: [Ecrit] Comments on 
> draft-ietf-ecrit-additional-data-32 / "Data About" registry
>
>  This field is merely a hint to help guide PSAPs or other entities 
> in deciding if they wish to access a block or not; they need to 
> consider the block's contents, not just this field.  This is why 
> the field only exists in the registry, and is not contained within 
> the block.
>  -------------- Randomly selected tag: --------------- Politics is 
> the art of making the inevitable appear to be a
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-------------- Randomly selected tag: ---------------
Einstein never accepted quantum mechanics because of this element
of chance and uncertainty. He said, "God does not play dice."
It seems that Einstein was doubly wrong. The quantum effects
of black holes suggests that not only does God play dice, He
sometimes throws them where they cannot be seen.  --Steven Hawking