Subject: RE: Q&C regarding geopriv-reqs-02

From: Cuellar Jorge <[email-masked]>
Date: Wed, 19 Feb 2003 22:29:03 +0100

Hi James,

I have the impression that now we are converging.  
Hopefully you too! ;)

> > > 1. Under what circumstances is LI optional within a
> > > valid LO (there are *no* LI fields) - section 3.1.2?

> I am going to send you my LO Policy Information and
> Security Information when requesting your LO?

Probably not.

> I see a Location Request as just that, a Location
> Request. I don't believe my LO has anything to do with
> your LO. So I'm not understanding what you intend yet.

The draft says:

Nothing is said about the semantics of a missing field.
For instance, a partially filled object MAY be understood
implicitly as the request to complete it.

I am *not* saying that a missing field is interpreted as a
request.  I say: "nothing is said about ..".  But the
possibility that we decide to use LOs to make requests has
been present since the LO-object draft of Randy, it has
been discussed many times, for instance in San Diego and in
Yokohama and we have never rejected this possibility.

> > In this request you usually have no Location Field,
> > only the requested location data type. A Location
> > Sighter may (in some scenario) tell a Location server
> > that he has spotted some target X, without giving
> > further details on the location.  This may be useful
> > already ("user A is in France") or the Location
> > Sighter may be sending this information as part of a
> > query ("do you need information for this target? At
> > which rate or on demand?").

> I believe in your example, ... <snip>

Let me explain my example in more detail.  Suppose one
Location Sighter (say an Access Provider located in a
certain region, say France) spots some target there.  He
wants to tell to the Location Server associated with this
roaming user, that he is able to provide location
information if required.  He may use the LO without a
location information to tell the LocServer that the target
is there and implicitly or explicitly query if the
LocServer would like further details.

Again, I am not saying that missing fields are understood
as queries ("nothing is said.."), but only that someone,
perhaps the using protocol, of the "geopriv protocol"
(whatever that may be) may decide to do that.

I do not see why we should restrict the choices and require
that all LO MUST have a Location field.

> > > 2.<snip>
> I agree this comment should be there, but I believe we
> should have text stating anything location-based can be
> included regardless of how well its known.

I suggest: "The LO will also be used to convey location
information regardless of how well it is known."

> > > 3. Stated in the Abstract:

> > >    "This document focuses on the authorization,
> > >    integrity and privacy <snip>

> But in order to determine this structure, we should have
> a requirements doc just for that structure (of the LI
> fields) to have a meaningful discussion that has a
> reference. Do you agree with this?

This is rather a question on the charter than on the draft.

Let us agree that the scope of the draft is the privacy
requirements of the LO (plus any other needed thing in
order to discuss privacy properly) and not on general
requirements on the LO format or the geopriv transactions.

Otherwise, this would delay our draft indefinitely.

> > > 4. From the Intro section

> > >    "A key goal of the protocols described in this
> > >    document is to facilitate the protection of
> > >    privacy pursuant to privacy policies set by the
> > >    "user" (or, more precisely in the terminology of
> > >    this document defined in Section 3 below, the
> > >    "Rule Maker")."

> > > This doesn't account for the possibility of any
> > > domain based policies (and
> > > mechanisms) that might override a user's policies.

<snip>
> I can see a clear case where an enterprise/government
> provider does NOT want devices providing too precise a
> location, and having a set policy to configure all
> Target and Location Servers to this mandatory maximum
> precision.

I do not really understand the case. Is this "set policy to
configure all Target and Location Servers to this mandatory
maximum precision" a user policy? And an enterprise, where
this user happens to be, does not want the user to send the
information that he is there? Or is the device a fixed
device, and the enterprise does not want to disclose its
exact position?  But how does the user have the rights to
write the privacy polices in that case?

> > > 5.

Do you suggest adding some text here?

> > > 6. <snip>
> Privacy yes, but the amount of privacy could change (be
> more or less) based on the amount of LI given. This is
> the foundation for the Resolution Fields; in other
> words, if device X gives location precision that is down
> to the millimeter, that Geopriv message should be
> considered for higher privacy controls than if device X
> merely gave the location precision of 1/6th that of the
> Earth (for where it is). Then there might not be very
> much (or no) privacy controls.

In both cases there is privacy control.  And it is exactly
the same privacy control check, base on exactly the same
policy rule. In one case the privacy compliance check may
say ok in the other it may say not ok.

> I believe this varying in precision should directly
> affect the level of privacy applied to an LO for any
> device.

The whole issue seems to me to be a confusion of terms.

I see a misunderstanding here (and this is reflected later
too): We do not think of privacy rules in terms of "a
varying level of privacy depending on the precision of the
data".

Rather, we think of rules as saying: "my location can only
be disclosed to the owner of such credentials and in such
accuracy".

*One* policy rule tells to whom which information may be
sent in which resolution.

Could some text help clarify this confusion? Suggestion?

> > > 7. From Conventions section:
<snip>
> > No, the document does not cover "all that is
> > mandatory" to implement.  There are still many points
> > open.  What the document want is to clarify what are
> > the privacy requirement, so that we can make further
> > progress with other parts of the specification.

> The text should be modified to state

Can you provide a suggested text and a place to insert it?

> > > 8. From section 3.1.1. Location Information (LI) and
> > >    Sighting:

> > You are right: the possibility of a configuration
> > protocol sending the Location Information to the
> > Target at boot time (or some other time) should be
> > included, of course.

> Thank you

Suggested text?

> > But how this information was entered into the system
> > is still out of scope for us.

> agreed

> > > Is one of the requirements of LI to state in which
> > > way the LI was determined? It seems to have been
> > > written this way.

> > No. We will add a remark.
I suggest to replace in 3.3.1:

"Location Information (LI):
  A relatively specific way of describing where a Device is
  located and that is (a) derived or computed from
  information generally not available to the general public
  (such as information mainly available to a network or
  service provider), (b) determined by a Device that may be
  not generally publicly addressable or accessible, or (c)
  input or otherwise provided by a Target."

by:
"Location Information (LI):
  A relatively specific way of describing where a Device is
  located.

This LI may have been determined in many different ways,
for instance (a)"...etc.

> > Also the emphasis on private information is misleading
> > at this point (Location Information may be as you have
> > said, public).

> > > And if we don't care (due to it being out of scope
> > > for us to manage or authenticate), we should refer
> > > to it other than the transport of it. This
> > > transportation could be in raw form, as such a
> > > Geopriv aware device is needed to generate the LI in
> > > a Geopriv format (which should be referenced).

> > I am not sure I understand...

> I'm referring to the transmission of non-IP or
> non-Geopriv information elements that can be gathered by
> a Geopriv aware device. This Geopriv aware device is the
> first device this WG should have scope over (and define
> 'stuff' regarding it).

Text?

> > > 9. <snip>

> I would prefer to call this "generation".

> Location Generation: The gathering of Location
> Information, perhaps from multiple sources, at an
> IP-based server which communicates with other Geopriv
> Entities (or Geopriv devices or something along these
> lines)

Since Jon proposed, along those lines:

"Location Generator: The LG is an element responsible for
 creating the Location Object. LGs publish Location
 Objects to Location Servers. The manner in which the
 Location Generator learns of Location Information is
 outside the scope of the geopriv protocol."

We could simply add:

"Thus Location Generation is the process of gathering
Location Information, perhaps from multiple sources, at an
IP-based Geopriv Entity, the LG, which communicates with
other Geopriv Entities."

> > > 10.
> It's an issue of perspective. Accuracy is a perspective
> from the Target outward (i.e. I'm X number of
> measurement units[feet, meters, miles, etc] from this
> point Y. This places a burden on the Target to know how
> to make this Location Information less granular.

> Definitions:

> Accuracy: The ability of a measurement to match the
> actual value of the quantity being measured
>          This states that the measurement could be
> incorrect, which should be a flaw in our choice of its
> use.

> Resolution: The fineness of detail that can be
> distinguished in measured area.  Geopriv applied: The
> fineness of area within provided, and closed, borders
> (ex. Latitude and Longitude boundaries)

> Precision:<snip> 3. The number of significant
> digits to which a value has been reliably measured.

> Geopriv should give a truthful reply to Location
> requests with the use of both Resolution and
> Precision. We SHALL state the defined borders a Target
> is within, yet the Target SHOULD control the precision
> (or exactness) of how large an area is provided in that
> reply.

Suggested text?

> > > 11. Why
> > > would LI be optional?

Why not?

> I am still somewhat confused and might be missing
> something. Are you stating that the LO should be utilized
> for a Location Request?

No. "Nothing is said.."  We do not know how loc reqs will
be sent.

> This seems to my to be unnecessary. Should Geopriv merely
> define separate packet formats for "Location Request" for
> when a device wants the location of a Geopriv Target?

> In this same vein, there needs to be something to satisfy
> one of John Morris's suggestions - that is to have a
> packet format to "notify" a Target (if it's Geopriv
> aware) that it's Location has been requested (to keep the
> Target in the loop, so to speak). This "Notify" message
> doesn't need a LO within it, especially since there
> should be a Security Association between the Location
> Server and the Target already in place.

"LO" is the generic geopriv object, that should be used
also for notifications (if they are geopriv messages).
This is another possible use of LO without LI.

> I believe we will end up with several message formats
> that don't require the LO be present. Including the LO in
> these packets will make the overall message long,
> cumbersome, and contain not-necessary information (which
> we should avoid, IMO).

Which messages without LO? Some other sort of Geopriv
messages?  Our basic assumption up to now is that we have
only LOs, nothing else.

> > > This section is a further reminder of how little is
> > > defined in the LI section (3.1.1) about LI and what
> > > fields are mandatory (apparently none), and which are
> > > optional, or even which are available to chose from
> > > (other than a time field - but is that time field the
> > > time when the Target was last queried for its
> > > location, or when the storing Server received the
> > > location, or when the Server responded to the
> > > Location Request?). Section 9.5 mentions that this
> > > time field doesn't have a default format.

> > Not yet, this will be important, of course, but we
> > wanted to concentrate on the privacy stuff.

> This, too, suggests that there ought to be a separate LI
> Reqs ID for pointed, open discussion on what should be in
> this LI portion of the LO.

The hope is to clarify those questions when defining the LO
itself.  In the charter, the expectation was that formats,
etc. is not the source of discussion, but rather the
privacy reqs.

> > > Somewhere, some device knows exactly where a Target
> > > is. What isn't stated explicitly in this ID is that
> > > from that precise and complete LI field group, policy
> > > can and will make the Target's location reply less
> > > precise - perhaps (and likely) based on who asked for
> > > the information.

I think this is said in the text, but can you provide another
perhaps more explicit suggested text and a place to insert it?

(See for instance: Filtered Location Information:
Then the Location Server sends the location information to
the Location Recipient.  The information may be filtered in
the sense that in general a less precise or a computed
version of the information is being delivered.
+
Location Server rules for receiving, filtering and
distributing Location Objects)

> > > There should be cases where maximum
> > > resolution is provided (emergencies or just by policy
> > > configuration for certain requesters). This isn't
> > > mentioned as being available.

> > A particular case of filtering is using no filter, or a
> > particular case of sending "in general a less precise
> > or a computed version of the information is being
> > delivered" is sending full resolution.

Suggested text and a place to insert it?

> > > There is also no mention of the ability for the
> > > Location Seeker (another hard term to use) to request
> > > an optional field be returned to it. For instance, if
> > > distance and vector are optional LI fields, is the
> > > Target the

> > > sole decision maker that it will include this
> > > information in the Location Reply? What if the
> > > Location Seeker doesn't want this information? This
> > > has

> > > a direct impact on the size of the Geopriv message
> > > (which is later stated in the ID to be a concern).

> > This is a difficult question. But we have not decided
> > yet, how location requests will really look like.
> > Perhaps it is at least partly a matter of the "using
> > protocol".

> I believe we should make it a requirement that there be
> some form of negotiation capability within the Geopriv
> Location Request message. Within this LRQ message, the
> Location Seeker could include which LI fields it wants
> returned to it (of course, other than those that are
> deemed mandatory - if this occurs).

The terminology today is that there is no extra
LRQ message, but that the LO is used there too.

Explicit negotiation was in the first versions of the
draft, but was rejected.

> Maybe I'm thinking down the road about having these
> multiple packet formats too much within my questions when
> I refer to asking why LI would be optional. If there is
> only ever one Geopriv packet format, the LI will be
> optional. I'd like to hope that we create a few packet
> formats/messages (Location Request, Location Reply,
> Location Reject, Notify, Location Update, etc)

May be, but all are one LO subformats.
Can we leave this for later?

> > > 12. From 3.1.3. Location Object vs. Using Protocol:

> > >    "The "using protocol" is the protocol that uses
> > >    (creates, reads or modifies) the Location Object.
> > >    A protocol that just transports the LO as a string
> > >    of bits, without looking at them (like an IP
> > >    storage protocol could do), is not a using
> > >    protocol, but only a transport protocol."

> > > This shouldn't be the definition of a using
> > > vs. transport protocol.  "...without looking at
> > > them..." is an unusual phrase in defining a
> > > protocol's usage. Shouldn't this be defined as
> > > "transporting unmodified" (the LI/LO) is a
> > > transportation protocol.

> > No, or classification is not base on only modifying the
> > LO, but on reading it, or "using" it.  If you read the
> > LO to get the identity of someone or whatever, you are
> > using the geopriv object.

> OK. I believe the text should explain this more so as to
> relieve potential confusion in the future. I have a
> feeling the Distinction of a Using Protocol vs. a
> Transport Protocol will become a bigger "thing" as LI
> starts getting incorporated into other
> Protocols. Defining it here more, will help this WG.

Can you provide a suggested text and a place to insert it?

> > > 13. Further from this section: 3.1.3.
> > >    "...Nevertheless, the entity or protocol that
> > >    caused the transport protocol to move the LO is
> > >    responsible for the correct distribution,
> > >    protection, usage, retention, and storage of the
> > >    LO."
> > > And, what is meant by the term "...correct..." in
> > this context. Is this not based uniformly on the
> > Policy and Security information contained within the
> > LO itself. If so, it should be stated here.

Can you provide a suggested text and a place to insert it?

> > It is base on the policies applicable to the LO, which
> > are given in the LO or referenced by it or were known
> > by other means by the entity or protocol that caused
> > the transport protocol to move the LO.  The point is: I
> > only send (if I am geopriv compliant) the LO to someone
> > who knows how to use it.  If he uses some low-level ip
> > storage transport protocol to move the object into some
> > SCSI ip device, he is still responsible for the data,
> > not the scsi ips protocol.

> OK

> > > 14. Further from this section: 3.1.3. Location Object
> vs. Using Protocol

> > > "...are of two types: First, the Location Object
> > > definition MUST include (optional) fields or
> > > mechanisms used to secure the LO as such.  The LO MAY
> > > be secured, for example, using cryptographic..."

> > > What is meant by "...MUST include (optional)
> fields..."?

> > The definition MUST include the fields.  The field
> > themselves are optional.

> I don't understand.

I am only talking about the *definition* of the object.

Let me give you one example: For instance RFC2459 defines
the fields of pki certificates. Now, one certificate may
perhaps not contain (use) all fields like Authority Key
Identifier.

Nevertheless RFC2459 defines such optional fields.

Our requirement just states that the document that defines
the LO MUST define a set of fields, which then may be
optional to use or not.

It is the same as saying that the definition of a
certificate MUST include the definition of the (optional)
field "Authority Key Identifier".

Is there a text that would resolve the confusion?

> If Geopriv were a binary protocol,
> this would make sense to keep the correct format of the
> packet or payload. Since Geopriv is Text-based, it will
> rely on Headers. Are you suggesting that all Headers
> possible be present even if the Header-Field is blank? 

No!

> I
> hope not. I hope that the Geopriv Protocol includes those
> LI Headers that have compliant values within their
> respective fields, and *not* include blank headers.  This
> is a waste of data that serves no purpose that I can see.

Exactly.  Nevertheless when you define the LO you have to
define which headers it may have.  Thus the *definition*
of the LO includes the fields, but the LO itself may
contain them or not.

Probably the wording is causing the confusion. Do you have
a suggestion?

> > > Fields are either optional, or mandatory, and so far
> > > in this document, no fields are mandatory; therefore
> > > nothing is a MUST.

Of course it is a MUST to define the fields, if they are 
mandatory or optional.

> > > 15. done, or do you wish some clarification text?

> > > 16. From 3.1.4. Trusted vs. Non-trusted Data Flows:

> > >    "The following terms distinguish between the two
> > >    basic types of data flows:

> > >        Trusted Data Flow: A data flow that is
> > >        governed by a pre-existing contractual
> > >        relationship that addresses location privacy.

> > >        Non-trusted Data Flow: The data flow is not
> > >        governed by a pre-existing contractual
> > >        relationship that addresses location privacy."

> > > This doesn't seem to cover the case of
> > > non-contracted, but Security Association configured
> > > "trusted" data flows. For example, not all >
> > > employees of the same company will necessarily have a
> > > contract in place when exchanging LI. Me and my wife
> > > might not either. Yet if the devices are configured
> > > to transfer LI between themselves in a secure manner
> > > (perhaps matching or exceeding Geopriv's minimums),
> > > that should be considered "trusted". PGP is an
> > > example of trusted data flows, yet there is no
> > > contract between parties that should not be expected
> > > between some Geopriv parties.

> > This whole world if trust is very subtle.  I could give
> > you more cases.  In this part of the document, the
> > authors want just to point out the case where there is
> > no pre-existing contractual relationship, which is more
> > problematic than the other one.  The case you mention
> > lies in between two extremes (the Non-trusted and the
> > trusted and secured one).

> I would still prefer there to be one piece of text (one
> sentence) stating something to the effect that two or
> more Geopriv aware endpoints can exchange LI if each
> trusts each other through some manual key/token exchange
> (like PGP or something similar).

Actually, in some cases, like for instance when the data is
publicly know, there is no need to have a security relation
to exchange LO.

> > > 17. done (?)

> > > 18. From 3.2.1. Primary Geopriv Entities:

> > > "Device" seem redundant and not necessary. Is it a
> > > Target? It seems as if "A Target" qualifies and
> > > fulfills the role of "A Device". The term/phrase "The
> > > Target" means a specific "Target" whose location is
> > > sought. Both are nouns (1st and 3rd person) and can
> > > easily be used either way - therefore reducing the
> > > number of terms used.

> > Yes, we have discussed this many times.  And I agree:
> > The term "Device" seem redundant and not necessary.
> > But if the target is for instance a person, then there
> > is some value of talking about how the location
> > information of one or several devices (which may be
> > lost or stolen or used by several people) are used as
> > "proxies" for the target.

> I agree that we've discussed this many times. I read the
> ID's text to state that a Target is the Geopriv Device
> ...

No, a target may be also a person or almost anything.
But a target may be a device.  And a target usually has one
or several devices.

> who's location is be sought after and that moment; and
> that any device *can* be a target (just not currently
> elevated to that level within this text).

Can you provide a suggested text and a place to insert it?

> > > 19. From 3.2.1. Primary Geopriv Entities:

> > >       "Rule Maker: The individual or entity that has
> > >       the authorization to set the applicable privacy
> > >       policies and rules."

> > > This definition explicitly states that there is "one"
> > > controller of rules or policies. A user should have
> > > control over their target(s), yet there could easily
> > > be a situation where a domain (perhaps a company's
> > > internal policy) might also have overriding control
> > > over part of the LI (perhaps overriding the maximum
> > > resolution a Target gives in a Location Request).

> > Actually I do agree.  But there has to be some proof
> > the user agrees too on that.

> I agree with your comment as well. This can be done
> within an employment or service contract, for example.

Should I include some additional text? Suggestion?

> > > 20. More from 3.2.1. Primary Geopriv Entities:

> > >     "Location Seeker (LSeek): An individual or entity
> > >     who seeks to receive location data about a
> > >     Target.

> > >     A Location Seeker may act in one or more of the
> > >     following more specialized roles: as the Location
> > >     Sighter, a Location Server, or as an Ultimate
> > >     Location Recipient:

> > >        Location Sighter (LoSi), or Location
> > >        Data-Source The original source of the
> > >        sighting of a Target in a given transaction.

> > > Location Server (LServ), or Intermediate Location
> > >  Recipient: "

> > > Seems like the acronyms are hard at best to remember.

> > > Seems like the Seeker can be a Ultimate Location
> > > Recipient. Why does this need 2 terms?

> > Because the seeker may pass this information further
> > (he may be also a Location Server)

> At that point, the Seeker is a Proxy (acting on behalf of
> other devices for Requests and Replies - it's still a
> Proxy). 

No, a seeker is not necessarily a proxy, even if passes
this information further.  For instance the seeker may
use this information to construct some accounting data
which includes location, and then pass this information to
a billing service.  This is not a proxy, is it?

I do not understand why the point is important anyway.

> We might define a Location Server to be able to
> act as a Proxy, then use the term as a verb and not a
> noun. I'd be OK with that, but interchanging causes
> confusion.

Interchanging what? For instance where?

Text suggestion?

> > It imitates a Client/Server type relationship - and
> > gives multiple names for the Client and Server. How
> > about a single name for each

> > > - while defining each can have multiple roles? This
> > is especially true when reading that there is another
> > term (Intermediate Location Recipient) possible.

> > We do not want to distinguish the entities or roles
> > from the point of view of one protocol run, but from
> > the point of view of privacy considerations and
> > requirements.  The ultimate location recipient has very
> > different needs than an Intermediate Location Recipient
> > form that point of view.

> I think that distinction should be made when the protocol
> is built, and left at a higher level (not defined as
> much) within the Reqs ID. So I guess I questioning the
> reason for defining a ULR this early

Because an ULR needs different policy information than
another recipient, which may pass this information further.

> > > 21. More from 3.2.1. Primary Geopriv Entities:

> > > "Ultimate Location Recipient (ULR): An individual or
> > > entity who receives location data about a Target and
> > > does not transmit the location information or
> > > information based on the Target's location (such as
> > > driving directions to or from the Target) to any
> > > party OTHER than the Target or the Rule Maker."

> > > Is the ULR (another hard acronym) still a ULR if the
> > > LI comes under the control of a Using Protocol? If
> > > so, this seems like a "Geopriv Location Seeker"
> > > endpoint (could be defined as one of its many
> > > roles); if not, Geopriv shouldn't define the ULR for
> > > another Protocol that optionally manipulates part of
> > > or all of the LO (including Policy and Security
> > > Information Fields and requirements).

> > The question is here not manipulating or using the LO,
> > but passing it further.

> But at that point, it's outside the scope of Geopriv. It
> might not even be IP at that point. I believe the ULR is
> the end of the line of Geopriv aware devices and we
> shouldn't necessarily go farther in definitions.

Even if it is not using IP, the ULR is not permitted to
pass this information any further.  This rule for the URL is
like a "copyright statement" if you wish. It says "this
data may not be disclosed further, in any form whatsoever."
We may not be able to enforce it, but we want to express
such a restriction.

> > > 22. done

> > > 23. <snip>
> > The IAP can also be a WLAN provider (not necessarily
> > the internet provider) or a corporate network, or
> > something else.

> Then any or all IP networks can be IAP. This seems like
> a hard group to define and I don't understand the
> purpose of this except for when lawyers get involved (no
> offense John).

Suggestion?

> > > How can a Network be a "Location Sighter"?

> > This text is misleading. The LoSi can be *part* of
> > that network or IAP.

> fair

Would this be sufficient: "Often, the IAP -- which will be
a wireless carrier, an Internet Service Provider, or an
internal corporate network -- will contain the LoSi."

> > > Cell Towers might be used to gather enough
> > > information to a collection server to generate LI
> > > worthy of insertion into a LO for a Target. A
> > > satellite system (GPS) could also be used for this
> > > operation. Neither is IP based, therefore shouldn't
> > > be defined here, but can be mentioned.

> > It is mentioned, because there are privacy concerns
> > here.

> I'm not sure how privacy concerns here are in scope of
> the IETF if they are not IP based

Oh yes, they are! We are defining, in IP, a language to
express the rules that govern the use of certain data, in
IP or not! It is like copyright.

> > > 24. From 3.2.3. Geopriv Data Storage Functions

> > >    "The existence and data storage practices of
> > >    Location Storage is crucial to privacy
> > >    considerations, because this may influence what
> > >    Location Information could eventually be revealed
> > >    (through later distribution, technical breach, or
> > >    legal processes)."

> > > This paragraph should necessitate a requirement for
> > > storage policy being included within the Policy
> > > Information of the LO for a Target.

> > Yes, I see something like "this data must be kept
> > secret (or even encrypted) as part of the policy. But
> > we have not reached consensus here. All those
> > questions have been moved to the "core-policies"
> > draft.

> Then maybe that ID should be referenced here?

I don't think that a draft in last call shall reference
a draft that is not supposed to become an rfc.

> > > 25. From 3.3. Privacy Policies and Rules

> > >    "..."my location can only be disclosed to the
> > >    owner of such credentials and in such
> > >    accuracy"..."

> > > This is a misuse of the word "accuracy" and its
> > > meaning. Resolution and (more likely only) precision
> > > are the coupled meanings that should be here in the
> > > quote.

> > Fine.

> Thanks

When should we use resolution and when precision (text
suggestions?)

> > > 26. From 3.4. Identifiers, Authentication and
> > >     Authorization

> > >     "...Unlinkability ...

> > Depending on the context, sometimes I want pure
> > unlinkability (Say: "there is one customer on the line
> > A", or "there are 27 vehicles on this part of the
> > road") without that any identifiable information is
> > disclosed.  In other cases I want that some people may
> > have the information linked, other not.  For instance
> > if I ask twice where you are, I may link the 2 pieces
> > of information. But perhaps the system is generating 2
> > unlinkable requests ("where is xyz001" and "where is
> > abc789") and a privacy friendly technology is able to
> > resolve the queries correctly.

> > > If you don't know that it is me requesting your
> > > location, because of this unlinkability, then how
> > > would you bind a rule or policy to my pseudonym
> > > and grant me the ability you would have given me
> > > (had you known it was me asking)?

I would say: the person who presents a token of this or
that type is allowed to obtain my location.  Much of the
business of privacy is how to do access control without
identification.   See for instance www.ra-pid.org, look for
identity management and PETs in infrastructures (section
on authorization privacy).

> > Of course it must be known that the requestor is
> > authorized, but this in not done via identification.

In other words: privacy-friendly access control operates
even when interacting parties decide to remain anonymous or
to disclose only specific attributes about themselves.

> But identification is how you create your rules that
> allow certain people (or devices certain people own) to
> get/receive more precise - or any - information in the
> first place. I currently don't see this being a
> requirement we can fulfill without limited the ability
> of our devices to allow appropriate replies. This seems
> like a loop that can't be satisfied when coupling the
> two requirements.

Explicitly, which requirements?  All that we ask at the
end of the day is Req 12. and 13.

> > > 27. More from 3.4. Identifiers, Authentication and
> > >     Authorization

> > > "Authorization The act of determining if a
> > > particular right, such as access to some resource,
> > > can be granted to the presenter of a particular
> > > credential."

> > > This doesn't seem to allow for the concept of
> > > varying authorization,

> This seems binary to me (you have authorization or you
> don't). And without authorization, your Location Request
> fails. Remember, we want to categorize Location Requests
> into levels of precision too. If authorization is
> binary, we can't. This is what I mean by varying levels.

Is this the discussion in Question #6?

Is there something you want to see as text?

> Or do you believe this is a multi-step process in which
> authorization determines that your request can be
> granted, then who you are determines what the reply will
> be?

No.  A privacy rule (=policy) says:  "my location can only
be disclosed to the owner of such credentials and in such
accuracy" (instead of accuracy read: precision or
resolution).

> But how do you determine who is who if pseudonyms are
> used?

For instance (although this is not the best solution, it is
easy to explain) you can give your friends a codeword to
access your location.
 
> > > 28. From 4. Scenarios and Explanatory Discussion

> > > There an example of GPS, of Cell Towers, and Mobile
> > > Communities and Location-Based Services. There is no
> > > mention of a wired scenario (such as Broadband Cable
> > > or DSL access, or Ethernet connectivity). This
> > > further makes this ID appear to be a mobile/Cellular
> > > centric ID. Geopriv should not be limited to
> > > wireless mind sets.

> > True.

> Thank you - can there be a small piece of text to this
> within the ID?

Sure! Can you provide the text and a place to insert it?

> > > Additionally, any GPS communications is logical and
> > > shouldn't be mentioned
> > > as a Geopriv scenario (there's no IP involved). Cell
> > > Towers aren't IP based, therefore they too aren't
> > > under Geopriv's charter.

> > > Once some Server that has gathered enough
> > > information about these cellular
> > > devices, that Server might use Geopriv to
> > > communicate to other Location Servers (this scenario
> > > could fall under Geopriv, or SOAP).

Suggested concrete changes?

> > > 29. From SCENARIO 3: Mobile Communities and
> > >     Location-Based Services

> > > "...including Data Types and Accuracy."

> > > This is the first mention of "Data Types". What are
> > > they? This is loosely referenced, but not defined in
> > > Requirement 2.6.

> > Civil vs. lat/long for instance. You may also think
> > that "country/state/city" is a different data type
> > than "country/state/city/street/number" (or that they
> > are 2 resolutions of the same data type).

> wow, that could get quite complicated once you add up
> all the potential variations of this.

Yes, this may not be viable.  I prefer to see
"country/state/city" and "country/state/city/street/number"
as 2 granularities (precision? resolution?) levels of the
same data type.  But it is not said in the reqs draft what
the data types will be.

> Henning and I did this exercise for his work office, and
> determined that he had (if memory serves) 11 Header
> fields involved just to get to him. That's a lot of
> unique Data Types to be registered when we get into the
> way various countries use postal or civil addressing

Is there anything you want to see that is missing or
anything that is there but you do not to see in the draft?

> > > 30. More From SCENARIO 3: Mobile Communities and
> > >     Location-Based Services

> > Registration is the process of making the contracts
> > with the ISPs or Mobile Carriers or geopriv service
> > providers.  At this point you, the user or rule maker,
> > have to show that you are entitled to "make the
> > policies" for this device under these or those
> > conditions, or using a particular password, etc.

> What about when a mobile device becomes mobile outside
> of its home domain network? The way you explain it
> above, it would lose contact with its core LSP and the
> IAP wouldn't recognize it. 

No, it will. (In general).  Like in Mobile-IP or gsm or
umts or many others, the visited nw will contact the home
network and ask for some kind of authorization and
authentication data.  The visited nw or isp will perform a
challenge response or another check and authenticate or
authorize the mobile device or user. This is usually not
referred to as registration.

> Shouldn't there be something
> like a roaming registration of cellular systems in our
> architecture? This would likely involve some form of
> registration with the new Service Provider, I would
> think.

AAA, not registration.

> > > Further, it would seem that the Target would be doing
> > > the Registration to a Location Service, and within
> > > that Registration would be a pointer to an existing
> > > Rule Maker (the Target and Rule Maker should be the
> > > owners of the policy for that Target) and an existing
> > > Rule Maker Policy Profile for that Target. The text
> > > here has this process turned around.

> > Say, the target is a car of an infant.  

Sorry. It should read: a car *or* an infant.

> > The owner of
> > the car or the parent of the child, the rule maker,
> > would be doing the Registration, not the target. I do
> > not think the text is reversed.

> Once that car or the infant crosses jurisdictional
> boundaries (county, province, state, country, etc) and
> leaves its home Location Service Provider's network, how
> does that car communicate via Geopriv in any direction?

As in mobile-ip or whatever.

> How does any Location Request get an appropriate
> response (remember - there would be no Sighter in this
> "other" jurisdiction)? The new LSP won't recognize it
> because there is no contract. It can't sent out a
> Location Update or determine where it is... nothing.

If there is no contract and no way of sending/information,
what has to do this with geopriv?  If there is, like in
mobile-ip, then the visited nw will recognize it and send
the information, say, to the home nw.  To know exactly what
to do the visited domain has probably to contact the
home nw to know who the rule maker is or where the policies
(rules) can be found.

Is there a change of test that you suggest?

> Say your cell phone is Geopriv compliant, and you have a
> contract with an LSP in your country. you travel to this
> country. Even though this country has a Geopriv Service
> Provider (I know, wishful thinking - just like cell
> coverage's "promise") you would lose contact until you
> returned home.

I don't see why.

> I don't believe we want Geopriv to be this limiting. We
> want there to be a solution for roaming (via some
> registration type process that perhaps checks the
> validity with your home domain and then chooses whether
> to honor it of not - under your policy/privacy rules)

Is this discussion only on our different uses of the word
registration?

> > > 31. From 5.1. Location Object

> > > "Req. 1.  (Location Object generalities)

> > >        1.1) Geopriv MUST define one Location Object
> > >        (LO) -- both in syntax and semantics -- that
> > >        must be supported by all geopriv entities.

> > >        1.2) Some fields of the Location Object MAY
> > >        be optional.  This means that an instance of
> > >        a Location Object MAY contain the fields or
> > >        not."

> > > Should be rewritten as follows (with new numbering
> > that's not included here):

> > >     1.1) Geopriv MUST define a 'mandatory to
> > > implement' set of Location Object fields to be
> > > understood by all Geopriv entities.

Notice that the Req 1 talks about LO, not about LO fields.
Perhaps your suggestion addresses instead Req 2 (2.5).  
But isn't what you are asking for exactly Req 3.1.?

If not, let me remind you that at some point we decided
that this draft would only concentrate on the privacy
aspects and leave decisions on formats, etc. for later.

> > Perhaps: "receivers". Senders-only do not have to
> > understands all.

> Fair correction. But shouldn't senders-only have to
> provide some mandatory to implement set of fields for
> interoperability reasons?

> > > 1.1a) Any Geopriv entity that transmits a maximum
> > > precision LO, provide a mandatory to implement
> > > minimum set of Location Information fields in that
> > > Location Reply (this should be similar to what is in
> > > the DHCP LO Option ID.

> This is for emergency cases - and I think we agree that
> this is a special case that requires a separate
> definition.

I still don't understand the requirement. I can not even
parse it properly. Should I read "provides" instead of
"provide"?  Is his meant to say MUST provide?  Which
"minimum set of Location Information fields"? How many
fields is this minimum set, or which ones, or when will
this be decided? May the set be empty? Which "that reply"?
If this is not a reply?

Is this requirement necessary now or is this part of the
decisions on formats, LO fields, etc, that we want to
concentrate on later?

> > >     1.1b) A Location Sighter (term needs to change
> > > to Generator) MUST include a mandatory minimum set
> > > of LI fields in its communication to the Location
> > > Server.

> > This seems to be requirements on a using protocol (or
> > in a very determined scenario).  I do not see why this
> > is needed.

> The Sighter or Generator doesn't have policy contained
> within it, so it should be mandatory to have that device
> send the complete, most precise LI for all potential
> Geopriv Targets it is the Sighter for. The LS then
> applies the Policy to all inbound requests.

I understand this requirement, but I do not see why this
is a MUST.  Suppose the generator contacts the LS and
ask him which LI granularity he wants, and thereafter only
sends this required information.

> > > 1.2) Some fields within the Location Object MAY be
> > present, or MAY not.

> > >     1.2a) All Geopriv entities MUST not fail a
> > > transaction if one or more fields are not present,
> > > or not understood, if the Geopriv message is
> > > acceptable under the Policy and Security rules for
> > > that Target.

> > I don't understand the requirement.  But if the
> > Geopriv message is not acceptable under the Policy and
> > Security rules for that Target, then it should not use
> > it.

> I'm stating the opposite, and agree with your comment
> (2nd sentence above).  

Opposite of what? agree with what? (I read something like
that you are claiming the opposite of what you agree with,
but this can not be the case).

> If a Location Seeker doesn't
> understand a particular field 

Including policy rules?

> that is included within
> the reply, it shouldn't fail the transaction. If a
> Location Server doesn't understand a Location field, it
> shouldn't fail the transaction.  This requirement is for
> the cases of extensibility when one side of the Geopriv
> process in any direction provides more information than
> the receiver understands.

Suggested text?
Is this a requirement in the scope of the draft as stated
in #3?

> > > 32. From Requirement 2.5 Location Field.

> > >    "Each Location Field may contain one or more
> > >    Location Representations, which can be also in
> > >    different formats."

> > > This text seems to indicate the necessity of another
> > > ID defining all the potential Location Information
> > > Fields (to ensure interoperability). Why was
> > > this left so open?

Suggestion for our draft?

> > > 33. From Requirement 2.7 Motion and direction
> > >     vectors

> > > This text should be under Req 2.5 - or this separate
> > ID defining the LO, or > at least the LI and its
> > mandatory and optional fields

> > > 34. From Requirement 3.2

> > >       "3.2) The Location Object SHOULD define two
> > >       Location Data Types: one for latitude /
> > >       longitude / altitude coordinates and one for
> > >       civil locations (City, Street, Number)
> > >       supported by all geopriv receivers (entities
> > >       that receive LOs)."

> > > Civil addressing isn't understood throughout the
> > > world (as in there isn't one way of expressing civil
> > > addresses). This should be an defined optional
> > > LI Field which should be included if the Location
> > > Seeker asks for it.

> > Yes.

> Ah, then you believe some notion of a Location Request
> containing the LI Fields it wants to receive? I think
> this is necessary, and we don't need much detail, but a
> little text should be added to this ID mentioning this
> (it is a FW ID as well).

I do not think this is necessary, but you are welcome to
suggest some text.  Also, perhaps the request does not
contain the LI fields it want to receive, but only
information on the data type and perhaps also on the
precision or resolution that it would expect.

> > > 35. From Requirement 3.3

> > >       "3.3) The latitude / longitude / altitude Data
> > >       Type SHOULD also support a delta format in
> > >       addition to an absolute one, used for the
> > >       purpose of reducing the size of the packages
> > >       or the security and confidentiality needs."

> > > In text format, as Geopriv is, this won't save any
> > > space in the Geopriv message - therefore this
> > > doesn't make much sense to be a requirement.

> > I do not think. Large numbers (even in text) require
> > more space than small numbers.

> OK... hmmmm

> How do you represent a ~10ft change in position over
> some interval of time, moving 287 degrees from True
> North - and have that number of headers added (much less
> the difference in total byte count) to the original
> reply equal less than just giving new Lat/Long/Alt?

Can you discuss this with Henning, who insists on having
the delta format?  I am also not sure that it really
reduces the packet size and that this kind of requirement
must be in this document (with focus on privacy), but when
I tried to eliminate the requirement he protested (seconded
by several others).

> This also places the burden of this change on the Target
> - which might support the Fields involved, but not
> support the processing power to keep up.

> I think this is a good idea that should fall under the
> "Optional LI Fields" area (meaning MAY not SHOULD).

For me, all fields are optional. But fields must be
standardized (=defined), to be understood.

> > > 36. From Requirement 3.4

> > >       "3.4) The Location Object definition SHOULD
> > >       agree on further Location Data Types supported
> > >       by some geopriv entities and defined by other
> > >       organizations."

> > > What is this requirement referring to? There are no
> > > examples, and nothing comes to mind that could
> > > explain this requirement.

The Req says that besides the required data types that all
geopriv receivers have to understand, a set of further data
types should be selected.  Probably the requirement on the
LO-draft will then look like: "following data types SHOULD
be supported by (this and this type of) geopriv entities".

In other words, besides the MUST data types (+formats),
some further ones should be selected and they should be 
recommended for use.

Text change?

> > > 37. From Requirement 5.2. The Using Protocol

> > >       "Req. 4.  The using protocol has to obey the
> > >       privacy and security instructions coded in the
> > >       Location Object and in the corresponding
> > >       Policy Rules regarding the transmission and
> > >       storage of the LO."

> > > This is written as a MUST, where other text in other
> > > parts of the ID state
> > > this is optional or preferred only;

> > No this is a MUST.  In other part it is said: there
> > are many ways of securing a LO.  We prefer the
> > LO-security itself, not just transporting the LO
> > securely.  This is like preferring IPsec to TLS or
> > preferring xml-security than securing SOAP with TLS.

Text suggestion?

> > > From 3.1.3:

> > >    "First, the Location Object definition MUST
> > >    include (optional) fields or mechanisms used to
> > >    secure the LO as such."

> > > And then:

> > >    "Second, the using protocol may also provide
> > >    security mechanisms to securely transport the
> > >    Location Object."

> > > And then:

> > >    "The security mechanisms of the Location Object
> > >    itself are to be preferred."

> > Yes.  The LO should offer LO-"intrinsic" security (if
> > it is xml then xml signatures, etc).  The using
> > protocol may take care to use further security (like
> > IPsec or TLS).  We prefer the "intrinsic" one.

> All of my question #37 was pointing out inconsistency in
> the text. I agree that it should be a MUST

I do not see the inconsistency: if the LO has privacy and
security instructions attached to it, they MUST be obeyed. No
question. For instance assume that it says this information
has to be kept confidential. Now, to secure this LO you can
use different techniques.  You may opt to construct a new
LO with this information encrypted or you may run the
protocol over TLS.  In both cases you are providing
confidentiality for this transmission.

Text suggestion?

> > > 38. From Requirement 15.3)

> > >    "The protocol SHOULD allow a bypass if
> > >    authentication fails in an emergency call.

> > >     The issue addressed in the last point is that an
> > >     emergency call in some very unfavorable
> > >     situations my not be completed if the minimal
> > >     authentication fails. "

> > > This requirement should be bound to a maximum
> > > precision of the LI fields within that LO
> > > transmitted during these emergency situations - but
> > > that text isn't present in this ID.

> > I am not sure what you mean "should be bound to a
> > maximum precision". The information must be sent in
> > full resolution, yes. There is no need for
> > authentication here.

> I believe the text should state "full resolution" (as
> you stated with your reply).

I agree, but I do not think that this requirement would be
in the scope of our draft.  I imagine that the type of
resolution required by emergency services is not for us to
decide, but by NENA or whoever.  Perhaps they request a
special format which is not "full resolution".  I would
rather leave this point open here.

> > > 39. done

> > > 40. From Emergency Case

> > >    "- "If the emergency server does not authenticate
> > >    itself, nevertheless send the location", or - "If
> > >    the emergency server does not authenticate
> > >    itself, let the call fail". "

> > > Although this seems like a good configuration plan,
> > > but doesn't solve the innocent bystander (a
> > > friend/colleague of the Target's owner) who might not
> > > want this configuration when they place the emergency
> > > call.

> > How would you solve the case?

> I think the default should be limited to "send the
> LI". If the user of the device changes the configuration
> to "MUST authenticate (even a emergency response center)
> or the call fails", then the innocent bystander has the
> owner of the device to direct any action (legal)
> towards, and not the device manufacturer - which is
> always an expensive uphill battle with a manufacturer's
> legal resources.

Text suggestion?

> > > 41. From 9.4. Truth Flag

> > >    "Geopriv should not provide an attribute in
> > >    object saying "I'm not telling you the whole
> > >    truth." "

> > > This should be a requirement in this document - as
> > > it would give away too much information to include
> > > it when the target is reducing the precision > > of
> > > their location purposely.

> > I do agree, but it has raised much debate. The problem
> > is: if you ask for resolution X and you get resolution
> > Y, is this because the server is not telling you the
> > whole truth?  If you send information in Lat/long,
> > should it be evident which resolution you are sending?
> > This is for later consideration.

> That's why I brought it up here on the list, to have
> more discussion about it.

Fine. Any suggestion for our draft?

> > > 42. done

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Feb 2003 23:20:37 -0600

>LocServer would like further details.

Couldn't this be accomplished with a NOTIFY message pertaining to the 
Target Identifier, and not an LO. I guess I'm just not understanding the 
multi-use of an LO. If an LO is the combination of LI, PI and SI elements, 
how are any of these used by that AP in France to inform the LS in your 
example above? At this point, I'm starting to believe I'm a little slow on 
the uptake here.

>that all LO MUST have a Location field.

I'm still stuck on the concept that the LO is about LI with accompanying 
privacy information that's relative in parameters/strength to how precise 
the LI is.

>requirements on the LO format or the geopriv transactions.

I just wanted clarity here, and you answered my question.

>Otherwise, this would delay our draft indefinitely.

I don't want that

>write the privacy polices in that case?

This is a case where the user has certain right to set the policy of the 
target, as does the domain the device is in. For example, there are certain 
countries in the world that don't want GPS location information derived to 
within a certain precision. If that maximum precision is 1000 ft x 1000 ft 
square, this might violate the 100 ft x 100 ft square precision the user 
sets for their device. Who wins here? Likely the jurisdictional authority 
by the threat of jail time for the owner of the location device.

As such, Geopriv could become a quite accurate mapping mechanism for other 
people's or corporations or organization's property lines (and structures 
with those property lines. If the corporation or organization is the Access 
provider as well, they should be able to set artificial limits on the 
precision measurable (thus conveyable by Geopriv Targets). This would be 
part of the contract the user has with the service or access provider.

Just like laws in most countries, if you're on someone else's land, they 
have certain rights that you have to obey.

>say ok in the other it may say not ok.

Oh... so this is a binary choice and not multi-leveled? I thought we would 
have a situation where there was something like a template for users to 
generally adhere to (by their choice), of basic categories of how to 
fashion a response to a Location Request. Something like:

1. fail the request
2. pass the request, give which hemisphere you are in
3. pass the request, give the timezone you're in
4. pass the request, give the country/province you're in
5. pass the request, give the province/state you're in
6. pass the request, give the city you're in
7. pass the request, give the city quadrant you're in
8. pass the request, give the street you're on
9. pass the request, give the street address you're at
10. pass the request, give the floor of the building you're on
11. pass the request, give the office/cube # you're in

This list is a generic template, and a user moves people (Location 
Requesters) in and out of each category. A more complex situation or end 
device might have time of day adjustment of what type of reply they get to 
an authorized query.

Obviously this is a 'civil' template example, but it is the easiest to 
visualize.

In this template example of categories, it isn't just a case of a location 
reply being authorized or not, it's who was authorized, what time they were 
authorized - and based on a rules engine on the Location Server for that 
Target, a the appropriate reply is generated.

>The whole issue seems to me to be a confusion of terms.

Maybe my example above explains where I was thinking this was going (I hope)

>sent in which resolution.

This might make for a whole bunch of a long list of rules. I like to look 
at this from a time of date routing perspective from IP Telephony. I'll 
wait for your (and other feedback) on this template category proposal I've 
suggested above before going further.

>Can you provide a suggested text and a place to insert it?

yes

> > > Target at boot time (or some other time) should be

I'll get this to you as well

>This LI may have been determined in many different ways,

very good

> > first device this WG should have scope over (and define

I'll work with you on this too

>IP-based Geopriv Entity, the LG, which communicates with

I like it

> > (or exactness) of how large an area is provided in that

Tell me where you want it in the ID and I'll frame the above paragraph to 
suit that section

>Why not?

This is rooting in our general disagreement in how the LO is used. If the 
PI and SI is all relative to the LI, then the absence of LI should negate 
the use of the LO. All other messages should be of another form and not use 
and LO to transmit or request information (like UPDATE and NOTIFY messages 
would intuitively accomplish)

OK

>This is another possible use of LO without LI.

Why would a Notify message described above need the PI and SI of a target?

I'm having a hard time not believing you consider an LO to be a generic 
term for any and all Geopriv messages... I must be misunderstanding 
something still

>messages?  Our basic assumption up to now is that we have

Yeah, this is one of my core questions, "about these other types of 
messages"? I understand and advocate any Geopriv message that includes LI 
must have the other elements (PI and SI) of the LO. So LI or PI or SI are 
subset of the LO. I'm racking my brain about the Notify being a subset of 
the LO as well.

But you answered one of my confusions with your answer above - I now 
understand that where I believe that there are only 3 pieces that make up 
the LO, you consider everything Geopriv to be an LO. I can't say which one 
of us is right, I just understand what the difference is now.

>distributing Location Objects)

I don't remember your use of the word "filter" as you have it above. If 
this is properly defined as to its direct impact or effect on the precision 
given, then this is either something I missed, or is a good improvement of 
what I remember reading.

>Suggested text and a place to insert it?

I need to re-read this area of the ID to make sure I didn't miss a concept 
you were trying to convey before I suggest a rewrite. Fair?

>Explicit negotiation was in the first versions of the

hmmmm..... I think I remember something about this, but I think the group 
wasn't talking about this exact mechanism. I believe we must reopen this 
capability to accomplish what we'll have asked of us. I can wait for other 
comments regarding this. I might pose an individual question to the list 
about this one, framing it to suggest alternatives for how we solve 
requesting optional LI fields be returned.

>Can we leave this for later?

I just hope the train isn't heading down the tracks without any brakes on 
this one

>Can you provide a suggested text and a place to insert it?

yes, I'll work on it as well

>Can you provide a suggested text and a place to insert it?

yes, and I think this paragraph (if it stays) is where there just needs to 
be a slight reword, not a major overhaul.

>Is there a text that would resolve the confusion?

I can now live with what you wrote

>of the LO includes the fields, but the LO itself may

This is similar to how we two look at this whole effort. I understand that 
the LO will have to have all of its fields defined, yet not have to include 
most of them in any one message. I just don't use the term LO as 
generically as you.

>Of course it is a MUST to define the fields, if they are

see above

>publicly know, there is no need to have a security relation

but once the SA is up and running, then all private into can be exchanged 
without regard to any other constraints. This is what I was looking for.

>But a target may be a device.  And a target usually has one

Ok, so you're taking the opposite definition of inheritance that I have, 
I'll bow to your definition if you put text in the ID stating a Target can 
be a person (or something non-IP based, or even non-electronic)

>Can you provide a suggested text and a place to insert it?

see above

>Should I include some additional text? Suggestion?

This might revolve around who is able to set the rules/policies for a 
Target (or device). If it is a combination of the owner of a device and the 
Access Provider, then there are two controllers. I think the text should 
state something to this affect and that there are jurisdictional issues 
that might force what a owner of a Device to adjust the precision of LI to 
be more exact or less exact, depending on local circumstances

>a billing service.  This is not a proxy, is it?

Extraction to a third party application.... you got me there, I think. I relent

>Interchanging what? For instance where?

I have to refocus this issue before making further suggestions

>another recipient, which may pass this information further.

Why can't the ULR just disregard what doesn't pertain to it in this 
instance (which will always be a superset of what it receives)?

>We may not be able to enforce it, but we want to express

I think it's out of scope once it leaves the IP world, but will relent if 
you want it that much

> > purpose of this except for when lawyers get involved (no

You used the term Access Provider earlier in this email - and I think this 
term fits what you intend, and is fairly easy to understand and remember. 
Maybe just a switch out?

>internal corporate network -- will contain the LoSi."

better

>IP or not! It is like copyright.

Written like a lawyer..... ha ha.

I guess I don't have a problem with this explanation if used to explain the 
location gathering methods

>a draft that is not supposed to become an rfc.

oh... you're right - but it does explain the situation that this ID won't 
unless something is referenced or included...

>When should we use resolution and when precision (text

The usages are subtly different and sometimes interchangeable (unfortunately).

Precise (is an adjective)
how precise something is

Precision ( is a noun)
level of precision

Resolution (is a noun)
Use Resolution when referring to boundaries (like Lat or Long)
Use resolution when referring to the topic

Resolve (is a verb)
To resolve to a certain degree

Key:
         Precision and Resolution can be interchanged, but
         Precise and Resolve are independent words

>that type is allowed to obtain my location.

But this would mean that I would have to identify myself to your 
authenticator/authorizer in order to obtain the appropriate token... I 
think this would compromise my anonymity in ways that is inconsistent with 
our goals - yet I don't have a solution ( this topic gets my noodle all 
wrapped up)

>Much of the

what you said

Now how do we accomplish this without you or I reveling ourselves in the 
packets, yet knowing each is who we say we are in people time?

>Is this the discussion in Question #6?

Question #5

>Is there something you want to see as text?

I think we need to agree on the concept before we get to adding or 
different text

>easy to explain) you can give your friends a codeword to

But my friends will know it's from me because I gave it to them out of band 
(from Geopriv). You are putting the burden on me to distribute my 
codeword(s) to all who can ask for my location. Since they have to have it 
in order for Geopriv to work at all, this codeword distribution must be 
done some other way. I have a belief that this makes the process less efficient

I want to put the type of person (wife, son, boss, co-worker, friend, etc 
as URIs) into and out of categories in a user friendly template that has 
established rules/policies, then adjust from there the specifics. Let these 
people authenticate to some service I trust, and their URI in the request 
will determine the type of response they receive. This puts the burden on 
them just like I have to learn your email address in order to email you, or 
your phone number in order to call you. But I can always input or push that 
trust up to my provider to state that I will trust a request from this or 
these URIs (perhaps to only some lesser degree that usual, but much more 
than a failure)

>Sure! Can you provide the text and a place to insert it?

By this point in the email, I knew you were going to ask for it. I'll get 
it to you soon.

>Suggested concrete changes?

I've already caved into these being viable examples that should be pointed 
out for clarity

>same data type.  But it is not said in the reqs draft what

Why not one for civil, and one for coordinate - and let the amount of trust 
determine how much.... oh yeah, you like the binary implementation. 
hmmmm..... here in one area that your "does he or doesn't he qualify" is 
gonna get you in terms of defining these Data Types.

>anything that is there but you do not to see in the draft?

It's an apparent difference in applicability, you like binary and I prefer 
varied

At least we both should understand more about what the other is referring 
to when communicating points of view  ;-)

>authentication data.

based on what message? The target doesn't generate anything except a 
response. If the Target is now in another Access Provider's network 
(coverage), there is no pinging like there is in gsm or utms, there's no 
broadcast saying "here I am, track me over here now".

>The visited nw or isp will perform a
>authorize the mobile device or user.

How will AP 2 know the Target one left its home domain? Does the home 
domain track the target's motions until it realizes the target is leaving 
it's area of control into another (known) AP and then contact that AP on 
some control channel to start tracking this Target?

I think you'll have a failure to communicate because of this lack of broadcast

If this is to be in addition to or take advantage of cellular 
communications such as 3GPP, the Geopriv client(device) software needs to 
know in its code to periodically announce itself like a gsm device does. 
The movement from AP zones will not be graceful always (like getting off a 
plane in another country and being turned on).

>This is usually not

No, but it is a form of broadcast beckoning that Geopriv Targets/devices 
likely don't have in mind currently. Or can you point me to the text 
hinting at this requirement for all implementations?

> > registration with the new Service Provider, I would

I'm using the wrong word here (registration) - and I sit corrected. But you 
need to solve the active outbound beckoning issue for Targets for me then 
(as mentioned above)....

>Sorry. It should read: a car *or* an infant.

that was a joke... ;-)

>As in mobile-ip or whatever.

here I'm getting back to the issue of a broadcast capability that this Reqs 
ID doesn't have that I'm seeing (until someone points this out where I've 
missed).

>mobile-ip, then the visited nw will recognize it

in Geopriv code?

>and send

Once this visited nw becomes aware of the target, what you state above is 
appropriate

> > coverage's "promise") you would lose contact until you

Read my questions above to understand my confusion about this lack of 
broadcast functionality in Geopriv devices or Servers

>Is this discussion only on our different uses of the word

see above, we can explore this further if you still don't understand my 
position (figuratively), or a proposed solution if you realize something is 
indeed missing that I've discovered.

>If not, let me remind you

... oh, I've had that read into my brain this evening going through this 
email....

>that at some point we decided

I'll push this one out for the moment

>is a MUST.

Because it should not be up to the Generator which fields to send - this 
should be exclusively where the policies are applied to determine how to 
manipulate any if not all fields from their respective maximum 
levels/values/whatever.

>  Suppose the generator contacts the LS and

this is suggesting a PDP/PEP relationship - which is new ....

> > > Security rules for that Target, then it should not use

What I state is the opposite, if the message does pass the PI and SI, and 
is also missing one or more LI fields the Location Seeker wants, this 
shouldn't be a candidate for failure by the Seeker, the Seeker should 
accept the LO as is. Lacking one or more fields might be by choice of the 
Rule Maker for that Target's presentation of location

>but this can not be the case).

Fair, I explained it more just above

> > understand a particular field

no, aside from Policy or Security rules only - we're talking about LI 
Fields only

>Is this a requirement in the scope of the draft as stated

#3 what? My Question #3? I don't understand here

>Suggestion for our draft?

none if another ID should be written...

But I think what you call "Location Representations" here is what you call 
"Data Types" elsewhere

>suggest some text.

This is the details of a "negotiation" you said we killed the idea of. Now 
I remember that discussion - and it was something to the of not wanting 
there to be too many round trips before deciding on the location answer. 
But I believe if we define a default set of LI fields that are appropriate 
for all Location Replies (meaning what's returned to the Location Seeker 
after passing policy and security rules) - then we can have the Seeker 
merely include in its Location Request the additional fields (that are 
defined somewhere) that it happens to want. Obviously the Rule maker is the 
decider of what is in the reply

>Also, perhaps the request does not

This is absolutely allowable in a request as I envision it

>I tried to eliminate the requirement he protested (seconded

I will talk to Henning about this. I think this was seconded by many 
because they want the capability - as do I - but I don't believe this 
should be part of the protocol, this is an implementation issue.

>standardized (=defined), to be understood.

All fields must be defined, there inclusion in a response is apparently up 
for debate

>some further ones should be selected and they should be

I just needed the explanation from above

> > > preferring xml-security than securing SOAP with TLS.

This is a MUST above, but if you look at the examples I've included, you 
have the words that pull back on that emphasis.

> > > >    include (optional) fields or mechanisms used to

This one I now understand and am not as adamant to change

>confidentiality for this transmission.

Maybe be firmer with the wording on the last 2 paragraphs I quoted above

>rather leave this point open here.

Then maybe place a open ended pointer to a future document on this known to 
exist topic (that could be for each country or generically for all 
countries - which I doubt could happen)

> > always an expensive uphill battle with a manufacturer's

I'll come up with it

>Fine. Any suggestion for our draft?

change "Geopriv should not provide an attribute..." to "Geopriv MUST NOT 
provide an attribute...."

fixed

> > > > 42. done

Well this took a few hours to go through.... ugh!

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"