Subject: [Geopriv] Comments on HELD-05

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 17 Mar 2008 09:28:58 -0500

Hi Mary,

Here are my remaining comments on the HELD-05 specification excluding
the one that we resolved in the meeting.

Section 6.1
There are a number of lower case "should"s in this section that are
really dictating how the LIS needs to behave when it receives a certain
value in the responseTime parameter. I think that these need to be
capitalized so the the behaviour of the LIS, and hence the real meaning
of these values, is more strongly dictated. Otherwise I fear
interoperability issues will arise.

Section 6.2
Civic:  The last sentence for this is a little confusing, and I think is
an artefact the old postal and jurisdictional civic stuff. I am not sure
that it adds anything anymore and should be deleted.

Also this section doesn't say that the LIS should provide location in
the response in the same order in which they were requested. It would be
nice if it did say that again. That is, if I request civic and geodetic
in that order, my resulting location response has the locations in that
order.

Section 6.6
Wow this is wordy! I think most of that first sentence (which is huge),
could be simplified by saying something like:
"The presence object is included in the locationResponse message when
the LIS is returning location by value". The presence object is a
PIDF-LO and is constructed in accordance with the rules in PIDF-LO
profile."

I think that that says the same as what is there now.. ;)

Section 9
The last sentence at the bottom of page 19 should say "HELD
locationResponse and error messages". Since HELD errors are returned in
an HTTP 200 OK

Section 10.2
Third paragraph, nit, "that location given only _to_ authorized
clients".

Bullet points. One of the key things that we found when implementing the
open source LIS was that the LIS needed to be aware of identifier (IP
address) re-allocation. In particular if I have a location URI that
pointed to your IP address, but you dropped of the network, and that IP
address was now allocated to me, the LIS needs to know that the URI that
you had is now invalid because it points to me instead of you. I don't
quite get that use case out of the bullets as currently written, and I
think it is a different use case than what is actually being described.

Section 11.1
The example on page 25 needs to have a <method> element added.

And that is it!
Well done! 

Cheers
James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 24 Mar 2008 14:54:06 -0500

James,

Thanks for reviewing the document. My responses are embedded below [MB].

Mary. 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, March 17, 2008 9:29 AM
To: GEOPRIV; Barnes, Mary (RICH2:AR00)
Subject: Comments on HELD-05

Hi Mary,

Section 6.1
There are a number of lower case "should"s in this section that are
really dictating how the LIS needs to behave when it receives a certain
value in the responseTime parameter. I think that these need to be
capitalized so the the behaviour of the LIS, and hence the real meaning
of these values, is more strongly dictated. Otherwise I fear
interoperability issues will arise.
[MB] There are 4 lower case "should"s in that section. Two of the lower
case "shoulds" are about the accuracy of the LI returned by the LIS. We
discussed that we cannot dictate accuracy from a protocol perspective,
thus those "should"s were actually changed from UC to LC in the -04 (per
IETF-69 discussion and subsequent mailing list discussion). There is
another lower case "should" that states something like  for the purpose
of emergencyDispatch the LI reflects the location to which "responders
should be dispatched.". In this case, also, I can't see that behavior as
being enforceable for the protocol. That one has always been lower case.
The 4th is about the time values associated with the purposes of
emergencyRouting and emergencyDispatch being configurable on the LIS.
Again, we can't mandate LIS configuration nor how a LIS might use those
purposes. The ECRIT WG documents would be the appropriate place for any
upper case SHOULDs (if at all) for these last two cases IMHO. [/MB]

Section 6.2
[MB] Agreed. [/MB]

Also this section doesn't say that the LIS should provide location in
the response in the same order in which they were requested. It would be
nice if it did say that again. That is, if I request civic and geodetic
in that order, my resulting location response has the locations in that
order.
[MB] Okay. I'll add the following sentence to the end of the paragraph
following the list of locationTypes:
"The LIS SHOULD provide the locations in the response in the same order
in which they were included in the locationType in the request."
[/MB]

Section 6.6

I think that that says the same as what is there now.. ;)
[MB] I'll disagree somewhat on this point. I think that it's perfectly
acceptable and not a bad idea even to be very explicit about the content
(e.g., I prefer the statement that references the explicit values in the
locationType rather than making the more general statement that's in the
case of location by value).  However, I do agree that we could delete
the rest of the paragraph starting with the sentence "Per the GEOPRIV
location Object Format...." and combine the 2nd and 3rd paragraphs
something like:
  "The LIS MUST follow the subset of the rules relating
   to the construction of the "location-info" element in the PIDF-LO
   Usage Clarification, Considerations and Recommendations document
   [12] in generating the PIDF-LO for the "presence" parameter." 
And, for the record, I'll note that the text being deleted has been in
that form (in another section) since the -00 (it was actually in the
protocol overview in that version. 
And, if we remove the detail from that section, we have a related change
to make by removing the reference to "further detail in section 4.1.
[/MB]

Section 9
The last sentence at the bottom of page 19 should say "HELD
locationResponse and error messages". Since HELD errors are returned in
an HTTP 200 OK
[MB] Good catch. That's a hold-over from when there was not a separate
error message. [/MB]

Section 10.2
Third paragraph, nit, "that location given only _to_ authorized
clients".
[MB] Yep. I'll fix that. [/MB]

Bullet points. One of the key things that we found when implementing the
open source LIS was that the LIS needed to be aware of identifier (IP
address) re-allocation. In particular if I have a location URI that
pointed to your IP address, but you dropped of the network, and that IP
address was now allocated to me, the LIS needs to know that the URI that
you had is now invalid because it points to me instead of you. I don't
quite get that use case out of the bullets as currently written, and I
think it is a different use case than what is actually being described.
[MB] I'm not clear on your concern. I would think the issue you
highlight is covered by both the 1st (limited lifetime) and 3rd bullets
(LIS is made aware of device movement).  So, perhaps to address your
concern we should expand the text in the 1st and 3rd bullets so it's
clear it addresses your concern or add your example to the intro
paragraph (i.e., after the sentence on temporary spoofing).  [/MB]

Section 11.1
The example on page 25 needs to have a <method> element added.
[MB] Okay. I'll add one. [/MB]

And that is it!
Well done! 

Cheers
James

------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately
and delete the original.  Any unauthorized use of this email is
prohibited.
------------------------------------------------------------------------
------------------------
[mf2]