Subject: Re: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-05.txt

From: Randall Gellens <[email-masked]>
Date: Wed, 7 Nov 2012 14:57:23 -0800

[[ resending from a subscribed email address ]]

A few comments:

(1) In Section 1, there is confusion over how many types of data 
exist and which are discussed/described/specified here, varying 
between three and four.  I think this stems from an incomplete 
deletion of the category for PSAP data.

(2) The text in Sections 1 and 3 is confusing and, to me, fuzzy on 
"the data structure," the blocks, the categories, the MIME types, and 
how they are used and identified.

Consider the text: 'data is defined as a series of "blocks" that 
represent a class of information' and 'an extensible set of these 
types constitute the data structure' and 'The data structure contains 
an element which itself is a URI that has device or service dependent 
data' -- I think this is confusing and unclear as to what is a block, 
a class, and 'the' data structure, and the role of the URI field 
within these (if there still is such).

My understanding from the discussions previously is that we have a 
set of MIME types, each of which is a data block belonging to one of 
the categories (call, caller, location).  Any set of blocks can be 
included by reference or by value.  For each block that is included 
by value, there is a URL pointing to it in a Call-Info header, with a 
tag indicating which block is being pointed at.  We discussed using a 
sub-part to 'purpose' or other mechanisms to indicate which block is 
being pointed at (e.g., 
'purpose=emergencyCallData.addDataProviderInfo').  The idea is that a 
system can examine the headers and determine if there are any data 
blocks that it is interested in, and if so, locate them.  I'm not 
sure if we discussed if this extends to blocks included by reference; 
the draft says no, but I can see a good case for doing so (e.g., so 
an entity can know if it wants the data before it fetches it).

To make things more clear, I think we need text explaining how to 
send data, for both the HTTPS and CID cases.  We probably also need a 
few more examples showing multiple data blocks, especially some added 
by different entities.

(3) I also think we agreed in email and at the Vancouver meeting to 
indicate in the MIME type that the data is for emergency calls, e.g.,

At 2:21 PM -0700 7/31/12, I wrote:
>    'application/emergencyCall-addDataProviderInfo+xml'
>    'application/emergencyCall-addCallSvcInfo+xml'
>    'application/emergencyCall-addDataDevInfo+xml'
>    'application/emergencyCall-addCallSub+xml'

Or something along these lines.

This applies to the individual sections defining these blocks and 
Section 13.1.3 and Section 13.4.

(4) Section 3 is titled "Call-Info Specification" and so would seem 
to be about the Call-Info header field, but it starts out saying "The 
Additional Data about a Call" and then discussing this class of data. 
Is the intent to be limited to this class, or is the intent to be a 
mechanism for any of the three (or four) classes of data?  I think 
this is another case where the document is really hard to follow.

(5) Sections 4-8 seem to each discuss one of the three (or four) 
classes of data plus the 'comment' field, with subsections for each 
data block.  If so, it would be helpful to say this somewhere, 
perhaps at the end of Section 3, assuming that section is about how 
to use the Call-Info header to point to blocks of those types.  Or, 
what may be far more clear, add a new section between Sections 3 and 
4 that gives a brief overview of each type/class/category of data and 
the MIME types for the blocks within that category.  Then, the 
sections that follow which give details will make more sense, having 
some context.  I think this will make the document flow better and 
easier for the reader to follow (the sections can then be thought of 
as explaining the overall system, then the details of the Call-Info 
header use, then an overview of the different blocks, then the 
details of each block; examples could then be placed after all this).

(6) In 13.1.3, what is the job of the expert reviewer, given that 
Specification Required is the rule?  I think probably only 
Specification Required is needed here.

(7) Minor editorial in Section 1: change "would provide" to "provides"

(8) Typo in Section 1: "services providers" instead of "service providers"

(9) Typo in Section 3: "the CID URL points one" should be "the CID 
URL points to one"

(10) Some of the edits sent in my review in November 2011, resent in 
July 2012, were skipped, and I'm not sure if this was deliberate or 
an oversight.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
#Random Tag

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
#Random Tag

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Rocky's Lemma of Innovation Prevention:

Unless the results are known in advance, funding agencies will
reject the proposal.