Subject: [Ecrit] Re: [Geopriv] coming to terms on location by reference

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 08:27:40 -0400

On Oct 10, 2006, at 7:30 AM, Brian Rosen wrote:
> Well, actually, I want to request that there be an (optional) URI  
> returned
> with the response that could contain information about the  
> location.  This
> URI, which need not be specified, would be used by PSAPs and other
> responders to obtain additional information about the location with  
> the sos
> service.  If two calls queried for the same location, they would  
> get the
> same URI, which might be service dependent.
>
> You can imagine things like floor plans, lists of hazardous materials,
> available surveillance video, entrance information, etc for the sos
> services.
>
> There will probably be authentication, and authorization needed to  
> access
> this information.

We have name for this in the software industry.  It is called feature  
creep, and it is known to be one of the causes of project failure.

I'm not actually sure how this would even work, as LoST is queried by  
a call routing function and its contents are used for that.  Such a  
URI would have to be conveyed from the seeker to the PSAP, which is  
not a LoST issue.

We've provided extension points in LoST, so this can be added later  
once there is a lot more detail about what is wanted.

-andy

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 08:38:08 -0400

As I've stated before, we plan to use LoST within the Emergency Services IP
Network to route calls from ESRPs to PSAPs and from PSAPs to responders.
The URI would not be passed; the PSAP or responders would query for it.

It might be feature creep, but it is useful.  If the IETF doesn't do it, it
may be that NENA does an "embrace and extend", which would be unfortunate,
but possible, since we're only talking about features on servers within a
domain we control.  I'd rather not do this.

I certainly don't think we want to create ANOTHER database, with a different
protocol, to provide this function.  I think it may be very useful for non
sos services.  For example, an apartment building could post its delivery
policy (all deliveries by the side door).  The information is seen as coming
from the building owners/tenants; the URI would be a URI they provide,
pointing back to a data structure they maintain.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 8:28 AM
> To: Brian Rosen; [email-masked]
> Cc: 'Dawson, Martin'; 'GEOPRIV WG'
> Subject: Re: [Geopriv] coming to terms on location by reference
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Oct 2006 08:41:07 -0400

Brian,

I don't think this is necessary; there are already mechanisms in SIP  
where the caller can insert information about the call, the caller  
and the location, namely the Call-Info header.

Needless to say, this has nothing to do with LByR or LByV.

Henning

On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote:

>> responders to obtain additional information about the location  
>> with the sos
> We have name for this in the software industry.  It is called  
> feature creep, and it is known to be one of the causes of project  
> failure.
>
> I'm not actually sure how this would even work, as LoST is queried  
> by a call routing function and its contents are used for that.   
> Such a URI would have to be conveyed from the seeker to the PSAP,  
> which is not a LoST issue.
>
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 08:52:10 -0400

The caller doesn't have this data.  It's not information about the call or
the caller, its information about the location.

We plan to use Call-Info for information about the call and the caller.

This is different.  The caller doesn't necessarily have a relationship with
the location other than being an authorized visitor.  It would be pretty
messy to try to pass the information through the location mechanisms (LCP)
to the endpoint and then put it on the call except in an enterprise
environment, because the access network doesn't know it either.  Its
information a building owner or tenant knows.  I doubt it fits in the LCP
any better than LoST.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 8:41 AM
> To: Andrew Newton
> Cc: Brian Rosen; [email-masked]; 'GEOPRIV WG'; 'Dawson, Martin'

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 10 Oct 2006 09:06:45 -0400

Brian,

> 
> The caller doesn't have this data.  It's not information 
> about the call or the caller, its information about the location.
> 
> This is different.  The caller doesn't necessarily have a 
> relationship with the location other than being an authorized 
> visitor.  It would be pretty messy to try to pass the 
> information through the location mechanisms (LCP) to the 
> endpoint and then put it on the call except in an enterprise 
> environment, because the access network doesn't know it 
> either.  Its information a building owner or tenant knows.  I 
> doubt it fits in the LCP any better than LoST.

How does the building owner or tenant get the data into the LoST database?

The mess seems to be if the PSAP authorities 'open up' the LoST db for input
by any/all.

Pidf-lo might be the right place, 'for further info about this location goto
<uri>'.  If there is such information available from the building owner or
tenant, that would imply they would probably being running the LIS.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Oct 2006 09:13:39 -0400

I agree that the biggest problem is that this fundamentally changes  
the operations & management aspect of LoST, as well as the  
responsibility for the data content. (LoST operator: "You mean I have  
to check each URL to make sure it doesn't point to whitehouse.com  
instead of whitehouse.gov?")

I will note that RPID already contains information describing the  
location (placetype and others). It would not be difficult to define  
another DHCP-civic option, for example, for a location-related URL.  
This fits well within CIPID; it already has a <map> element.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 09:22:39 -0400

On Oct 10, 2006, at 8:52 AM, Brian Rosen wrote:

> This is different.

How can you possibly expect us to put it in LoST if we don't know  
what it is and it hasn't been described very well?

> I doubt it fits in the LCP
> any better than LoST.

Actually, there is the dhc-lost draft which has just now (or will  
become) an ECRIT work item.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 10 Oct 2006 09:29:35 -0400

My take on this is that it sounds like an operational nightmare. What
used to be a fairly simple system that just needed lots of location
info, and PSAP boundary and contact info, now has to have
logins/passwords for managers of every large building in a city. And
there will need to be a big support desk, for all these people to call
when they can't figure out how to input or update their info. And then
we'll need laws and regulations to force them to put the info in the
system (or it will never happen), and the laws will need to cover what
the minimum data set has to be. And we'll need to have a consistent
format for all the data, with XML labels for exits, circuit breakers,
fire extinguishers, escape ladders, etc., and common notation for how to
express their location inside a building; all the building managers will
need some tools to help them get all the data formatted correctly. My
head hurts just thinking of the bureaucracy that would be created to try
to get this done right. Not that bureaucracy tends to get things
right...
Barbara 

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 8:52 AM
> To: 'Henning Schulzrinne'; 'Andrew Newton'
> Cc: 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked]'
> Subject: RE: [Geopriv] coming to terms on location by reference
> 
> 
> about the call or
> relationship with

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:44:51 -0400

> How does the building owner or tenant get the data into the LoST database?
Basically, it probably comes through the PSAP or some other government
authority.  Since I expect the PSAP to contract operation of the LoST
database, it probably is another service that entity runs.  Eventually, I'd
like the "validation" mechanism to work for sub building levels (floor,
room, ...) and the path would be the same.  It's fairly straightforward to
validate it, using the post office and the fact that the owner, and even the
tenants are known to the authorities.

> The mess seems to be if the PSAP authorities 'open up' the LoST db for
It's just a URI.  It's not opening it up very much.

> tenant, that would imply they would probably being running the LIS.
You are just moving the problem.  I don't mind that too much, although I
didn't think we wanted to carry the data all the way through the path.  If
you put it in the PIDF, then the access network has to handle it.  That's
not too bad, although it falls apart when there is a tenant/building owner
situation.  The tenant is a subscriber of the access network, but the
building owner isn't.  

The real reason I don't want to do that is that it gives the access network
more obligations.  I don't want to go there.  We're going to have enough
trouble getting every access network to deploy a LIS and an LCP.  Adding
more work is counterproductive.  That's not a good protocol engineering
reason, but it's a pretty good reason nonetheless.

It seems to fit LoST: Location+Service in, URI out.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:51:57 -0400

No, it's just a URI.  The only mechanism you need is a way to supply the
URI.  You validate it with a post card.

The data format is another story, and outside the expertise of this group.
It will, I'm sure, evolve.  It can be a local matter: it's information about
a building that the PSAP and responders that serve that building agree is
useful.  

The other side of your argument is that we should not have the possibility
to provide this information, or, as they do now, the fire chief can carry a
box of paper floor plans in the trunk of his car.

We can do this another way, but it seems useful to have a mechanism that
works across the Internet.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 9:30 AM
> To: Brian Rosen; Henning Schulzrinne; Andrew Newton
> Cc: GEOPRIV WG; Dawson,Martin; [email-masked]
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA624

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:59:15 -0400

> what it is and it hasn't been described very well?
It's a URI.  The format and protocol can be defined locally, because the
location and the service (PSAP and Responders) are local to one another.
What works in the U.S. probably won't work in China.  The URI parameter
however is universal.  Every LoST server could support it.

> become) an ECRIT work item.
I like dhc-lost, but it's not, as you know, universally applicable.

It also requires that we have the endpoint fetch and pass it through the
call, although I don't consider that too much of a problem.  I'm more
worried that because dhcp is not universal, we need a variety of mechanisms
and endpoints would have to implement them all.  A parameter in the LoST
return is much simpler to me.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 10 Oct 2006 10:04:33 -0400

> > 
> > Pidf-lo might be the right place, 'for further info about 
> this location
> > goto
> You are just moving the problem. 

But I'm moving the problem to the owner of the data!

 I don't mind that too much, 
> although I

I don't understand this.  You are implying that a tenant that is large
enough to have extraneous information about their location (floor plans,
hazardous chemicals, etc.), but yet does not control (relies on someone
else) the operation their access network/LIS?  Makes no sense.  Even
residential *could* operate their own LIS, regardless of the access provider
(yes, reverse DNS LIS discovery would be broken, but it's a bad mechanism to
start with).
 
> It seems to fit LoST: Location+Service in, URI out.

I agree, the emerging LoST protocol appears to be a good fit for your
application.  Having Public Safety provide the service is where this falls
apart.

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 10:08:28 -0400

> however is universal.  Every LoST server could support it.

If it is not universal, how do you know a URI is applicable to all 
jurisdictions?  You seem to be treating a URI as a blob.  If it is a blob 
you want, LoST already has that in the form of an extension point... which 
can contain a URI or a base 64 encoded JPEG of your cat... or both.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 11:32:42 -0400

Roger Marshall just gave me a suggestion to fix this simply, no new feature
required.

Define a new service URN that returns this data.

Done.

That's all we need.

Brian

> Sent: Tuesday, October 10, 2006 9:59 AM
> To: 'Andrew Newton'
> Cc: 'GEOPRIV WG'; [email-masked]'
> Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 12:57:13 -0400

> Define a new service URN that returns this data.

Define a new service URN that returns the URI you want?  Is that the idea? 
Fancy that, using URNs for their originally envisioned purpose.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 13:20:13 -0400

Yeah, well, sorry.  I should have made that observation myself.  Thanks to
Roger for pointing out the obvious.

In a NENA call today it was observed that, really, in at least a large
enterprise environment, it would be best if it WAS in the PIDF.  In the
general case, it is hard to always assume the operator of the LIS has the
data, but in the case of the enterprise who runs a LIS, it does, and in that
case it is a whole lot easier to supply it in the PIDF than to get it put in
the LoST database.

That may mean it makes sense to allow the (same) URI in the PIDF.  I'm not
sure I like "both" as an answer here, but the cases are pretty different.

Brian

> Sent: Thursday, October 12, 2006 12:57 PM
> To: Brian Rosen
> Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by
> reference
> 
> Brian Rosen wrote:

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 14:16:02 -0400

> sure I like "both" as an answer here, but the cases are pretty different.

Perhaps my point was lost (no pun intended).  If it is a URI you want, then 
using a URN to get it involves only DNS, not PIDF nor LoST.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 14:30:58 -0400

No, you need a URI that is dependent on location.  Your query is location
in, URI out.  DNS does not do that.  LoST does.  Roger's idea was rather
than including an "additional information" URI in every LoST return, for
every service, that we define a new service URN for "additional
information".  You then submit a LoST query with the
urn:service:additional-location (or whatever) and your location, and the
return is a URI for additional information corresponding to that location.

Work this out.  The assumption is that, for example, there is a local
definition for what additional information is needed/wanted in NYC, and that
included floor plans.  When a query for, let's say, 1234 5th Street, New
York, NY was made with urn:service:additional-information, the response
would be a URI that could retrieve the data structure for 1234 5th Street,
which contained the floor plan.  Any (authorized) responder could get that
data by querying LoST given the location.

Brian

> Sent: Thursday, October 12, 2006 2:16 PM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 17:20:08 -0400

One practical suggestion is to include the URL information in the 
civic-lo-revision document and then later add a code point to the 
DHCP-civic registry.

I will note that having a single URL refer to possibly multiple 
semantically different objects seems to be somewhat at odds with HTTP 
conventions, where Accept is generally used to choose between renditions 
of the same logical document in different formats (such as an image in 
GIF or PNG). A floor plan and hazmat information, say, are not really 
the same logical document.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 17:37:03 -0400

> civic-lo-revision document and then later add a code point to the
Good idea
> the same logical document.
I was thinking that the local authorities would define a single data
structure that had tags for the different kinds if information they were
interested in.  Some of the tag values might be URLs themselves. 

The IETF is, of course, not the place to standardize that data structure, at
least not now.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 17:43:04 -0400

> The IETF is, of course, not the place to standardize that data structure, at

Sure - but we need to have some idea what constraints we impose on 
future solutions. For example, the approach you suggest means that all 
information has to be managed by a single source, at least at the 
pointer level. I happen to think that this is not unreasonable, but 
since the number of types of information is probably fairly small 
(handful), it would also be quite plausible to remove one layer of 
indirection.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 18:58:37 -0400

I think there are several dimensions.

One is tenant/building owner; some information is available from the tenant,
some from the building owner.  I was thinking that the base data structure
would be from the building owner.  He would have things like building floor
plans, construction, entrance, elevator, .... kinds of data.

He would then have a pointer for each tenant, which would be a data
structure provided by the tenant.  The tenant would have things like
interior floor plans, hazmat data.

The thing is, of course, that nearly everything in the tenant part could
apply to the building owner.

I think there are a very large number of potential items in the data
structure.  I'm not sure how many of them are small enough to put directly
in, vs needing an indirect mechanism.  Clearly floor plans are indirect.
Something like hazmat data may not be.  Elevator status may not be, but
remote elevator control probably is (and probably requires significantly
more authentication and authorization if it is provided at all).  The
availability, location, etc of surveillance video could be directly in the
structure, but you clearly would have an RTSP (or something like it) pointer
to the actual video.  There are probably hundreds of potential tags, and I
don't know how many are pointers.

Brian

> Sent: Thursday, October 12, 2006 5:43 PM
> To: Brian Rosen

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 18:37:46 -0500

This appears to have branched off onto a new topic, so I have taken the liberty of changing the subject.

I think that what you are describing is a good idea for a new service, but I don't think that designing on the fly is going to work.  I also don't think that it is necessary to lump this data in with a civic address.

I'd contend that what you are proposing is information _about_ the civic address, not a part of the address.

To pick on one aspect of your data, what distinguishes a floor plan that highlights where particular rooms are to a street directory that highlights where roads are, or a world map that includes country borders?  Yes, you can argue that there is a level beyond which you can start making assumptions, but that requires that you draw a line.

A better approach would be to define a service, just as Roger suggested.  Location + urn:service:map + LoST = Map.  You can add to this as much complexity as you like - delegation of responsibility for features, innumerable tags, scalable resolution, etc...

> Sent: Friday, 13 October 2006 8:59 AM
> To: 'Henning Schulzrinne'
> Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by
> reference
> 

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 20:00:40 -0400

Agree we aren't going to design it on the fly.

I don't think WE are going to design it.

At the moment, I really think that is a local matter, and it works as a
local matter without any loss of interoperability.

It is clearly information ABOUT the address.

It's not limited to civic address.

I don't think we need to draw lines.  While I can't think of a good reason
to, if you put in a civic location with just a city name, you might get back
a street map.  Again, a local matter, it seems to me.

One of the reasons why there is some sense to allowing the pointer in the
PIDF itself (and it DOES make sense to have a pointer for "additional
information about the location in this PIDF") is that, at least in large
enterprise, it can give you the right answer, because it comes from the
right entity (it is, after all, the enterprise that runs the LIS in this
case).  A more general case of a broadband carrier serving a high rise
apartment building doesn't work, but then the notion of it being in LoST
makes sense there.

Right now, without a lot to go on, I'm thinking I don't want to standardize
a whole bunch of service URNs, one per piece of data and query for them
individually.  I think I want one locally defined XML structure and a "gimme
all you got" query.  YMMV.

Later, when we have more experience in how this works, and how else we can
use it, we could think about creating some more services such as map.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 7:38 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: GEOPRIV WG; ECRIT
> Subject: [Geopriv][Ecrit] Map data for a civic address
> 
> I think that what you are describing is a good idea for a new service, but
> I don't think that designing on the fly is going to work.  I also don't
> think that it is necessary to lump this data in with a civic address.
> 
> To pick on one aspect of your data, what distinguishes a floor plan that
> highlights where particular rooms are to a street directory that
> highlights where roads are, or a world map that includes country borders?
> Yes, you can argue that there is a level beyond which you can start making
> assumptions, but that requires that you draw a line.
> 
> A better approach would be to define a service, just as Roger suggested.
> Location + urn:service:map + LoST = Map.  You can add to this as much
> complexity as you like - delegation of responsibility for features,
> innumerable tags, scalable resolution, etc...
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 20:13:26 -0400

The only real difference between a PIDF inclusion and a LoST lookup  
in this case seems to be one layer of indirection, with the attendant  
advantages and disadvantages.

One of the practical issues is that LoST is currently designed for  
public information; any layer of indirection has to deal with well- 
discussed problems of having the LoST server decide who gets access  
to the information.

And now we can replay our by-value or by-reference discussion, since  
we haven't had one in a day or two.

Btw, PIDF-LO already contains information _about_ the address, such  
as the placetype or, if you like, the business name.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 19:15:11 -0500

You need to be careful that you aren't mistaking a "can" for a "should".

In any case, assuming that the LIS provides this information; where does this belong?  I can see four options:

 - In the civic address: I've already given my reasons why I believe this is a bad idea.

 - In the Geopriv element (alongside <method>, <usage-rules> and so forth).

 - In the PIDF: I wonder if this could really be considered presence information.

 - In the acquisition protocol: Add an option in the protocol to request additional information and include the data as an adjunct.

Personally, I like the last one.

Cheers,
Martin

> Sent: Friday, 13 October 2006 10:01 AM
> To: Thomson, Martin; 'Henning Schulzrinne'
> Cc: 'GEOPRIV WG'; 'ECRIT'
> Subject: RE: [Geopriv][Ecrit] Map data for a civic address
> 
> > > to the actual video.  There are probably hundreds of potential tags,
> and
> > I
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 19:26:57 -0500

> as the placetype or, if you like, the business name.

Business names are often a very useful way of identifying a location - they are often far more prominently displayed than other labels, like street numbers.  Therefore, they have a direct use.

As for placetype... obviously you will disagree, but I don't think that they should have been included in the civic address encoding.

Cheers,
Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 20:39:15 -0400

> discussed problems of having the LoST server decide who gets access

Could we close this issue out?  

LoST is defined over TLS.

Could the following text be included in Security Considerations:

In some jurisdictions, not all of the information in the LoST server may be
appropriate for an arbitrary public client to obtain.  The LoST server MAY
make use of the identity of the requester implied in a TLS connection
establishment within which LoST queries and responses are sent and make an
authorization decision based on that identity.  This means that the response
of the server MAY depend on the identity of the requester.  The query itself
does not contain any explicit identifying information of the requestor.
Appropriate TLS privacy mechanisms SHOULD be used to protect the non-public
information when such an option is used.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 20:53:55 -0400

> information when such an option is used.

First, being designed over TLS does not mean anything about the  
information being non-public.  Second, we aren't just using TLS.   
We've been round and round on this.  Third, I think this is just a  
plain bad idea.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 13 Oct 2006 12:19:09 -0400

If this pointer is provided by the LIS, then all access providers who supply service to that building would have to have this. For example, if tenants in a high rise apartment building have a choice between cable access, DSL, city-wide mesh Wi-Fi, and satellite, all these providers would have to replicate this pointer in their LIS. So the building managers would have to know all the possible access mechanisms, how to get the pointer to these companies, etc.

Just a comment. It's definitely do-able. The list of possible access providers is still short.
Barbara

> Sent: Thursday, October 12, 2006 8:15 PM
> In any case, assuming that the LIS provides this information; 
> where does this belong?  I can see four options:
> 
>  - In the acquisition protocol: Add an option in the protocol 
> to request additional information and include the data as an adjunct.
> 
> > to, if you put in a civic location with just a city name, 
> you might get
> > back
> > individually.  I think I want one locally defined XML 
> structure and a
> > "gimme
> > > This appears to have branched off onto a new topic, so I 
> have taken the
> > > liberty of changing the subject.
> > >
> > > I think that what you are describing is a good idea for a 
> new service,
> > but
> > > I'd contend that what you are proposing is information 
> _about_ the civic
> > > address, not a part of the address.
> > >
> > > Yes, you can argue that there is a level beyond which you 
> can start
> > making
> > > > One is tenant/building owner; some information is 
> available from the
> > > > tenant,
> > > > would be from the building owner.  He would have things 
> like building
> > > > floor
> > > > The thing is, of course, that nearly everything in the 
> tenant part
> > could
> > > > structure.  I'm not sure how many of them are small 
> enough to put
> > > directly
> > > > Something like hazmat data may not be.  Elevator status 
> may not be,
> > but
> > > > availability, location, etc of surveillance video could 
> be directly in
> > > the
> > > > structure, but you clearly would have an RTSP (or 
> something like it)
> > > > pointer
> > > > > > The IETF is, of course, not the place to 
> standardize that data
> > > > > structure, at
> > > > > > least not now.
> > > > >
> > > > > future solutions. For example, the approach you 
> suggest means that
> > all

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Andrew Newton <[email-masked]>
Date: Fri, 13 Oct 2006 14:09:09 -0400

> Just a comment. It's definitely do-able. The list of possible access providers is still short.

Before this goes any further, it should be noted that this is outside the 
scope of both ECRIT and GEOPRIV.

-andy