Re: [Ecrit] A few issues with RFC7852 (Additional Data)

More generally, the reason the block type MUST be a registered emergency 
call additional data block and the block type is part of the Call-Info 
'purpose' parameter is so an entity can determine using rules if it will 
access the block or not.  This applies regardless of the block is passed 
by reference or by value.  The expectation is that, for example, PSAPs 
will determine the handling of various types of data using a set of 
rules, (not unlike policy routing), e.g., specifying which data elements 
of which blocks are displayed to a call taker on call presentation vs 
available to a call taker by request vs not accessed.

RFC 7852 Section 6 does mention the possibility of having a different 
block type than what the 'purpose' parameter indicated:

     Note that, as with any mechanism, failures are possible.  For
     example, a block (provided by value or by reference) might not be 
the
     type indicated by the 'purpose' parameter, or might be badly 
formed,
     etc.  The general principle that applies to emergency calls is that
     it is more important for the call to go through than for everything
     to be correct.  Thus, most PSAPs will process a call if at all
     possible, even if data is missing or other failures occur.

--Randall

On 4 Dec 2020, at 10:57, Brian Rosen wrote:

> In a discussion in NENA, a few issues were discovered with the 
> Additional Data document.
>
> 1. The purpose parameter contains the type of block. What happens if 
> the actual block type received is not what the purpose parameter says?
> If we do a bis of this document, we might want to state why the block 
> type is part of the purpose parameter: it’s because if the block is 
> passed by reference, you want to know, before you dereference the URL, 
> what kind of block it is.  This error (block type not the same as 
> purpose) isn’t anything we can really do anything about.  But at 
> least we should say something about the possibility and consequences.
>
> 2. How long does the reference work after the Additional Data 
> reference is passed?  In NENA docs we say “a few minutes past the 
> end of the emergency call”.  That’s probably not good enough for 
> Additional Data: it has to be valid for the entire incident the call 
> references.  The calling device/service provider doesn’t know that, 
> so we probably have to have a time based recommendation that is 
> measured in hours.
>
> Brian
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit