Subject: RE: [Geopriv] Comments on HELD-03

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Jan 2008 18:12:16 -0600

Hi Eric,

Thanks for your time in reviewing the document.  Most of your comments sound reasonable to me.  I’ve inserted 

________________________________

From: Arolick, Eric [mailto:[email-masked]] 
Sent: Thursday, 27 December 2007 9:55 AM
To: [email-masked]
Subject: [Geopriv] Comments on HELD-03

Below are comments on draft 3 of HELD. Most are suggestions for readability or clarity and also to be more explicit and consistent in the wording. I apologize if any are duplicates of comments received from others.

Eric Arolick

 - First paragraph of Introduction, the second sentence is awkward – suggest moving the phrase that starts with “such as” at the end of the sentence to the middle of the sentence after the words “access network”, since this is what is being referred to. As it reads now, the first impression is that “such as …” is related to “location information”.

- Last paragraph of Section 3 – Should there be a reference to the identity-extensions document? – Or perhaps some general text that alerts the reader that the base protocol described in this document may be extended by other documents?

[MT] I’m of the opinion that it we don’t want to reference other documents here.  There are quite a few extensions that have already been proposed, and no doubt more that could be included.  From a purely pragmatic perspective, adding references slows the progress of this document.  On the point of extensions, I should think that extensibility is an expectation of IETF protocols.  A brief statement would be OK.

- Section 4.1.2 – In the first sentence, it seems that the word “accurate” could lead to misinterpretation. What is the measure of accuracy that the LIS should use to determine if it should provide location information? Maybe replace with “correct” or “appropriate” or reword to describe that the LIS should not return location when certain conditions are recognized.

[MT] Since “accurate” is a qualitative term, we can be a little more lax in its usage.  I don’t think that the usage in this section is inappropriate.  I don’t like “appropriate” though – it’s too vague.

- Section 4.1.2 – To perhaps make the section more clear, remove the last sentence of the first paragraph and the first sentence of the second paragraph. Start the second sentence of the second paragraph with “To recognize these conditions, the LIS operator …” Then combine into 1 paragraph.

- Section 6, Table – The table should indicate that PIDF-LO is an optional component in the Response message.

- Section 6, Table – The table should not indicate that the code parameter is included in the location response message. According to Section 6.3, code is only used for errors.

- Section 6.1 – This section has a lot of explanatory text but never explicitly states the requirement for the protocol. Suggest adding at the beginning – “The responseTime parameter MAY be included in a location request message. When included, the possible value is either a decimal seconds value, or a value of emergencyRouting or emergencyDispatch.” Then remove “is optional and” from the current first sentence.

- Section 6.2 – Skip a line before the list of possible values. For the “any” parameter, remove the second sentence. To be consistent with the language of the previous section, include the following sentence after the sentence that ends with “location URI” - “If the locationType parameter is absent, this value MUST be assumed as the default.”

- Section 6.2 - For locationURI, as has been pointed out in other documents, there are two kinds of references. A reference can point to a fixed location at the time the reference is created (i.e. snapshot URI) or will return the current location at the time of de-referencing. Since the capability for the requestor to indicate what it wants is not part of this document, what kind should the LIS return? This document should describe the default kind of reference the LIS will return, or at least describe that there are two types and that it is left to the LIS to decide what type will be returned.

[MT] It might be wise to recommend that the LIS provide location information that is current at the time of de-reference.  Specific types of reference (snapshot, limited use) are covered in held-contexts.

- Section 6.2 – Suggest replacing the last 2 sentences of the paragraph after the list of values that describe the “exact” parameter with – “The location types the LIS returns also depends on the setting of the optional “exact” attribute, as described in the following section.”

- Section 6.2.1 – Start the section with “ The “exact” attribute MAY be included in a locationRequest when the locationType parameter is included.”

- Section 6.5 – Is the meaning of “scheme” in the context it is used in the second paragraph well known? I think some further explanatory text would help clarify what is meant.

[MT] I think this is OK.  It might be clearer if “URI scheme” were used in the first instance, but we have to assume that the readership have at least this much background.

- Section  6.5.1 – Remove “optional” from the first sentence. As the last sentence indicates, expires is not optional, it is conditionally required.

- Section 7 – Should the XML schema indicate that PIDF-LO may be included in a Location Response?

[MT] Ideally, yes, this would be the case.  However, the fact that the PIDF-LO is optional causes a clash with the “Unique Particle Attribution” schema constraint, one of the most contentious “features” of XML schema.  The text that you have suggested in Section 6 (a suggestion that I have also made) will have to suffice.

------------------------------------------------------------------------------------------------
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://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Arolick, Eric" <[email-masked]>
Date: Wed, 2 Jan 2008 13:40:32 -0500

Martin

Thanks for the responses. See below for some follow-up.

Eric

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, January 01, 2008 7:12 PM
To: Arolick, Eric; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Hi Eric,

Thanks for your time in reviewing the document.  Most of your comments
sound reasonable to me.  I've inserted 

Below are comments on draft 3 of HELD. Most are suggestions for
readability or clarity and also to be more explicit and consistent in
the wording. I apologize if any are duplicates of comments received from
others.

Eric Arolick

 - First paragraph of Introduction, the second sentence is awkward -
suggest moving the phrase that starts with "such as" at the end of the
sentence to the middle of the sentence after the words "access network",
since this is what is being referred to. As it reads now, the first
impression is that "such as ..." is related to "location information".

- Last paragraph of Section 3 - Should there be a reference to the
identity-extensions document? - Or perhaps some general text that alerts
the reader that the base protocol described in this document may be
extended by other documents?

[MT] I'm of the opinion that it we don't want to reference other
documents here.  There are quite a few extensions that have already been
proposed, and no doubt more that could be included.  From a purely
pragmatic perspective, adding references slows the progress of this
document.  On the point of extensions, I should think that extensibility
is an expectation of IETF protocols.  A brief statement would be OK.

EA - Agree that specific references can be problematic. I think a brief
statement would be useful as a hint to the reader to go look for
extension documents, since, as you point out, many already exist.

- Section 4.1.2 - In the first sentence, it seems that the word
"accurate" could lead to misinterpretation. What is the measure of
accuracy that the LIS should use to determine if it should provide
location information? Maybe replace with "correct" or "appropriate" or
reword to describe that the LIS should not return location when certain
conditions are recognized.

[MT] Since "accurate" is a qualitative term, we can be a little more lax
in its usage.  I don't think that the usage in this section is
inappropriate.  I don't like "appropriate" though - it's too vague.

EA - I could be mistaken, but I think some might see "accurate", rightly
or wrongly, as a quantitative term and then there could be other
interpretations of the first sentence. The point of the text is not to
return location when NAT or VPN is recognized and the LIS can therefore
not correctly determine location. Maybe the first sentence should be
combined with the second sentence to read - A LIS MUST NOT provide
location information to a Device where the Device uses a VPN connection
or is behind a NAT... 

- Section 4.1.2 - To perhaps make the section more clear, remove the
last sentence of the first paragraph and the first sentence of the
second paragraph. Start the second sentence of the second paragraph with
"To recognize these conditions, the LIS operator ..." Then combine into
1 paragraph.

- Section 6, Table - The table should indicate that PIDF-LO is an
optional component in the Response message.

- Section 6, Table - The table should not indicate that the code
parameter is included in the location response message. According to
Section 6.3, code is only used for errors.

- Section 6.1 - This section has a lot of explanatory text but never
explicitly states the requirement for the protocol. Suggest adding at
the beginning - "The responseTime parameter MAY be included in a
location request message. When included, the possible value is either a
decimal seconds value, or a value of emergencyRouting or
emergencyDispatch." Then remove "is optional and" from the current first
sentence.

- Section 6.2 - Skip a line before the list of possible values. For the
"any" parameter, remove the second sentence. To be consistent with the
language of the previous section, include the following sentence after
the sentence that ends with "location URI" - "If the locationType
parameter is absent, this value MUST be assumed as the default."

- Section 6.2 - For locationURI, as has been pointed out in other
documents, there are two kinds of references. A reference can point to a
fixed location at the time the reference is created (i.e. snapshot URI)
or will return the current location at the time of de-referencing. Since
the capability for the requestor to indicate what it wants is not part
of this document, what kind should the LIS return? This document should
describe the default kind of reference the LIS will return, or at least
describe that there are two types and that it is left to the LIS to
decide what type will be returned.

[MT] It might be wise to recommend that the LIS provide location
information that is current at the time of de-reference.  Specific types
of reference (snapshot, limited use) are covered in held-contexts.

EA - Yes, and with the recommendation maybe there should be an
additional sentence that says - Making requests for specific types of
references is outside the scope of this document - similar to the
sentence in Section 3 about the use of additional identifiers being out
of scope.

- Section 6.2 - Suggest replacing the last 2 sentences of the paragraph
after the list of values that describe the "exact" parameter with - "The
location types the LIS returns also depends on the setting of the
optional "exact" attribute, as described in the following section."

- Section 6.2.1 - Start the section with " The "exact" attribute MAY be
included in a locationRequest when the locationType parameter is
included."

- Section 6.5 - Is the meaning of "scheme" in the context it is used in
the second paragraph well known? I think some further explanatory text
would help clarify what is meant.

[MT] I think this is OK.  It might be clearer if "URI scheme" were used
in the first instance, but we have to assume that the readership have at
least this much background.

- Section  6.5.1 - Remove "optional" from the first sentence. As the
last sentence indicates, expires is not optional, it is conditionally
required.

- Section 7 - Should the XML schema indicate that PIDF-LO may be
included in a Location Response?

[MT] Ideally, yes, this would be the case.  However, the fact that the
PIDF-LO is optional causes a clash with the "Unique Particle
Attribution" schema constraint, one of the most contentious "features"
of XML schema.  The text that you have suggested in Section 6 (a
suggestion that I have also made) will have to suffice.

EA - OK. I did some XML reading and I think I understand. To reflect the
text in Section 6, would it be useful to have text or a footnote in
Section 7 that indicates that PIDF-LO is not shown as an optional
element in the location response due to XML schema constraints? 

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 4 Jan 2008 12:14:57 -0600

Eric and Martin,
 
My comments are embedded below [MB].
 
Thanks,
Mary.

From: Arolick, Eric [mailto:[email-masked]] 
Sent: Wednesday, January 02, 2008 12:41 PM
To: Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Martin

Eric

Hi Eric,

Eric Arolick

[MB] Yes, we do not want to reference other docs, as we did that in the
past and the consensus was to remove all those references. We should
just be able to qualify the description of the protocol in the
introduction as extensible, by changing the first sentence of the last
paragraph in the introduction as follows:

OLD:

   This specification defines an XML-based protocol that enables the
   retrieval of LI from a LIS by a Device. 

NEW:

   This specification defines an extensible XML-based protocol that
enables the
   retrieval of LI from a LIS by a Device. 

[/MB]

[MB]  Per the thread of discussion on Roger Marshall's comments, there's
already a proposal to change that text, combining sentences, etc. I
won't repeat it here, but here's a link to that thread:

http://www1.ietf.org/mail-archive/web/geopriv/current/msg04991.html

Please reply to that part of the thread if you have concerns about the
proposed rewording.

[/MB]

[MB] See above. [/MB] 

[MB]    There is normative text in section 5.3 that states that the
response contains either a PIDF-LO or locationURI.  However, for
consistency, we should also describe that parameter in detail in section
6. I would propose a section 6.6.  [/MB]

[MB] Good catch. That's a leftover from the reworking of the codes to be
only for error scenarios.  I removed the "message", but not the "code"
for requests.  I'll fix that in the -04. [/MB] 

[MB]  This has already been discussed in response to Cullen's comments
on the document in this thread:

http://www1.ietf.org/mail-archive/web/geopriv/current/msg04951.html

The rewording from "is optional" to "MAY be included" is fine. 

[/MB] 

[MB] Okay, I'll make these NIT changes, but I don't think they're at all
critical to the understanding or intent of the current text.[/MB] 

[MB] I would prefer to not add any of that level of detail to this
document.  We can't prescribe what will be the default kind of reference
the LIS will return.  I think the most we can do is to add a statement
that the specific type of reference is up to the LIS and outside the
scope of this document, but that ends up making this text even more
open-ended that it is right now. The protocol is entirely neutral as to
the types of location URIs.  We have a reference in this document to the
de-referencing protocol and I think that document is where this sort of
material belongs.  [/MB] 

[MB] That's a good idea.[/MB] 

[MB] Another good suggestion. [/MB] 

[MB] I agree, we should qualify the term "scheme" with "URI" as
suggested. [/MB] 

[MB] The "optional" was added in the -02 based on past WG feedback. Take
a look at the diff.   I agree it is conditional, but it seemed overly
complex and confusing add an additional tag to the Table, BUT if it
clarifies things, maybe it's useful.  And, there's actually an issue
with Table 1 in that it specifies "expires" to be mandatory (it's been
that way since the -00 and was that way in the individual document).

[/MB]

[MB] Per my comments on the comment on section 6, I think we should add
PIDF-LO to the table and add a section describing PIDF-LO in section 6.
Martin, I apologize if you made this comment in the past, but I don't
recall having seen a comment like this at all in the past. 

We should also add a statement something like the following at the end
of the first/only paragraph in section 7:

"Note that the PIDF-LO is not explicitly shown in the schema for a
Location Response due to the XML schema constraints. Please refer to
section 6.6 for a details on the PIDF-LO in Location Responses."

[/MB]

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 4 Jan 2008 15:39:43 -0600

Hi Mary,

I have a comment on one of your comments below.

Cheers
James

EA - Yes, and with the recommendation maybe there should be an additional sentence that says - Making requests for specific types of references is outside the scope of this document - similar to the sentence in Section 3 about the use of additional identifiers being out of scope. 
 
[MB] I would prefer to not add any of that level of detail to this document.  We can't prescribe what will be the default kind of reference the LIS will return.  I think the most we can do is to add a statement that the specific type of reference is up to the LIS and outside the scope of this document, but that ends up making this text even more open-ended that it is right now. The protocol is entirely neutral as to the types of location URIs.  We have a reference in this document to the de-referencing protocol and I think that document is where this sort of material belongs.  [/MB] 

[AJW] The Location URIs defined originally for HELD would always return the current location of the Target device, these other types of reference had not really been considered. I believe that for clear implementation guidance we need state what the expected behaviour of the reference is. I would propose therefore text something like the following:

"The location URI provide the LIS is a current location reference, and the Target Device should assume that the LIS will determine its location each time the URI is accessed."

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Jan 2008 11:21:06 -0800

>"The location URI provide the LIS is a current location reference, and the Target Device should assume that the LIS will determine its location each time the URI is accessed."
I don't think this is implementation guidance, so much as deployment guidance
and I'm somewhat concerned as a result.  I believe, in particular, that
"the LIS will determine its location each time the URI is accessed" reflects
a particular deployment mode.   I think it would be better to say something
like

"The location URI provided by the LIS is a reference to the most current available
reference, and the Target Device should understand that it is not a stable reference
to a specific location". 

To make the reference as current as possible, the LIS may re-determine a location
for the target, but it is possible it will return the freshest available data if it
cannot do so or is configured to treat location requests within some time frame
able to use previous responses (two dereference request within the same
second, for example).

To give a concrete example here, I have in the past made 911 calls to report
cars broken down on the highway.  If I made such a call while at the location,
it would be routed to the correct PSAP (since my car and the disabled vehicle
are at the same place).  But if I continue on, my location URI will get updated
with new locations as I move, and a later dereference will give a different
location.  We definitely need to make that clear; we may eventually want
to add functionality to provide a stable reference to a location,
for cases where you want to pass both current and stable. 

			regards,
				Ted

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 7 Jan 2008 14:38:40 -0600

I agree with Ted's suggestion.  Unless folks disagree, I'll include this
sentence in section 6.2 in the paragraph that discusses the LIS
processing for this parameter.

Mary. 

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 1:21 PM
To: Winterbottom, James; Barnes, Mary (RICH2:AR00); Arolick, Eric;
Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

>[AJW] The Location URIs defined originally for HELD would always return
the current location of the Target device, these other types of
reference had not really been considered. I believe that for clear
implementation guidance we need state what the expected behaviour of the
reference is. I would propose therefore text something like the
following:
>
>"The location URI provide the LIS is a current location reference, and
the Target Device should assume that the LIS will determine its location
each time the URI is accessed."
I don't think this is implementation guidance, so much as deployment
guidance and I'm somewhat concerned as a result.  I believe, in
particular, that "the LIS will determine its location each time the URI
is accessed" reflects
a particular deployment mode.   I think it would be better to say
something
like

"The location URI provided by the LIS is a reference to the most current
available reference, and the Target Device should understand that it is
not a stable reference to a specific location". 

To make the reference as current as possible, the LIS may re-determine a
location for the target, but it is possible it will return the freshest
available data if it cannot do so or is configured to treat location
requests within some time frame able to use previous responses (two
dereference request within the same second, for example).

To give a concrete example here, I have in the past made 911 calls to
report cars broken down on the highway.  If I made such a call while at
the location, it would be routed to the correct PSAP (since my car and
the disabled vehicle are at the same place).  But if I continue on, my
location URI will get updated with new locations as I move, and a later
dereference will give a different location.  We definitely need to make
that clear; we may eventually want to add functionality to provide a
stable reference to a location, for cases where you want to pass both
current and stable. 

			regards,
				Ted

---

From: "Arolick, Eric" <[email-masked]>
Date: Mon, 7 Jan 2008 16:17:01 -0500

Mary

Thanks for the response. Just a couple of follow-ups embedded below.

Eric

From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, January 04, 2008 1:15 PM
To: Arolick, Eric; Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Eric and Martin,

Thanks,

Mary.

Martin

Eric

Hi Eric,

Eric Arolick

OLD:

NEW:

[/MB]

EA - The proposed sentence is fine. Is there also some way to indicate
that a number of extensions have already been proposed so a new reader
can know to go look to see what other capabilities are already
potentially in the works?

[/MB]

EA - I think the proposed new text still has the word "accurate" which
was my main concern. I'll see how it reads in the next draft. If others
don't see a problem, then OK.

[MB] See above. [/MB] 

[/MB] 

EA - There's a new thread for this one, so I'll follow the discussion
there.

[/MB]

EA - Maybe the table only needs to address the main parameters.
Sub-parameters like exact (for locationType) and expires (for
locationURI) that are conditional on the presence of other parameters
can be removed from the table and addressed in the text. In fact, the
text above the table already says it is for "top-level components."

[/MB]

---

From: "Stuard, Doug" <[email-masked]>
Date: Mon, 7 Jan 2008 16:20:12 -0500

Perhaps the location returned should be the most recent. Merely
accessing the URI should not re-initiate location determination, as
numerous spurious location taskings could result.  An update should be
specifically requested (although such update could be automated in some
applications).   

_____________________________________________ 
Doug Stuard 
Andrew Network Services 
19700 Janelia Farm Blvd.
Ashburn, VA 20147
703-726-5630
(fax) 703-726-5600

Notice: 
  
This communication from Andrew Corporation, including attachments,
if any, is intended as a confidential and privileged communication.  If
received in error, you should not copy, save, or reproduce in any manner
or form, but delete immediately and notify the sender. 
  
Thank you.

> Sent: Monday, January 07, 2008 2:21 PM
> To: Winterbottom, James; Mary Barnes; Arolick, Eric; Thomson, Martin;
> [email-masked]
> >[AJW] The Location URIs defined originally for HELD would always
> return the current location of the Target device, these other types of
> implementation guidance we need state what the expected behaviour of
> the reference is. I would propose therefore text something like the
> following:
> >
> the Target Device should assume that the LIS will determine its
> location each time the URI is accessed."
> guidance
> report
> are at the same place).  But if I continue on, my location URI will
get
> updated

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 7 Jan 2008 15:28:41 -0600

Doug, 

Ted's response hit the spirit of what I was trying to get at and I am
more than happy with his wording.

Different URIs will result in different types of behaviour at the LIS
and its subsequent responses. Defining, creating and controlling these
URIs is what the Context Management document
(http://tools.ietf.org/html/draft-winterbottom-geopriv-held-context-01)
addresses.

Cheers
James

> From: Stuard, Doug
> Sent: Tuesday, 8 January 2008 8:20 AM
> To: Ted Hardie; Winterbottom, James; Mary Barnes; Arolick, Eric;
Thomson,
> Martin; [email-masked]
accessing
> the URI should not re-initiate location determination, as numerous
> spurious location taskings could result.  An update should be
specifically
> requested (although such update could be automated in some
applications).
> > To make the reference as current as possible, the LIS may
re-determine
> > a location
> > it would be routed to the correct PSAP (since my car and the
disabled
> > vehicle
get

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 7 Jan 2008 16:04:00 -0600

I like it.  However, it does say "reference to the most current available _reference_".  This should probably be "reference to the most current available _location information_".

> From: Winterbottom, James
> Sent: Tuesday, 8 January 2008 8:29 AM
> To: Stuard, Doug; 'Ted Hardie'; 'Mary Barnes'; 'Arolick, Eric'; Thomson,
> Martin; [email-masked]'
> Ted's response hit the spirit of what I was trying to get at and I am more
> than happy with his wording.
> 
> Different URIs will result in different types of behaviour at the LIS and
> its subsequent responses. Defining, creating and controlling these URIs is
> what the Context Management document (http://tools.ietf.org/html/draft-
> winterbottom-geopriv-held-context-01) addresses.
> 
> Cheers
> James
> 
> 
> > To: Ted Hardie; Winterbottom, James; Mary Barnes; Arolick, Eric; Thomson,
> > Martin; [email-masked]
> > requested (although such update could be automated in some applications).
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 7 Jan 2008 16:05:37 -0600

Yes, that is better

> From: Thomson, Martin
> Sent: Tuesday, 8 January 2008 9:04 AM
> To: Winterbottom, James; Stuard, Doug; 'Ted Hardie'; 'Mary Barnes';
> 'Arolick, Eric'; [email-masked]'
> I like it.  However, it does say "reference to the most current
available
> _reference_".  This should probably be "reference to the most current
> available _location information_".
> 
> and
> > its subsequent responses. Defining, creating and controlling these
URIs
> is
> > > if any, is intended as a confidential and privileged
communication.
> If
> > > > return the current location of the Target device, these other
types
> of
> > > > >"The location URI provide the LIS is a current location
reference,
> > and
> > > > and I'm somewhat concerned as a result.  I believe, in
particular,
> > that
> > > > "the LIS will determine its location each time the URI is
accessed"
> > > > reflects
> > > > reference, and the Target Device should understand that it is
not a
> > > > stable reference
> > > > to a specific location".
> > > >
> > > > To make the reference as current as possible, the LIS may re-
> determine
> > > > a location
> > > > cannot do so or is configured to treat location requests within
some
> > > > time frame
> > > > able to use previous responses (two dereference request within
the
> > same
> > > > second, for example).
> > > >
> > > > To give a concrete example here, I have in the past made 911
calls
> to
> > > > report
> > > > cars broken down on the highway.  If I made such a call while at
the
> > > > location,
> > > > with new locations as I move, and a later dereference will give
a
> > > > different
> > > > location.  We definitely need to make that clear; we may
eventually
> > > > want

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 8 Jan 2008 13:01:44 -0600

Hi Eric,
 
I've snipped the thread and have only included responses to the comments
to which you responded [MB2].
 
Thanks,
Mary.

From: Arolick, Eric [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 3:17 PM
To: Barnes, Mary (RICH2:AR00); Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Mary

Eric

Eric and Martin,

Thanks,

Mary.

Martin

Eric

Hi Eric,

Eric Arolick

OLD:

NEW:

[/MB]

[/MB]

[MB2] My view is that the term "accurate" can also be used as a
qualitative term and that's the intent in that sentence.  We have the
same concern you raise no matter what term we use because we can't
mandate what a LIS does.  We can say that the location should be
accurate, correct, appropriate or deviate only a slight amount from the
absolute location, etc. but no matter what, it still depends upon the
LIS as to the degree of accuracy.  In section 6.1, we do mention that
the LIS should return the most accurate location it is capable of
determining within the time specified in the "responseTime".   So, the
proposed text for this section is entirely consistent with other parts
of the document and I think the re-arranging of the sentences per the
referenced thread sufficiently qualifies the use of accurate in this
context. [/MB2] 

.............

[/MB]

[MB2]  You're right in that the content of the table does not match the
text in terms of only list top-level parameters.  I'm beginning to
wonder if the table is useful after all or does its potential to mislead
or confuse outweigh the basic usefulness of the summary.   Does anyone
have any issue if we remove the table?  [/MB2]

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 8 Jan 2008 13:28:08 -0600

Alrighty - so I'll make the change including Martin's suggestion.

Mary.

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 4:04 PM
To: Winterbottom, James; Stuard, Doug; Ted Hardie; Barnes, Mary
(RICH2:AR00); Arolick, Eric; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

I like it.  However, it does say "reference to the most current
available _reference_".  This should probably be "reference to the most
current available _location information_".

> To: Stuard, Doug; 'Ted Hardie'; 'Mary Barnes'; 'Arolick, Eric'; 
> Thomson, Martin; [email-masked]'

> (http://tools.ietf.org/html/draft-
applications).
> > if any, is intended as a confidential and privileged communication.

> > If received in error, you should not copy, save, or reproduce in any

> > manner or form, but delete immediately and notify the sender.
> >
> > Thank you.
> >
> >
> > > To: Winterbottom, James; Mary Barnes; Arolick, Eric; Thomson, 
> > > Martin; [email-masked]
> > > types of reference had not really been considered. I believe that 
> > > for clear implementation guidance we need state what the expected 
> > > behaviour of the reference is. I would propose therefore text 
> > > something like the
> > > following:
> > > >
> > > I don't think this is implementation guidance, so much as 
> > > deployment guidance and I'm somewhat concerned as a result.  I 
> > > believe, in particular,
> that
accessed"
> > > "The location URI provided by the LIS is a reference to the most 
> > > current available reference, and the Target Device should 
> > > understand that it is not a stable reference to a specific 
> > > location".
> > >
> > > re-determine a location for the target, but it is possible it will

> > > return the freshest available data if it cannot do so or is 
> > > configured to treat location requests within some time frame able 
> > > to use previous responses (two dereference request within the
> same
> > > second, for example).
> > >
> > > To give a concrete example here, I have in the past made 911 calls

> > > to report cars broken down on the highway.  If I made such a call 
> > > while at the location, it would be routed to the correct PSAP 
> > > (since my car and the disabled vehicle are at the same place).  
> > > But if I continue on, my location URI will
> get
> > > updated
> > > with new locations as I move, and a later dereference will give a 
> > > different location.  We definitely need to make that clear; we may

> > > eventually want to add functionality to provide a stable reference

> > > to a location, for cases where you want to pass both current and 
> > > stable.
> > >
> > > 			regards,
> > > 				Ted
> > >
> > >

------------------------------------------------------------------------
------------------------
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]

---

From: "Arolick, Eric" <[email-masked]>
Date: Wed, 9 Jan 2008 10:28:29 -0500

Mary

Thanks again.

I think the table in Section 6 is useful and would like to see it remain
in the document. I think having it show only the top-level parameters
would eliminate any confusion. There could perhaps be some additional
text to explain that sub-parameters associated with the parameters shown
in the table are covered in the sections that follow.

Eric 

From: Mary Barnes [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 2:02 PM
To: Arolick, Eric; Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Hi Eric,

Thanks,

Mary.

Mary

Eric

Eric and Martin,

Thanks,

Mary.

Martin

Eric

Hi Eric,

Eric Arolick

OLD:

NEW:

[/MB]

[/MB]

.............

[/MB]

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 9 Jan 2008 10:22:19 -0600

Eric,
 
That sounds like a reasonable approach, so I'll make that change in the
-04, which is currently underway.
 
Mary.

From: Arolick, Eric [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 9:28 AM
To: Barnes, Mary (RICH2:AR00); Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Comments on HELD-03

Mary

Thanks again.

Eric 

Hi Eric,

Thanks,

Mary.

Mary

Eric

Eric and Martin,

Thanks,

Mary.

Martin

Eric

Hi Eric,

Eric Arolick

OLD:

NEW:

[/MB]

[/MB]

.............

[/MB]