Subject: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 12:10:54 -0500

All -

Hannes and James tell me that http://www.ietf.org/internet-drafts/ 
draft-ietf-geopriv-pdif-lo-profile-07.txt
is ready for WGLC. This document's been around for a long time, but  
it's been awhile since
it's received comment on the list. Now is a good time to read through  
it and make sure it says what you
remember it should say.

I'd like to get a good record of how much review the document's  
received, so please respond even if
you have no changes to suggest. If you are ok with the document  
progressing, but don't plan to review
it yourself, I'd like to hear that too.

Please send comments to the list by June 22.

Thanks,

RjS

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 18 Jun 2007 10:10:18 -0500

I have seen zero responses to this call so far. Please get your  
response in by the 22nd (that's this Friday).

RjS

On Jun 4, 2007, at 12:10 PM, Robert Sparks wrote:

> it's received comment on the list. Now is a good time to read  
> through it and make sure it says what you
> remember it should say.
>

---

From: <[email-masked]>
Date: Wed, 20 Jun 2007 13:11:27 -0400

Hi all,

The only concern I have is with rule #3 (in section 3):

   Rule #3:  Providing more than one location chunk in a single presence
      document (PIDF) MUST only be done if all objects refer to the same
      place.

While I agree that that would minimize ambiguity, I find it incompatible with RFC-4479 ("A Data Model for Presence") which distinguishes between presence attributes for a person, services and devices. Using this construct, it is quite possible to express more that one "discrete location" throughout the whole document (for different devices, for example). I wouldn't want to discard rule #3 altogether however, so I think adding just a bit of semantics might be sufficient. For example:

   Rule #3:  Providing more than one location chunk in a single presence
      document (PIDF) or in a specific construct, within that document,
	that represents a single conceptual entity MUST only be done if all 	objects refer to the same place.

I don't care much about the wording... I would just like to avoid having a legitimate PIDF-LO guideline limit presence information expressiveness, although I acknowledge that achieving expressiveness and unambiguity at the same time is not always easy.
 
I don't have any specific comment on the geodetic shapes part (sections 4 and 5) as I'm not very familiar with this area, so all of this sounds good to me.

Also, some minor corrections:

- (in the abstract) "To allow successfully interoperability" should read "To allow successful interoperability"

- (at the end of rule #9) "with the first document be considered first" should read "with the first document considered first"

- (in section 3.2) "Applying rules #6 and #7 are applied" should read "Applying rules #6 and #7"

- (in section 6) "shapes and volumes should assumed" should read "shapes and volumes should be assumed"

- (in section 6) "when associated representing a Target's location" should read "when representing a Target's location"

Thanks,

Jérôme Grenier

-----Message d'origine-----
De : Robert Sparks [mailto:[email-masked]] 
Envoyé : 18 juin 2007 11:10
À : [email-masked]
Objet : Re: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt

RjS

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Wed, 20 Jun 2007 15:59:06 -0600

Have read through the document. From a GML and from the GML 3.1.1 PIDF-LO 
Shape Application Schema for use by the Internet Engineering Task Force 
(IETF)", the document appears to be spot-on. My only suggestion is that for 
the polygon example, it might be useful to show how all of the coordinates 
can be expressed in a more compact manner. So instead of:

               <gml:exterior>
                 <gml:LinearRing>
                   <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                   <gml:pos>43.211 -73.422</gml:pos> <!--H-->
                   <gml:pos>43.111 -73.322</gml:pos> <!--G-->
                   <gml:pos>43.111 -73.222</gml:pos> <!--F-->
                   <gml:pos>43.211 -73.122</gml:pos> <!--E-->
                   <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                   <gml:pos>43.411 -73.222</gml:pos> <!--C-->
                   <gml:pos>43.411 -73.322</gml:pos> <!--B-->
                   <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                 </gml:LinearRing>
              </gml:exterior>

you could also have an example that shows:

               <gml:exterior>
                 <gml:LinearRing>
                   <gml:posList>43.311 -73.422 43.211 -73.422 
 43.111 -73.322 43.111 -73.222 43.211 -73.122 43.311 -73.122 43.411 -73.222 
43.411 -73.322 43.311 -73.422</gml:posList>
                 </gml:LinearRing>
              </gml:exterior>

Makes for a much more compressed expression of the coordinates. However, it 
does introduce the use of "posList" for expressing polygon coordinates. 
However, "posList" is used for the coordinate list in Prism. Very 
straightforward to double check the GML 3.1.1 schemas in the OGC Best 
Practices document. Not critical and up to Martin et. al.

 Regards

Carl

----- Original Message ----- 
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 04, 2007 11:10 AM
Subject: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt

> is ready for WGLC. This document's been around for a long time, but  it's 
> been awhile since
> it's received comment on the list. Now is a good time to read through  it 
> and make sure it says what you
> remember it should say.
>
> I'd like to get a good record of how much review the document's  received, 
> so please respond even if

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 20 Jun 2007 16:35:23 -0700

My comments to <draft-ietf-geopriv-pdif-lo-profile-07.txt> are as
follows:

C1. Section  3. Using Location Information, minor - comment, [RM - Since
this section plunges into talking about a PIDF document, yet doesn't
define PIDF, only PIDF-LO in the Introduction, it would be helpful to
have some explanation as to what a PIDF doc is - in contrast to a more
specific PIDF-LO description (to me, one is a specific instance of the
other).]

C2. Section  3. Using Location Information, para. 2., minor - change
from, "Hence, a single PIDF document may contain an arbitrary number of
location objects" to, "Hence, a single PIDF document may contain, within
multiple tuple elements, and likewise, within multiple geopriv elements,
an arbitrary number of location objects"

C3. Section 3., Rule #1, minor - comment, [RM - Given 'Rule #1: A
<geopriv> element MUST describe a discrete location.', it would be good
to define what a discrete location is, since I would imagine that a
PIDF-LO might only (sometimes) contain a 'coarse', or 'gross' location,
such as the name of a one-PSAP town (emergency use-case), yet I'm not
sure that most people would think of 'Philadelphia PA' as a 'discrete'
location.]

C4. Section 3., major - comment, [RM - Rules 3 & 5 seem to be in
contradict to one another.  On one hand, the explanation of rule 3
states, "This may occur if a Target's location is determined using a
series of different techniques.", whereas rule 5 says, "locations MUST
be provided ... by the same location determination method.".]

C5. Section 3., major - comment, [RM - I don't see how the 'same
location determination method' can be referenced in the case of rule 5's
explanation, for example (as stated), "a geodetic location describing a
point, and a civic location indicating the floor in a building.".  A GPS
determination method could provide a geodetic point, but determination
of the floor would likely be based on calibrated association
(interpretation) to some calculated altitude, or via some other method
altogether.  I think rule 5 is untenable as written.]

Regards,

-roger marshall.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 10:11 AM
> To: [email-masked]
> is ready for WGLC. This document's been around for a long 
> time, but it's been awhile since it's received comment on the 
> list. Now is a good time to read through it and make sure it 
> says what you remember it should say.
> 
> I'd like to get a good record of how much review the 
> document's received, so please respond even if you have no 
> changes to suggest. If you are ok with the document 
> progressing, but don't plan to review it yourself, I'd like 
> to hear that too.
> 

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Jun 2007 18:51:42 -0500

Hi Roger,

Comments and snips inline.

Cheers
James

> specific PIDF-LO description (to me, one is a specific instance of the
[AJW] We can add a brief section saying what a PIDF is. I would point
out that this is already stated in RFC4119 however.

> an arbitrary number of location objects"
[AJW] Okay

> sure that most people would think of 'Philadelphia PA' as a 'discrete'

[AJW] Discrete location is defined in section 2.

> be provided ... by the same location determination method.".]

[AJW] Not at all.
      #3 Says same document, describe the same location. It makes no
statement about how location is determined.
      #5 says if you have a PIDF-LO document, then location inside the
same 
        <location-info> element have to have come form the same source
and been determined in the same way.

Let me give you an example.
I can have a single PIDF document with multiple location objects in it
if they all describe where I currently am, or was.
If I get one set of data from DHCP, say using LCI form 3825, I can have
a location-info element that has geodetic and civic data (civic for
floor), and I would have a method of DHCP. This does not contravene any
rules.

In a separate tuple, I can provide data obtain from HELD. In yet another
tuple I can provide data that came from my GPS.

I hope this clarifies things a bit.

> altogether.  I think rule 5 is untenable as written.]

[AJW] Please previous explanation for why I don't believe that this is
the case.

> The information contained in this message may be privileged and/or
> confidential. If you are not the intended recipient, or responsible
for
> delivering this message to the intended recipient, any review,
forwarding,
> dissemination, distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received this
message in
> error, please so notify the sender immediately, and delete it and all
> attachments from your computer and network.
> 
> 
> 

------------------------------------------------------------------------------------------------
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: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Jun 2007 18:52:51 -0500

Hi Jerome,

Thanks for your comments.

So to put an example around your proposed clarification, you think that I should be able to express in a PIDF-LO my current location, and say my nominal home location?

I guess I can see where communicating this in a PIDF-LO may be useful, though I am not sure how you can effectively convey that this is home vs current location. Certainly the application we have most discussed to date, call routing, could be sorely confused by doing this. Though, I would be the first to admit that we have only scratched the tip of the iceberg with regards to applications.

I found the suggested change in wording quite confusing, and I was really shooting for clarity in these requirements. 

Would it be reasonable to change the MUST in the original wording to it is RECOMMENED that?

This would not preclude it, but would discourage it for general use.

Cheers
James

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, 21 June 2007 3:11 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt
> 
> Hi all,
> 
> While I agree that that would minimize ambiguity, I find it incompatible
> with RFC-4479 ("A Data Model for Presence") which distinguishes between
> presence attributes for a person, services and devices. Using this
> construct, it is quite possible to express more that one "discrete
> location" throughout the whole document (for different devices, for
> example). I wouldn't want to discard rule #3 altogether however, so I
> think adding just a bit of semantics might be sufficient. For example:
> 
> I don't care much about the wording... I would just like to avoid having a
> legitimate PIDF-LO guideline limit presence information expressiveness,
> although I acknowledge that achieving expressiveness and unambiguity at
> the same time is not always easy.
> 
> I don't have any specific comment on the geodetic shapes part (sections 4
> and 5) as I'm not very familiar with this area, so all of this sounds good
> to me.
> 
> - (at the end of rule #9) "with the first document be considered first"
> should read "with the first document considered first"
> 
> - (in section 6) "when associated representing a Target's location" should
> read "when representing a Target's location"
> 
> Thanks,
> 
> Jérôme Grenier
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Jun 2007 22:32:30 -0500

Hi Carl,

I am happy to add the additional form to show that a shortened form is
possible. For clarity I long the longer form better... *8)

Cheers
James

> From: Carl Reed OGC Account [mailto:[email-masked]]
> Sent: Thursday, 21 June 2007 7:59 AM
> To: [email-masked]; Robert Sparks
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt
> 
> (IETF)", the document appears to be spot-on. My only suggestion is
that
> Makes for a much more compressed expression of the coordinates.
However,
> it
> it's
through

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 21 Jun 2007 08:17:59 -0700

James:

I don't think we've got the right terminology still [see 'C3' snip
below].

> > be provided ... by the same location determination method.".]
...
> I can have a single PIDF document with multiple location 
> objects in it if they all describe where I currently am, or was.
> If I get one set of data from DHCP, say using LCI form 3825, 
> I can have a location-info element that has geodetic and 
> civic data (civic for floor), and I would have a method of 
> DHCP. This does not contravene any rules.
> 
> In a separate tuple, I can provide data obtain from HELD. In 
> yet another tuple I can provide data that came from my GPS.

Thanks for the clarification.  It's now apparent (to me) that the text
should be referring to 'configuration' or 'acquisition', rather than
'determination'.  Location determination, I hope you'd agree, is
provided in conjunction w/methods as listed in the IANA registry, not
via DHCP or HELD, etc. (http://www.iana.org/assignments/method-tokens).
This same need for the right term applies to my 'C5' as well.

-roger marshall.

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2007 4:52 PM
> To: Roger Marshall; Robert Sparks; [email-masked]
> [AJW] We can add a brief section saying what a PIDF is. I 
> would point out that this is already stated in RFC4119 however.
> 
>       #3 Says same document, describe the same location. It 
> makes no statement about how location is determined.
>       #5 says if you have a PIDF-LO document, then location 
> inside the same 
>         <location-info> element have to have come form the 
> same source and been determined in the same way.
> 
> I can have a single PIDF document with multiple location 
> objects in it if they all describe where I currently am, or was.
> If I get one set of data from DHCP, say using LCI form 3825, 
> I can have a location-info element that has geodetic and 
> civic data (civic for floor), and I would have a method of 
> DHCP. This does not contravene any rules.
> 
> In a separate tuple, I can provide data obtain from HELD. In 
> yet another tuple I can provide data that came from my GPS.
> 
> > explanation, for example (as stated), "a geodetic location 
> describing
> a
> [AJW] Please previous explanation for why I don't believe 
> that this is the case.
> 
> > 
> > Regards,
> > 
> > 
> > -roger marshall.
> > 
> time, but 
> > > it's been awhile since it's received comment on the list. 
> Now is a 
> > > good time to read through it and make sure it says what 
> you remember 
> > > it should say.
> > >
> > > received, so please respond even if you have no changes 
> to suggest. 
> > > If you are ok with the document progressing, but don't plan to 
> > > review it yourself, I'd like to hear that too.
> > >

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Jun 2007 16:55:47 -0500

Hi Roger,

One quick further comment below.

> via DHCP or HELD, etc.
(http://www.iana.org/assignments/method-tokens).
> This same need for the right term applies to my 'C5' as well.

[AJW] Method technically in this case is probably wiremap, that is, we
used some kind of circuit or tother information that enabled us to
determine the location we have pre-stored in a database. The DHCP method
as defined is a special case of wiremap, it says that the information
provided came from DHCP relay information, not that DHCP was used at the
acquisition protocol, at least that is my take on it.

I don't think that we need to convey information relating to how we
determined the location that we have in our wiremap database.

Cheers
James

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 21 Jun 2007 15:44:09 -0700

James:
I still don't understand.  Let me try again, by defining terms.

-- Location Determination: method by which a location is 'calculated' or
'given'.  This could be, for example something like trilateration (often
referred to as triangulation), or manually input (provisioned),
respectively.

This definition is similar, but not exactly the same as what you've
stated in another of your drafts,
(http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held-capabili
ties-01.txt), since your definition doesn't take into account manual
inputs:

  Location Determination:  The process of finding the location of a
      Device, either by calculation or correlation.  The many-varied
      processes for location determination are outside the scope of this
      document. 

-- Location Configuration: method by which a location is 'acquired' into
an end device or middlebox, for subsequent use in a location-based
operation (e.g., LoST routing).

My following assertions are based on the above defns.

In the pidf-lo-profile draft, rules 3 & 5 text talk about determination,
not configuration.  From prior email, it sounds like the intent of 3 & 5
is for configuration, not determination.  If so, let's change the term.

My original point around rule 5 was that, if you don't change the term
from determination to configuration, then rule 5 cannot always work -
since a lat/lon produced via trilateration and a bldg. floor produced by
extrapolation are NOT the same (determination) method - thus violating
the rule.

My point to rule 3, was that the justification text should likewise be
changed to 'configured' instead of 'determined' for all the same
reasons.

-roger marshall.

> Sent: Thursday, June 21, 2007 2:56 PM
> [AJW] Method technically in this case is probably wiremap, 
> that is, we used some kind of circuit or tother information 
> that enabled us to determine the location we have pre-stored 
> in a database. The DHCP method as defined is a special case 
> of wiremap, it says that the information provided came from 
> DHCP relay information, not that DHCP was used at the 
> I don't think that we need to convey information relating to 
> how we determined the location that we have in our wiremap database.
> 
> Cheers
> James
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Jun 2007 18:16:08 -0500

Roger,

I don't agree with your interpretation of those definitions.
The acquisition is the LCP, be it HELD, DHCP, LLDP-MED, this is not
determination.

Wiremap correlations may be things like DHCP-Relay, switch port etc.
This is determination. How information was derived and put into my
wiremap database is a level of indirection that is not addressed by the
Method value.

If I use parameters such a timing advance etc and then compute a
location using a specific method, such as UTDOA for example, then that
should be the method.

I don't believe that the rules state anything to contrary on this. What
you are asking for is for the method to reflect how the data in the
database was calculated or arrived out, that is not in my view what the
method parameter is trying to provide.

Cheers
James 

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Friday, 22 June 2007 8:44 AM
> To: Winterbottom, James; Robert Sparks; [email-masked]
> > Subject: RE: [Geopriv] WGLC:
draft-ietf-geopriv-pidf-lo-profile-07.txt
for
forwarding,
message in

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 21 Jun 2007 16:32:13 -0700

James: Please see my inline responses. 

Thx.

-roger marshall.

> Sent: Thursday, June 21, 2007 4:16 PM
> The acquisition is the LCP, be it HELD, DHCP, LLDP-MED, this 
> is not determination.
We're in whole-hearted agreement here.

> This is determination. How information was derived and put 
> into my wiremap database is a level of indirection that is 
> not addressed by the Method value.
Agree - I think, except which 'Method' value are you pointing to,
determination method or configuration method (I assume you meant
determination method).

> 
> If I use parameters such a timing advance etc and then 
> compute a location using a specific method, such as UTDOA for 
> example, then that should be the method.
Agree that it should be the determination 'method', but not the
configuration 'method' - (configuration is what rules 3 & 5 are aiming
at).

> 
> I don't believe that the rules state anything to contrary on 
> this. What you are asking for is for the method to reflect 
> how the data in the database was calculated or arrived out, 
> that is not in my view what the method parameter is trying to provide.
I'm not advocating that the determination method be reflected in either
rule 3 or 5, and therefore the terms 'determined, determination' should
not appear in the rules either.  Check the text yourself, why would
these 'det' terms be used in rules 3 & 5?

> > -- Location Determination: method by which a location is 
> 'calculated'
> or
> > not configuration.  From prior email, it sounds like the 
> intent of 3 &
> 5
> > since a lat/lon produced via trilateration and a bldg. 
> floor produced
> by
> > > [AJW] Method technically in this case is probably 
> wiremap, that is, 
> > > we used some kind of circuit or tother information that 
> enabled us 
> > > to determine the location we have pre-stored in a 
> database. The DHCP 
> > > method as defined is a special case of wiremap, it says that the 
> > > information provided came from DHCP relay information, 
> not that DHCP 
> > > was used at the acquisition protocol, at least that is my take on 
> > > it.
> > >
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.

---

From: <[email-masked]>
Date: Tue, 26 Jun 2007 10:34:00 -0400

Hi James,

The example I had in mind was more along the lines of expressing the fact that two of my devices are currently at different locations (using RFC-4479 "A Data Model for Presence") and that I'll be at another location tomorrow (using RFC-4481 "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals"), all using one PIDF document.

As long as it's clear in everyone's mind that draft-ietf-geopriv-pidf-lo-profile does not restrict PIDF-LO documents to the only-one-location-now scenario, I'm fine. I guess that when a PIDF document's structure brings enough semantics to allow me to unambiguously interpret different location pieces scattered in the document, I won't need the guidelines of draft-ietf-geopriv-pidf-lo-profile. However, if a very scoped part of my semantically-structured PIDF document exposes potentially ambiguous pieces of location information, then I'll be happy that the originator of the document has followed draft-ietf-geopriv-pidf-lo-profile so that I'll know that these pieces of location information are not in conflict. It is this whole-document-or-scoped-part nuance that I tried to bring to rule #3, but I realize it was a bit confusing.

Either the MUST is changed into RECOMMENDED for rule #3 or (preferably) some text is added to clarify that these rules (those with "MUST") are required only when there is potential for ambiguity.

Jérôme

-----Message d'origine-----
De : Winterbottom, James [mailto:[email-masked]] 
Envoyé : 20 juin 2007 19:53
À : Grenier, Jerome (6002687); [email-masked]; [email-masked]
Objet : RE: [Geopriv] WGLC: draft-ietf-geopriv-pidf-lo-profile-07.txt

Hi Jerome,

Cheers
James

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Jun 2007 05:42:21 -0400

We definitely need to allow devices (and maybe services) to be at  
different locations, as that is part of the composition algorithm and  
can be used to detect, for example, which service is most likely to  
succeed. A reference from lo-profile to the data model document would  
be most helpful.

On Jun 26, 2007, at 10:34 AM, <[email-masked]>  
<[email-masked]> wrote:

> Hi James,
>
> The example I had in mind was more along the lines of expressing  
> the fact that two of my devices are currently at different  
> locations (using RFC-4479 "A Data Model for Presence") and that  
> I'll be at another location tomorrow (using RFC-4481 "Timed  
> Presence Extensions to the Presence Information Data Format (PIDF)  
> to Indicate Status Information for Past and Future Time  
> Intervals"), all using one PIDF document.
>
> As long as it's clear in everyone's mind that draft-ietf-geopriv- 
> pidf-lo-profile does not restrict PIDF-LO documents to the only-one- 
> location-now scenario, I'm fine. I guess that when a PIDF  
> document's structure brings enough semantics to allow me to  
> unambiguously interpret different location pieces scattered in the  
> document, I won't need the guidelines of draft-ietf-geopriv-pidf-lo- 
> profile. However, if a very scoped part of my semantically- 
> structured PIDF document exposes potentially ambiguous pieces of  
> location information, then I'll be happy that the originator of the  
> document has followed draft-ietf-geopriv-pidf-lo-profile so that  
> I'll know that these pieces of location information are not in  
> conflict. It is this whole-document-or-scoped-part nuance that I  
> tried to bring to rule #3, but I realize it was a bit confusing.
>
> Either the MUST is changed into RECOMMENDED for rule #3 or  
> (preferably) some text is added to clarify that these rules (those  
> with "MUST") are required only when there is potential for ambiguity.
>
> Jérôme
>
> So to put an example around your proposed clarification, you think  
> that I should be able to express in a PIDF-LO my current location,  
> and say my nominal home location?
>
> I guess I can see where communicating this in a PIDF-LO may be  
> useful, though I am not sure how you can effectively convey that  
> this is home vs current location. Certainly the application we have  
> most discussed to date, call routing, could be sorely confused by  
> doing this. Though, I would be the first to admit that we have only  
> scratched the tip of the iceberg with regards to applications.
>
> I found the suggested change in wording quite confusing, and I was  
> really shooting for clarity in these requirements.
>
>> - (in the abstract) "To allow successfully interoperability"  
>> should read
>> "To allow successful interoperability"
>>
>> - (in section 6) "shapes and volumes should assumed" should read  
>> "shapes
>> and volumes should be assumed"
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 28 Jun 2007 18:41:47 -0500

Hi Henning,

I am in the process of releasing the 08 version of PIDF-LO profile, and I have added an opening paragraph to the introduction that addressed Jerome's concern. I will further add a reference from this section the data model document (RFC4479).

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 28 June 2007 7:42 PM
> To: <[email-masked]>
> Cc: GEOPRIV WG