Subject: Re: [Ecrit] Location Protocols in Phone BCP

From: <[email-masked]>
Date: Thu, 20 Nov 2008 08:48:23 +0200

I was requested to send my observations regarding this requirement:

  ED-21/INT-12 Devices MUST support all of: DHCP location options
   [RFC4776] and [RFC3825], HELD
   [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED].

I believe we should come up with a list of LCPs which are likely to be
supported in devices in a not so distant future. Since I have no seen or
heard about LLDP support yet, at least that should be replaced with what
is mostly used today (OMA SUPL) and the 802.11 mechanism, with the
condition that this MUST only be supported if there is a wifi interface
available on the device.

- Gabor

________________________________

From: ext Tschofenig, Hannes

Sent: Tuesday, November 18, 2008 12:49 PM
To: Bajko Gabor (Nokia-CIC/MtView); [email-masked]
Subject: Location Protocols in Phone BCP

Gabor, 

Could you please raise your question about location protocols in Phone
BCP mentioned at ESW5 in the ECRIT WG session again? 

Ciao
Hannes 

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Nov 2008 02:05:59 -0600

Hi Gabor,

The list of LCPs in the phone BCP is a must support list, and is access-type agnostic.
I am curious that you say that SUPL is a MUST support given that:
a) it requires a home network in order to operate
b) it simply doesn't work for DSL or Cable
c) it is questionable whether it is really deployable for WiFi networks

Can you perhaps describe how it fits into the general Internet model?

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Thu 11/20/2008 12:48 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Location Protocols in Phone BCP

I believe we should come up with a list of LCPs which are likely to be supported in devices in a not so distant future. Since I have no seen or heard about LLDP support yet, at least that should be replaced with what is mostly used today (OMA SUPL) and the 802.11 mechanism, with the condition that this MUST only be supported if there is a wifi interface available on the device.

- Gabor

Gabor, 

Could you please raise your question about location protocols in Phone BCP mentioned at ESW5 in the ECRIT WG session again? 

Ciao
Hannes 

------------------------------------------------------------------------------------------------
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: <[email-masked]>
Date: Thu, 20 Nov 2008 16:26:08 +0200

Hi,

Is the intent to list the LCPs which are access-type agnostic but not
supported anywhere, or instead have a list of LCPs which are highly
probable to produce the intended result?

There are restrictions everywhere, things come at a cost even in the
general Internet model. The reality is that most of the devices with
internet access have a home network already. 

- Gabor

  >From: ext Winterbottom, James [mailto:[email-masked]]
  >Sent: Thursday, November 20, 2008 12:06 AM
  >To: Bajko Gabor (Nokia-CIC/MtView); [email-masked]
  >Cc: [email-masked]; Tschofenig Hannes (NSN - FI/Espoo)
  >Subject: RE: [Ecrit] Location Protocols in Phone BCP
  >
  >Hi Gabor,
  >
  >The list of LCPs in the phone BCP is a must support list, and is
access-
  >type agnostic.
 
>-----------------------------------------------------------------------
--
  >-----------------------
 
>-----------------------------------------------------------------------
--
  >-----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 09:38:22 -0500

The problem with SUPL is that the majority of networks where SUPL would be
available have a proxy (E-CSCF) insert location.  It also has an
incompatible location representation, and an incompatible privacy model.
That makes it very hard to interwork with any of the rest of the IETF work.

I will say this.  For quite some time, the IETF has been trying to interest
OMA into cooperation on location so that we have interoperability at the
protocol, location representation and privacy levels.  So far, that has not
happened.  If, as part of a comprehensive agreement to accomplish such a
goal, SUPL became one of the LCPs, I would not object.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, November 20, 2008 9:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Location Protocols in Phone BCP

Hi,

- Gabor

access-
 
--
 
--

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 09:10:41 -0600

I think we need to pull up a level.  It's not reasonable for an RFC to 
try to list all of the location protocols out there, if for no other 
reason than that it will rapidly become obsolete.  Instead, we should 
say something like the following:

"
INT-12 Devices MUST support the DHCP location options [RFC4776] and 
[RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery].  Devices 
SHOULD support all location protocols supported at lower layers by their 
interfaces (e.g., LLDP-MED [LLDP-MED]).
"

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 10:29:54 -0500

We have been over this several times before.

You can't get interoperability that way.

If there are exactly two LCPs all UAs must implement, and any number of
optional ones, then every network has to implement at least one of those two
LCPs, and any number of optional ones.  That means that "any number of
optional ones" is useless for both parties.

If the network can limit UAs to ONLY those that implement one of the
optional protocols, then it works, but in practice, it is usually impossible
to do that.  My example is the wired, Ethernet connected phone in an RV
traveling down the road with wireless data card in a router.  These EXIST,
now.  

Brian
-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 10:11 AM
To: Brian Rosen
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Ecrit] Location Protocols in Phone BCP

"

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 10:11:01 -0600

The IETF can't (and shouldn't) try to make particular standards for 
every access technology that's out there.  What we can say is that the 
paradigm for those protocols should be the same as at the IP layer: 
Clients MUST implement all, networks MUST implement at least one.

(This is a little different from the text I sent before, and clearer, I 
think.)

All I'm saying is that we shouldn't try to enumerate all the possible 
protocols at lower layers, we should just state the general rule.  It 
seems to me that this achieves the same level of interoperability at all 
layers.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 11:22:40 -0500

It's very hard to have L2 specific LCPs.  The problem is that the clients
are generally not very L2 aware.  It's the clients that have the problem.
You can do things like interwork an L2 specific LCP to a common LCP so that
non L2 aware devices can work, but you have to do that, and usually, that's
impractical.  Use my example.  Suppose that the L2 used SUPL.  It's possible
for the PC Card that is plugged into the router could implement a SUPL
client and a HELD server and interwork SUPL in the GSM system to HELD on the
Ethernet so the Ethernet VoIP phone could get location via HELD.  Possible,
but not practical.  There are all sorts of these kinds of problems.  That's
why L2 specific LCPs don't work.

Brian

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 11:11 AM
To: Brian Rosen
Cc: [email-masked]; [email-masked]; [email-masked];

--Richard

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 11:35:33 -0800

If the choice is between preventing, allowing, or requiring PhoneBCP
suppport of SUPL, then my vote is to NOT prevent!  I would prefer
'require' since *most* of the location-aware 3G compatible
handsets/aircards over the next several years will (I predict) have a
SUPL stack included.  In the same time frame, many of those will also
have WiFi support, others will have LTE or WiMAX support as hybrids.

SUPL will be common-place.  OMA may not be 'Open-Source', it is
open-minded, and there is movement afoot to expand OMA/SUPL (as we heard
in the geopriv mtg. on Tuesday) w/respect expected proposals such as
LocSIP, etc.  Over the fairly near-term, I think there will be fewer
protocol, location representation, and privacy discontinuities - things
that too often get cited - yet are seldom well understood.

Let's encourage continued IETF communication with OMA/SUPL - not block
its use altogether.  This is a case where we need to be inclusive, not
exclusive.

As to the mobile RV sample case, the solution is also forseeable -
especially given that the location of the 3G aircard in the router is
good enough for routing.  The scenario given needs some integration, but
is doable.  Given that the aircard acts as a logical SET, with a SUPL
stack on board, and a GPS/AGPS chipset inside.  This combination *WILL*
(I believe) interoperate with a number of end client applications to
initiate and complete a location-routed, 3261 style SIP, emergency call
through the core, and into an ESInet.

-roger.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Thursday, November 20, 2008 8:23 AM
> To: 'Richard Barnes'
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> It's very hard to have L2 specific LCPs.  The problem is that 
> the clients are generally not very L2 aware.  It's the 
> clients that have the problem.
> You can do things like interwork an L2 specific LCP to a 
> common LCP so that non L2 aware devices can work, but you 
> have to do that, and usually, that's impractical.  Use my 
> example.  Suppose that the L2 used SUPL.  It's possible for 
> the PC Card that is plugged into the router could implement a 
> SUPL client and a HELD server and interwork SUPL in the GSM 
> system to HELD on the Ethernet so the Ethernet VoIP phone 
> could get location via HELD.  Possible, but not practical.  
> There are all sorts of these kinds of problems.  That's why 
> L2 specific LCPs don't work.
> 
> Brian
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> The IETF can't (and shouldn't) try to make particular 
> standards for every access technology that's out there.  What 
> we can say is that the paradigm for those protocols should be 
> the same as at the IP layer: 
> All I'm saying is that we shouldn't try to enumerate all the 
> possible protocols at lower layers, we should just state the 
> general rule.  It seems to me that this achieves the same 
> level of interoperability at all layers.
> 
> --Richard
> 
> > If there are exactly two LCPs all UAs must implement, and 
> any number 
> > of optional ones, then every network has to implement at 
> least one of 
> > those
> two
> > to do that.  My example is the wired, Ethernet connected 
> phone in an 
> > RV traveling down the road with wireless data card in a 
> router.  These 
> > EXIST, now.
> > 
> > Brian
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]
> > [RFC3825] and HELD 
> [I-D.ietf-geopriv-http-location-delivery].  Devices 
> > SHOULD support all location protocols supported at lower layers by 
> > their interfaces (e.g., LLDP-MED [LLDP-MED]).
> > "
> > 
> > 
> > 
> > 
> > Brian Rosen wrote:
> >> The problem with SUPL is that the majority of networks where SUPL 
> >> would
> be
> >> That makes it very hard to interwork with any of the rest 
> of the IETF
> > work.
> >> OMA into cooperation on location so that we have 
> interoperability at 
> >> the protocol, location representation and privacy levels.  So far, 
> >> that has
> > not
> >> happened.  If, as part of a comprehensive agreement to accomplish 
> >> such a goal, SUPL became one of the LCPs, I would not object.
> >>
> >> Brian
> >>
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of [email-masked]
> >>   >I believe we should come up with a list of LCPs which 
> are likely 
> >> to be
> >>   >supported in devices in a not so distant future. Since 
> I have no 
> >> seen or
> >>   >Could you please raise your question about location 
> protocols in 
> >> Phone

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Berryman" <[email-masked]>
Date: Thu, 20 Nov 2008 13:46:17 -0600

Roger makes a valid and compelling argument, one which I agree with.

Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roger Marshall
Sent: Thursday, November 20, 2008 1:36 PM
To: Brian Rosen; Richard Barnes
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Ecrit] Location Protocols in Phone BCP

-roger.

> >>   >this email is prohibited.

CONFIDENTIALITY NOTICE: The information contained in this message may be
privileged and/or confidential. If you are not the intended recipient,
or responsible for delivering this message to the intended recipient,
any review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please notify the sender immediately,
and delete it and all attachments from your computer and network.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: <[email-masked]>
Date: Thu, 20 Nov 2008 21:46:30 +0200

Oh, well. Do you want to have text which accommodates current client
implementations or instead set requirements for implementations intended
to support functionalities defined in ecrit?

Some (most?) of the clients out there do use L2 specific location
determination extensively. E.g., my device knows its location (at least
roughly) by multiple means, being that A-GPS, 2G/3G cell-id, L7 based on
L2 identifiers, etc. 

Since there is a DHCP client in the device, it wouldn't be a big deal
supporting the two location specific options. But are there any DHCP
servers out there which could provide me with reliable location while I
am on the move?

The problem I have is that what is used today is excluded from the
draft, but we are including things there which may never be deployed.
And it would be a naivity thinking that these LCPs would get deployed
because they are included in this draft.

- Gabor

  >From: ext Brian Rosen [mailto:[email-masked]]
  >Cc: Bajko Gabor (Nokia-CIC/MtView); [email-masked];
  >[email-masked]; [email-masked]; Tschofenig Hannes (NSN -
  >FI/Espoo)
  >You can do things like interwork an L2 specific LCP to a common LCP
so
  >that
  >client and a HELD server and interwork SUPL in the GSM system to HELD
on
  >the
[email-masked];
  >> optional ones, then every network has to implement at least one of
  >those
  >two
  >[email-masked];
  >>> That makes it very hard to interwork with any of the rest of the
IETF
  >>> OMA into cooperation on location so that we have interoperability
at
  >the
  >>> protocol, location representation and privacy levels.  So far,
that
  >has
such
  >a
Behalf
  >Of
  >>>   >   [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED
[LLDP-
  >MED].
  >>>   >
  >>>   >
  >>>   >I believe we should come up with a list of LCPs which are
likely to
  >>> be
  >>>   >supported in devices in a not so distant future. Since I have
no
  >seen
  >>> or
  >>>   >heard about LLDP support yet, at least that should be replaced
with
  >>> what
  >>>   >Could you please raise your question about location protocols
in
  >>>   >BCP mentioned at ESW5 in the ECRIT WG session again?
---------------------------------------------------------------------
---------------------------------------------------------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 14:51:59 -0500

I'm not interested in preventing SUPL.  The drafts allow others.  The
problem is, and remains interoperability.  The basic LCP "rule" is
"endpoints implement all, access networks implement one".  That rule
provides interoperability.  There is nothing you can do with SUPL that is
interoperable unless it goes on the list.  If you implement SUPL, then the
network and the endpoints ALSO need to implement another protocol from the
list, or we don't have interoperability.  It's possible for the network to
implement SUPL and some endpoints implement SUPL and those endpoints will
work.  Others won't, and that is very bad. 

There is no short cut.  Either SUPL goes on the list, or the network has to
implement one of the LCPs on the list.

Given the current level of non-interoperability of SUPL with the rest of the
LCPs, I oppose adding SUPL to the list at this time.

I don't understand your comments on the RV case.  The card can implement a
SUPL client.  Unless it implements a DHCP or HELD server and interworks the
SUPL location to the HELD/DHCP protocols, we have a problem.  And of course,
we can't reasonably get the privacy right doing that, and in some cases we
can't interwork the location representation.

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 2:36 PM
To: Brian Rosen; Richard Barnes
Cc: [email-masked]; [email-masked];

-roger.

> >> with what

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 20 Nov 2008 14:54:15 -0500

I cannot support requiring SUPL in DSL routers, desktop computers (and
related operating systems, SIP soft clients), analog terminal adaptors,
or other similar devices that are intended for use in a wireline
environment. I think that organizations that can drive requirements for
devices intended to be use in an environment where SUPL would actually
work, should be responsible for having device requirements requiring
SUPL. In other words, 3GPP/3GPP2 are absolutely in a position to require
SUPL support for devices that operate in an environment where SUPL
works. This is a perfect example of the "closed" network that Brian
describes somewhere (framework, I think).

Phonebcp is about requirements for devices in access environments where
the operators of the access environment cannot be assumed to have any
control over the type or nature of devices that connect to or through
it. Phonebcp needs to continue to have that as its purpose. 

I agree that nothing in phonebcp should preclude the use of SUPL, or be
incompatible with the use of SUPL. And I don't think it does.
Barbara 

-----Original Message-----

-roger.

*****

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: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 13:54:20 -0600

I think this argument makes sense.  In the framework I was calling for 
earlier, this would be one of the "Layer 2" protocols, since it has 
explicit dependencies on the physical layer and particular structure of 
the network.  So it would be RECOMMENDED under the principle that "if 
you're capable of a non-Internet-wide mechanism, you SHOULD support it."

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 14:58:42 -0500

What we have is basic non-interoperability.  Allowing SUPL is easy, and
doesn't help.
Adding SUPL to the list can't be done at the moment: we have to figure out
how to interwork representation, and we have to figure out how to deal with
the privacy issues.

Repeating myself, these issues could be solved by cooperation between IETF
and OMA.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 2:46 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Ecrit] Location Protocols in Phone BCP

- Gabor

so
on
[email-masked];
IETF
at
that
such
Behalf
[LLDP-
likely to
no
with
in

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 14:01:25 -0600

The problem is the scope of "all".  I don't think it makes sense for an 
IETF document to try to enumerate all the Layer-2 ways that people 
access the Internet and their associated location protocols, but it 
*can* make a recommendation for how things work at those layers (namely, 
it can recommend that layer-2 entities follow the same 
"endpoint-all/network-one" principle -- "EAN1"?).

Note: I'm grouping SUPL in with the "layer 2" mechanisms because it has 
dependencies on assumptions about the physical host (e.g., GPS in most 
cases), and about the structure of the network.

The real distinction, I guess, is between protocols that work everywhere 
in the Internet (DHCP, HELD) and protocols that only work in specific 
environments, like SUPL or LLDP.  The EAN1 principle applies to both of 
these classes, but is only an unconditional MUST for the Internet-wide 
ones, because it's not meaningful to mandate universal support for 
non-universal protocols.  There could still be a *conditional* MUST, 
conditioned on the client and its network connectivity meeting the 
requirements of the constrained protocols.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 15:06:38 -0500

Gabor accuses us of ignoring reality.  The 3GPP crowd has its own version of
that.

All 3GPP networks I know of support a raw packet service.  On that service
will run applications like MSN or AOL instant messaging.  Those services
will need to be able to make emergency chats.   To route properly, they need
location.  That means that EVERY handset must deploy some LCP, and must be
able to get location suitable for emergency call routing and dispatch per
-phonebcp.  The RV example is yet another case of the same thing.  The
mistake is assuming that all emergency calls will come through the E-CSCF.
They won't, and the 3GPP access network must conform to all the -phonebcp
requirements.  

Generally, I agree that SUPL is unsuitable for access networks that don't
use GPS or some form of measured location. 

Brian

-----Original Message-----

-roger.

*****

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: Ted Hardie <[email-masked]>
Date: Thu, 20 Nov 2008 14:16:12 -0600

At 12:06 PM -0800 11/20/08, Brian Rosen wrote:
>will need to be able to make emergency chats.

Sorry, can you point me to the current text in PhoneBCP or Framework
where we describe the emergency chats?  Grep didn't find it for me,
and I must have missed the fun on defining that.

In general, it might be best not to change the subject, if we are to
actually conclude this conversation.
				Ted
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 12:22:04 -0800

> Generally, I agree that SUPL is unsuitable for access 
> networks that don't use GPS or some form of measured location. 

[rsm - measured only - really? - surely you aren't suggesting that OMA
(and therefore 3GPP, 3GPP2) throw away their reliance on 'rough
location' via CellID, are you?

Wiremap location - given (manually input)]
CellID location - given
Terrestial trilateration - measured
Celestial trilateration - measured
Geocoded/reverse geocoded - derived

I would hope that PhoneBCP doesn't show a pre-disposition to 'given'
location scenarios, aka wiremap, etc. that are more Wireline oriented,
rather than mobile.  For the future, wireline devices reduce in number,
mobile (or even nomadic) devices will continue in their distribution
bias.  Fixed vs. Mobile has been the fundamental difference between how
the IETF looks at things vs. these mentioned other fora.  I contend that
if we solve this for mobile - then we can begin communicating better
with OMA/3GPP/3GPP2, and... Solving fixed will be easier.
/]

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, November 20, 2008 12:07 PM
> To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes'
> Gabor accuses us of ignoring reality.  The 3GPP crowd has its 
> own version of that.
> 
> All 3GPP networks I know of support a raw packet service.  On 
> that service will run applications like MSN or AOL instant 
> messaging.  Those services
> location.  That means that EVERY handset must deploy some 
> LCP, and must be able to get location suitable for emergency 
> call routing and dispatch per -phonebcp.  The RV example is 
> yet another case of the same thing.  The mistake is assuming 
> that all emergency calls will come through the E-CSCF.
> They won't, and the 3GPP access network must conform to all 
> the -phonebcp requirements.  
> 
> Generally, I agree that SUPL is unsuitable for access 
> networks that don't use GPS or some form of measured location. 
> 
> Brian
> 
> I cannot support requiring SUPL in DSL routers, desktop 
> computers (and related operating systems, SIP soft clients), 
> analog terminal adaptors, or other similar devices that are 
> intended for use in a wireline environment. I think that 
> organizations that can drive requirements for devices 
> intended to be use in an environment where SUPL would 
> actually work, should be responsible for having device 
> requirements requiring SUPL. In other words, 3GPP/3GPP2 are 
> absolutely in a position to require SUPL support for devices 
> that operate in an environment where SUPL works. This is a 
> perfect example of the "closed" network that Brian describes 
> somewhere (framework, I think).
> 
> Phonebcp is about requirements for devices in access 
> environments where the operators of the access environment 
> cannot be assumed to have any control over the type or nature 
> of devices that connect to or through it. Phonebcp needs to 
> continue to have that as its purpose. 
> 
> I agree that nothing in phonebcp should preclude the use of 
> SUPL, or be incompatible with the use of SUPL. And I don't 
> think it does.
> Barbara 
> 
> On Behalf Of Roger Marshall
>  If the choice is between preventing, allowing, or requiring 
> PhoneBCP suppport of SUPL, then my vote is to NOT prevent!  I 
> would prefer 'require' since *most* of the location-aware 3G 
> compatible handsets/aircards over the next several years will 
> (I predict) have a SUPL stack included.  In the same time 
> frame, many of those will also have WiFi support, others will 
> have LTE or WiMAX support as hybrids.
> 
> SUPL will be common-place.  OMA may not be 'Open-Source', it 
> is open-minded, and there is movement afoot to expand 
> OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) 
> w/respect expected proposals such as LocSIP, etc.  Over the 
> fairly near-term, I think there will be fewer protocol, 
> location representation, and privacy discontinuities - things 
> Let's encourage continued IETF communication with OMA/SUPL - 
> not block its use altogether.  This is a case where we need 
> to be inclusive, not exclusive.
> 
> As to the mobile RV sample case, the solution is also 
> forseeable - especially given that the location of the 3G 
> aircard in the router is good enough for routing.  The 
> scenario given needs some integration, but is doable.  Given 
> that the aircard acts as a logical SET, with a SUPL stack on 
> board, and a GPS/AGPS chipset inside.  This combination 
> *WILL* (I believe) interoperate with a number of end client 
> applications to initiate and complete a location-routed, 3261 
> style SIP, emergency call through the core, and into an ESInet.
> 
> -roger.
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Brian Rosen
> > It's very hard to have L2 specific LCPs.  The problem is that the 
> > clients are generally not very L2 aware.  It's the clients 
> that have 
> > the problem.
> common LCP so 
> > that non L2 aware devices can work, but you have to do that, and 
> > usually, that's impractical.  Use my example.  Suppose that the L2 
> > used SUPL.  It's possible for the PC Card that is plugged into the 
> > router could implement a SUPL client and a HELD server and 
> interwork 
> > SUPL in the GSM system to HELD on the Ethernet so the Ethernet VoIP 
> > phone could get location via HELD.  Possible, but not practical.
> > (This is a little different from the text I sent before, 
> and clearer, 
> > I
> > think.)
> > 
> > seems to me that this achieves the same level of 
> interoperability at 
> > all layers.
> > 
> > --Richard
> > 
> > >> I will say this.  For quite some time, the IETF has been 
> trying to
> > > interest
> > >>   >c) it is questionable whether it is really deployable 
> for WiFi 
> > >> networks
> > >>   >
> CONFIDENTIALITY NOTICE: The information contained in this 
> message may be privileged and/or confidential. If you are not 
> the intended recipient, or responsible for delivering this 
> message to the intended recipient, any review, forwarding, 
> dissemination, distribution or copying of this communication 
> or any attachment(s) is strictly prohibited. If you have 
> received this message in error, please notify the sender 
> immediately, and delete it and all attachments from your 
> computer and network.
> 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: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 15:32:06 -0500

Phonebcp doesn't have a pre-disposition.  It's neutral.  If we need to parse
more carefully, SUPL isn't very suitable for wiremap forms of location
determination.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 15:35:07 -0500

ED-78

You are clearly correct on thread drift.  Sorry.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Nov 2008 14:49:03 -0600

In another thread, Brian pointed out  the existence of ED-78.  His

>>will need to be able to make emergency chats.

ED-78 actually says:

ED-78 Endpoints supporting Instant Messaging (IM) MUST support both
   [RFC3428] and [RFC4975].

RFC 3428 is "Session Initiation Protocol (SIP) Extension for Instant Messaging"
and RFC 4975 is The Message Session Relay Protocol (MSRP).

These two are in conflict.  The first proposes that the instant messaging
services which are common and commercially deployed need to be
supported, need to have access to location, etc.  The second requires
the SIP/SIMPLE and MSRP be supported if any IM service is.

I do not think that any of this is currently best current practice, and
I think attempting to mandate SIP/SIMPLE & MSRP for anyone wishing
to support any IM is not practical.   IM can often be added by third
party applications, and I see no practical way to ensure that they
are compelled by this.

			Ted

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2008 14:58:06 -0600

At 02:01 PM 11/20/2008, Richard Barnes wrote:
>The problem is the scope of "all".  I don't think it makes sense for 
>an IETF document to try to enumerate all the Layer-2 ways that 
>people access the Internet and their associated location protocols, 
>but it *can* make a recommendation for how things work at those 
>layers (namely, it can recommend that layer-2 entities follow the 
>same "endpoint-all/network-one" principle -- "EAN1"?).
>
>Note: I'm grouping SUPL in with the "layer 2" mechanisms because it 
>has dependencies on assumptions about the physical host (e.g., GPS 
>in most cases), and about the structure of the network.
>
>The real distinction, I guess, is between protocols that work 
>everywhere in the Internet (DHCP, HELD) and protocols that only work 
>in specific environments, like SUPL or LLDP.  The EAN1 principle 
>applies to both of these classes, but is only an unconditional MUST 
>for the Internet-wide ones, because it's not meaningful to mandate 
>universal support for non-universal protocols.  There could still be 
>a *conditional* MUST, conditioned on the client and its network 
>connectivity meeting the requirements of the constrained protocols.

MUSTs in IETF-speak is not conditional, ever.  SHOULDs are 
conditional based on a "really good reason for an implementer to not 
implement something.

>>From: Roger Marshall [mailto:[email-masked]] Sent: 
>>Thursday, November 20, 2008 2:36 PM
>>>Behalf Of Brian Rosen
>>>clients are generally not very L2 aware.  It's the clients that 
>>>have the problem.
>>>You can do things like interwork an L2 specific LCP to a common 
>>>LCP so that non L2 aware devices can work, but you have to do 
>>>that, and usually, that's impractical.  Use my example.  Suppose 
>>>that the L2 used SUPL.  It's possible for the PC Card that is 
>>>plugged into the router could implement a SUPL client and a HELD 
>>>server and interwork SUPL in the GSM system to HELD on the 
>>>Ethernet so the Ethernet VoIP phone could get location via 
>>>HELD.  Possible, but not practical.
>>>There are all sorts of these kinds of problems.  That's why L2 
>>>specific LCPs don't work.
>>>
>>>Brian
>>>
>>>The IETF can't (and shouldn't) try to make particular standards 
>>>for every access technology that's out there.  What we can say is 
>>>that the paradigm for those protocols should be the same as at the 
>>>IP layer: Clients MUST implement all, networks MUST implement at least one.
>>>
>>>general rule.  It seems to me that this achieves the same level of 
>>>interoperability at all layers.
>>>
>>>--Richard
>>>
>>>>INT-12 Devices MUST support the DHCP location options [RFC4776] 
>>>>and [RFC3825] and HELD
>>>>SHOULD support all location protocols supported at lower layers 
>>>>by their interfaces (e.g., LLDP-MED [LLDP-MED]).
>>>>"
>>>>
>>>>
>>>>
>>>>
>>>>Brian Rosen wrote:
>>>>>the protocol, location representation and privacy levels.  So 
>>>>>far, that has
>>>>not
>>>>>happened.  If, as part of a comprehensive agreement to 
>>>>>accomplish such a goal, SUPL became one of the LCPs, I would not object.
>>>>>
>>>>>Brian
>>>>>

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 13:06:56 -0800

Isn't there a need to set the scope [text] of phonebcp, so that it makes
clear what that the requirements apply (without bias) to both fixed and
mobile end devices (and their associated network deployment types)?

Below is some keyword sampling to show some implications with regard to
fixed vs. mobile, but which isn't as crisp as it could be (depending on
the scope).

A search of phonebcp for the following terms yields the associated
references:

Fixed: 
(none);

Wireline: 
(none);

Mobile: 
AN-11; 
ED-35/AN-19; 
ED-35; 

Wireless:
AN-7/INT-6; 
AN-9; 
AN-7; 
INT-6; 

>From the toc, it is listed...

       6.2.2.  Access network "wire database" location information  .  7
       6.2.3.  End-system measured location information . . . . . . .  7
       6.2.4.  Network-measured location information  . . . . . . . .  8

-roger.

No mention of fixed, wireline, wireless, or mobile in any of the text
sections (Intro, etc.)

> Sent: Thursday, November 20, 2008 12:32 PM
> To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes'
> Phonebcp doesn't have a pre-disposition.  It's neutral.  If 
> we need to parse more carefully, SUPL isn't very suitable for 
> wiremap forms of location determination.
> 
> Brian
> 
> [rsm - measured only - really? - surely you aren't suggesting 
> that OMA (and therefore 3GPP, 3GPP2) throw away their 
> reliance on 'rough location' via CellID, are you?
> 
> Wiremap location - given (manually input)] CellID location - 
> given Terrestial trilateration - measured Celestial 
> trilateration - measured Geocoded/reverse geocoded - derived
> 
> location scenarios, aka wiremap, etc. that are more Wireline 
> oriented, rather than mobile.  For the future, wireline 
> devices reduce in number, mobile (or even nomadic) devices 
> will continue in their distribution bias.  Fixed vs. Mobile 
> has been the fundamental difference between how the IETF 
> looks at things vs. these mentioned other fora.  I contend 
> that if we solve this for mobile - then we can begin 
> communicating better with OMA/3GPP/3GPP2, and... Solving 
> fixed will be easier.
> /]
> 
> > Gabor accuses us of ignoring reality.  The 3GPP crowd has its own 
> > version of that.
> > 
> > All 3GPP networks I know of support a raw packet service.  On that 
> > service will run applications like MSN or AOL instant messaging.  
> > Those services
> > location.  That means that EVERY handset must deploy some LCP, and 
> > must be able to get location suitable for emergency call 
> routing and 
> > dispatch per -phonebcp.  The RV example is yet another case of the 
> > same thing.  The mistake is assuming that all emergency calls will 
> > come through the E-CSCF.
> > They won't, and the 3GPP access network must conform to all the 
> > -phonebcp requirements.
> > 
> > Generally, I agree that SUPL is unsuitable for access networks that 
> > don't use GPS or some form of measured location.
> > 
> > Brian
> > 
> computers (and 
> > related operating systems, SIP soft clients), analog terminal 
> > adaptors, or other similar devices that are intended for use in a 
> > wireline environment. I think that organizations that can drive 
> > requirements for devices intended to be use in an environment where 
> > SUPL would actually work, should be responsible for having device 
> absolutely 
> > in a position to require SUPL support for devices that 
> operate in an 
> > environment where SUPL works. This is a perfect example of the 
> > "closed" network that Brian describes somewhere (framework, 
> I think).
> > 
> > Phonebcp is about requirements for devices in access environments 
> > where the operators of the access environment cannot be assumed to 
> > have any control over the type or nature of devices that 
> connect to or 
> > through it. Phonebcp needs to continue to have that as its purpose.
> > 
> SUPL, or 
> > be incompatible with the use of SUPL. And I don't think it does.
> > Barbara
> > 
> > open-minded, and there is movement afoot to expand OMA/SUPL (as we 
> > heard in the geopriv mtg. on Tuesday) w/respect expected proposals 
> > such as LocSIP, etc.  Over the fairly near-term, I think 
> there will be 
> > fewer protocol, location representation, and privacy 
> discontinuities - 
> > things that too often get cited - yet are seldom well understood.
> > 
> > good enough for routing.  The scenario given needs some 
> integration, 
> > but is doable.  Given that the aircard acts as a logical 
> SET, with a 
> > SUPL stack on board, and a GPS/AGPS chipset inside.  This 
> combination
> > applications to initiate and complete a location-routed, 3261 style 
> > SIP, emergency call through the core, and into an ESInet.
> > 
> > -roger.
> > 
> standards for 
> > > > optional protocols, then it works, but in practice, it 
> is usually
> > > impossible
> > accomplish
> [mailto:[email-masked]] On 
> > > >>   >condition that this MUST only be supported if there 
> is a wifi 
> > > >> interface
> > > >>   >available on the device.
> > > >>   >
> > > >>   >- Gabor
> > > >>   >
> > > >>   >
> > > >>   >
> message may 
> > be privileged and/or confidential. If you are not the intended 
> > recipient, or responsible for delivering this message to 
> the intended 
> > recipient, any review, forwarding, dissemination, distribution or 
> > copying of this communication or any attachment(s) is strictly 
> > prohibited. If you have received this message in error, 
> please notify 
> > the sender immediately, and delete it and all attachments from your 
> > computer and network.
> 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

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 13:13:23 -0800

No objection to saying that SUPL in its present form is not a good
choice for wire-map, but would object to saying the same for other types
of 'non-measured' location.  

Rather, SUPL is in fact an excellent choice for non-endpoint measured
location such as 'CellID'. 

-roger.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Nov 2008 16:06:51 -0600

Only if the device is connected to its home network, else you require a
world in a database solution. Inter-carrier roaming with SUPL is
problematic to say the least.

Cheers
James

Of
> Roger Marshall
> Sent: Friday, 21 November 2008 8:13 AM
style
the

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Nov 2008 16:22:42 -0600

The distinction between fixed and mobile, wireline and wireless is
relevant, it is old-school thinking and isn't really applicable anymore.
We are talking about an Internet-based device, which can be any or all
of the above, and often at the same time.

I think that dissecting the networks in the manner being described below
leads to a very slippery slope very quickly.

Our requirements for an LCP were that it MUST be implemented by all
devices, not that it MUST be implemented by all device if....

LCPs, the ones currently in Phone BCP, all provide a local service
discovery technique, SUPL does not. This aspect of an LCP is important,
as it puts the target device in contact with the location server
responsible for determining the location of the Target in the local
access network. In this way, it is possible for the device to ask for
location in the same way every time, regardless of the network
technology. Again, this is not true for SUPL, different access
technologies require the Device and the home SLP to support new
measurement types, and potentially additional "out of scope"
connectivity back to the actual serving network to use this information.

Don't get me wrong, SUPL has a place in providing location in some
access network architectures, but it is far from ubiquitous, the aim of
phone BCP is specify what MUST be supported by all devices.

Cheers
James

Of
> Roger Marshall
> Sent: Friday, 21 November 2008 8:07 AM
style
the

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 16:32:59 -0600

I think James is saying about what I was before: Phonebcp just needs to 
distinguish Internet vs. non-Internet LCPs (not fixed vs mobile, etc). 
In the former class are HELD and DHCP location; in the latter, 
everything else.  The EAN1 principle applies in both cases, but in the 
non-Internet case, is conditioned on the endpoint actually having the 
capability (in terms of hardware and network) to use the LCP.

--Richard

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 15:09:30 -0800

Wait on... not the case for non-IMS emergency calls in SUPL. 

While it is true that SUPL goes to its home network for commercial
location and for any IMS call, it is not specified to do so with non-IMS
Emergency Roaming in SUPL 2.0 (Section 5.1.15.3).  For that, an
emergency call uses the local (visited) E-SLP (and lesser-tiered V-SLP).
Both are assumed to be in the visited network.  The device discovers the
E-SLP via MNC/MCC (network & country codes) supplied.

-roger.

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Thursday, November 20, 2008 2:07 PM
> To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes
> Only if the device is connected to its home network, else you 
> require a world in a database solution. Inter-carrier roaming 
> with SUPL is problematic to say the least.
> 
> Cheers
> James
> 
> 
> 
> > > Phonebcp doesn't have a pre-disposition.  It's neutral.  
> If we need 
> > > to parse more carefully, SUPL isn't very suitable for 
> wiremap forms 
> > > [rsm - measured only - really? - surely you aren't 
> suggesting that 
> > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance 
> on 'rough 
> > > Wiremap location - given (manually input)] CellID 
> location - given 
> > > Terrestial trilateration - measured Celestial trilateration - 
> > > measured Geocoded/reverse geocoded - derived
> > >
> > > oriented, rather than mobile.  For the future, wireline devices 
> > > reduce in number, mobile (or even nomadic) devices will 
> continue in 
> > > their distribution bias.  Fixed vs. Mobile has been the 
> fundamental 
> > > difference between how the IETF looks at things vs. these 
> mentioned 
> > > other fora.  I contend that if we solve this for mobile - then we 
> > > can begin communicating better with OMA/3GPP/3GPP2, 
> and... Solving 
> > > fixed will be easier.
> > > /]
> > >
> environments 
> forseeable -

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 20 Nov 2008 15:24:10 -0800

I don't think those fixed operator's wanting to introduce mobile
services think of these feature distinctions as 'old school'.  Nor do I
believe that current mobile operators view the separation as a slippery
slope.

 I do think you are failing to tease out the reasons why SUPL does
contain those specific measurement techniques - that is, that it does
the job of an LCP for conforming mobile networks, as well as additional
underlying data exchange (which LCP's by design, don't do - but rely on
other associated protocol suggestions like the new grip, the draft
titled, 'Providing Satellite Navigation Assistance Data using HELD',
etc.
<http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held-grip-00.
txt>).

So, in a way, SUPL </> HELD + GRIP

p.s. I think you meant "is NOT relevant"

> The distinction between fixed and mobile, wireline and 
> wireless is relevant,

-roger.

> Sent: Thursday, November 20, 2008 2:23 PM
> The distinction between fixed and mobile, wireline and 
> wireless is relevant, it is old-school thinking and isn't 
> really applicable anymore.
> We are talking about an Internet-based device, which can be 
> any or all of the above, and often at the same time.
> 
> I think that dissecting the networks in the manner being 
> described below leads to a very slippery slope very quickly.
> 
> Our requirements for an LCP were that it MUST be implemented 
> by all devices, not that it MUST be implemented by all device if....
> 
> LCPs, the ones currently in Phone BCP, all provide a local 
> service discovery technique, SUPL does not. This aspect of an 
> LCP is important, as it puts the target device in contact 
> with the location server responsible for determining the 
> location of the Target in the local access network. In this 
> way, it is possible for the device to ask for location in the 
> same way every time, regardless of the network technology. 
> Again, this is not true for SUPL, different access 
> technologies require the Device and the home SLP to support 
> new measurement types, and potentially additional "out of scope"
> Don't get me wrong, SUPL has a place in providing location in 
> some access network architectures, but it is far from 
> ubiquitous, the aim of phone BCP is specify what MUST be 
> supported by all devices.
> 
> 
> Cheers
> James
> 
> 
> 
> >        6.2.2.  Access network "wire database" location 
> information  .
> 7
> >        6.2.3.  End-system measured location information . . 
> . . . . .
> 7
> >        6.2.4.  Network-measured location information  . . . 
> . . . . .
> 8
> > 
> > -roger.
> > 
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Nov 2008 17:30:06 -0600

Hi Roger,

You and I have a different understanding then on how SUPL is invoked for
emergency calling.

It is my understanding that a SET has N x E-SLP certificates configured
into it.

When an emergency call is made, the network (P-CSCF) determines that an
emergency call is being made, and proceeds to contact the local E-SLP.
At that point, the E-SLP contacts the device, and IF the device has the
cert for that E-SLP, then it will initiate communication back to the
E-SLP for SUPL to continue.

This is not really device discovery of the LCP-server in the same way
that is done for HELD or DHCP.

Cheers
James

> Sent: Friday, 21 November 2008 10:10 AM
> To: Winterbottom, James; Brian Rosen; Stark, Barbara; Richard Barnes
the
> > > > > SUPL will be common-place.  OMA may not be 'Open-Source', it
is
> > > > > > > try to list all of the location protocols out there, if
for
> > > > > > no other
> > > > > > > reason than that it will rapidly become obsolete.
Instead,
> > > > > > we should

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 20 Nov 2008 17:39:07 -0600

Right - SUPL 2.0 now covers the option of SLPs that are present in the
access and intended to support emergency location. However, the E-SLP
procedures require a network-initiated ULP session to be established
with the SET in order to get location. That is, the VSP/IMS service has
to get this procedure kicked off. Then you get to the question of how
the SET deals with an otherwise unsolicited location request from an SLP
it doesn't recognize (i.e. didn't discover).

This procedure is not consistent with ECRIT emergency call procedures -
they are device centric with respect to initiating/controlling the
location acquisition. It isn't even clear how a VSP could possibly know
where to direct an MLP request to in order to bring the E-SLP into play.
It works in certain IMS architectures but not in the general Internet
case.

There is clearly no reason that a suitably controlled environment
couldn't use SUPL for the VoIP emergency call case - at least for
initial location - and I don't think that BCP is saying it can't be the
mechanism for generating location for an emergency call. It wouldn't be
right to mandate that all devices have to have SUPL, for a number of
reasons including the constraint that you can't actually have SUPL
without a home SLP provider being configured into the SET. A vanilla,
off the shelf, device can have perfectly functional HELD/DHCP
capabilities without any third party dependency.

In the case of the RV example, the 3G router could definitely have a
SUPL client. I think the issue Brian is talking about is that all of the
devices in the RV (that would actually be the source of the emergency
call) would either be using WiFi or Ethernet to talk to the VSP. It
doesn't help them that the router is a SET - unless the router turns
around and acts as a LIS or provides location by DHCP. It would also be
challenged by the lack of ability to get a location reference from the
SLP that could be used for location updates in a mobile environment.
Location URI is not available via SUPL.

I think that, perhaps, the opportunity is to make the BCP more clearly
state that other methods aren't excluded by the mandatory LCP list -
it's just that the IETF isn't saying that all devices that use the ECRIT
emergency calling model must also support those other methods.

I believe I'm echoing Richard Barnes' sentiment in this respect.

Cheers,
Martin

-----Original Message-----

-roger.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Nov 2008 06:21:33 +0100

We are moving towards a state where devices support multiple of these,
and in some cases where they may be active at the same time.

We certainly already have devices that may be simultaneously registered
in WLAN and 3GPP access.

As soon as you start distinguishing any type of phone by access
technology, you will end up with these devices having to support
multiple different requirements.

regards

Keith 

> Sent: Thursday, November 20, 2008 9:07 PM
> Isn't there a need to set the scope [text] of phonebcp, so 
> that it makes clear what that the requirements apply (without 
> bias) to both fixed and mobile end devices (and their 
> associated network deployment types)?
> 
> Below is some keyword sampling to show some implications with 
> regard to fixed vs. mobile, but which isn't as crisp as it 
> could be (depending on the scope).
> 
> information  .  7
> No mention of fixed, wireline, wireless, or mobile in any of 
> the text sections (Intro, etc.)
> 
> we need to 
> > parse more carefully, SUPL isn't very suitable for wiremap forms of 
> > location determination.
> > 
> > Brian
> > 
> suggesting that OMA 
> > Wiremap location - given (manually input)] CellID location - given 
> > Terrestial trilateration - measured Celestial trilateration 
> - measured 
> > rather than mobile.  For the future, wireline devices reduce in 
> > number, mobile (or even nomadic) devices will continue in their 
> > distribution bias.  Fixed vs. Mobile has been the fundamental 
> > difference between how the IETF looks at things vs. these mentioned 
> > other fora.  I contend that if we solve this for mobile - 
> then we can 
> > begin communicating better with OMA/3GPP/3GPP2, and... 
> Solving fixed 
> > will be easier.
> > /]
> > 
> LCP, and 
> networks that

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 21 Nov 2008 07:28:48 -0800

Keith:
I agree completely with the first part of what you said, and want to
clarify my intent of highlighting differences in general:

We've already got different requirements by access 'type' (i.e.,
'wireless' and 'mobile' mentioned by name), so for some other
requirements - certainly, I would think those that mention the term
'wire database' - those imply their application to a fixed type of
network access (it wouldn't work to well for mobile).

What I was asking for, (and to my understanding, it was agreed to in the
ecrit meeting), was that since these requirements already mention
different access types, that there should be some additional text that
acknowledges the existance of these different access types, as
background for their respective requirements.

-roger.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Thursday, November 20, 2008 9:22 PM
> We are moving towards a state where devices support multiple 
> of these, and in some cases where they may be active at the same time.
> 
> We certainly already have devices that may be simultaneously 
> registered in WLAN and 3GPP access.
> 
> As soon as you start distinguishing any type of phone by 
> access technology, you will end up with these devices having 
> to support multiple different requirements.
> 
> regards
> 
> Keith 
> 
> > Isn't there a need to set the scope [text] of phonebcp, so that it 
> > makes clear what that the requirements apply (without
> > bias) to both fixed and mobile end devices (and their associated 
> > network deployment types)?
> > 
> > Below is some keyword sampling to show some implications 
> with regard 
> > to fixed vs. mobile, but which isn't as crisp as it could be 
> > (depending on the scope).
> >

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 21 Nov 2008 07:30:45 -0800

James:
My scenario was the non-IMS one (no P-CSCFs, etc.)

-roger. 

> Sent: Thursday, November 20, 2008 3:30 PM
> You and I have a different understanding then on how SUPL is 
> invoked for emergency calling.
> 
> It is my understanding that a SET has N x E-SLP certificates 
> configured into it.
> 
> When an emergency call is made, the network (P-CSCF) 
> determines that an emergency call is being made, and proceeds 
> to contact the local E-SLP.
> At that point, the E-SLP contacts the device, and IF the 
> device has the cert for that E-SLP, then it will initiate 
> communication back to the E-SLP for SUPL to continue.
> 
> This is not really device discovery of the LCP-server in the 
> same way that is done for HELD or DHCP.
> 
> Cheers
> James
> 
> 
> > > require a world in a database solution. Inter-carrier 
> roaming with 
> > > SUPL is problematic to say the least.
> > >
> > > Cheers
> > > James
> > >
> > >
> > >
> > > [mailto:[email-masked]] On Behalf Of
> > > > Roger Marshall
> > > > choice for wire-map, but would object to saying the 
> same for other
> > > types
> > > > > > Generally, I agree that SUPL is unsuitable for 
> access networks
> > > that
> > > > > > requirements for devices intended to be use in an 
> environment
> > > where
> > > > > > > Clients MUST implement all, networks MUST 
> implement at least
> > > one.
> > > > > > >
> > > > > > > protocols at lower layers, we should just state 
> the general
> > > > > > rule.  It
> > > > > > > > If the network can limit UAs to ONLY those that 
> implement
> > > > > > > one of the
> > > > > > > >> incompatible location representation, and an 
> incompatible
> > > > > > > privacy model.
> > > > > > > >> supported anywhere, or instead have a list of 
> LCPs which
> > > > > > > are highly
> > > > > > > >> There are restrictions everywhere, things come 
> at a cost
> > > > > > > even in the
> > > > > > > >>   >I am curious that you say that SUPL is a 
> MUST support
> > > > > > > given that:
> > > > > > > >>   >Can you perhaps describe how it fits into 
> the general
> > > > > > > Internet model?
> > > > > > > >>   >
> > > > > > > >>   >Cheers
> > > > > > > >>   >James
> > > > > > > >>   >
> > > > > > > >>   >
> > > > > > > >>   >I was requested to send my observations 
> regarding this
> > > > > > > requirement:
> > > > > > > >>   >
> > > > > > > >>   >heard about LLDP support yet, at least that 
> should be
> > > > > > replaced
> > > > > > > >> with what
> > > > > > > >>   >contain privileged, proprietary, or 
> otherwise private
> > > > > > > information.
> > > > > > the sender immediately, and delete it and all 
> attachments from
> > > your
> > > > > > computer and network.
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Nov 2008 09:43:20 -0600

>network access (it wouldn't work to well for mobile).

I'm not trying to be flippant - but what about APs that do not 
triangulate, in which any location will be based on the wiremap DB 
off a specific Ethernet switch port?

This has a specific learned <method> tag already.

> > > environment where

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Nov 2008 10:44:23 -0500

Roger

Please send text.  Note that probably this text goes in -framework, so look
there first.  If you think specific statements in -phonebcp need to be
changed, please suggest the precise change you want.

Note that I plan to release a new version within a week.

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Friday, November 21, 2008 10:29 AM
To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; Richard Barnes
Cc: [email-masked]; [email-masked];

Keith:

-roger.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 21 Nov 2008 10:42:35 -0600

I strongly disagree with this from a philosophical standpoint.  Type of access should only affect protocol design where attributes of that access affect the protocol.

For instance, we design protocols for networks with long delays, which happen to be applicable to inter-planetary communication.  This means that when someone uses that protocol for shipping data on reindeer, it doesn't break because someone assumes that it a radio link in space.

So, what we need to do is identify attributes of the network that are relevant to the protocol design.  As far as the document is currently specified, the attribute that we're interested in is mobility - that is, the fact that location changes.  Do not mistakenly assign this attribute to wireless networks.

For an example of how this is harmful, imagine that it is possible that a wired connection on a plane (now, why don't they do that...seems logical).  If we had a client that was on a wire, there is the risk that they continue this assumption to detrimental effect.

Cheers,
Martin

> Sent: Friday, 21 November 2008 9:29 AM

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Nov 2008 11:52:30 -0500

The plane is a great example of an indirect connection to a network. My RV
was another.  You can't make assumptions about mobility or anything else of
relevance to the group from the characteristics of the device placing the
emergency call, or it's first hop connection.  It's another example of how
difficult it is to make use of layer 2 specific LCPs.  Generally, assuming
that bridging devices will bridge LCPs is a losing proposition.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomson, Martin
Sent: Friday, November 21, 2008 11:43 AM
To: Roger Marshall
Cc: [email-masked]
Subject: Re: [Ecrit] Location Protocols in Phone BCP

I strongly disagree with this from a philosophical standpoint.  Type of
access should only affect protocol design where attributes of that access
affect the protocol.

For instance, we design protocols for networks with long delays, which
happen to be applicable to inter-planetary communication.  This means that
when someone uses that protocol for shipping data on reindeer, it doesn't
break because someone assumes that it a radio link in space.

So, what we need to do is identify attributes of the network that are
relevant to the protocol design.  As far as the document is currently
specified, the attribute that we're interested in is mobility - that is, the
fact that location changes.  Do not mistakenly assign this attribute to
wireless networks.

For an example of how this is harmful, imagine that it is possible that a
wired connection on a plane (now, why don't they do that...seems logical).
If we had a client that was on a wire, there is the risk that they continue
this assumption to detrimental effect.

Cheers,
Martin

> > > > > sender and delete the material from all computers. GA621

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 21 Nov 2008 10:54:17 -0800

I agree with the differentiation of protocol requirement which
differentiate between mobile and non-mobile (use whatever term you
like), but I do not support terms such as 'wireless' (as is in the
draft) for the reasons you reasonably cite. 

The airplane example provides two notions of location.  One may relative
to a wired database, which is inside a closed system, which can only
provide a relative location (e.g., you're in seat 34C).  The other view
is that of being mobile, in this case, best given by some 3space datum
coordinate set (it could either represent the plane's position or the
end device location - you pick).  The two forms have different levels of
importance, but each is relevant.  

The question is, is the end device fixed or mobile?

-roger.

> Sent: Friday, November 21, 2008 8:53 AM
> To: 'Thomson, Martin'; Roger Marshall
> Cc: [email-masked]
> The plane is a great example of an indirect connection to a 
> network. My RV was another.  You can't make assumptions about 
> mobility or anything else of relevance to the group from the 
> characteristics of the device placing the emergency call, or 
> it's first hop connection.  It's another example of how 
> difficult it is to make use of layer 2 specific LCPs.  
> Generally, assuming that bridging devices will bridge LCPs is 
> a losing proposition.
> 
> Brian
> 
> On Behalf Of Thomson, Martin
> I strongly disagree with this from a philosophical 
> standpoint.  Type of access should only affect protocol 
> design where attributes of that access affect the protocol.
> 
> For instance, we design protocols for networks with long 
> delays, which happen to be applicable to inter-planetary 
> communication.  This means that when someone uses that 
> protocol for shipping data on reindeer, it doesn't break 
> because someone assumes that it a radio link in space.
> 
> So, what we need to do is identify attributes of the network 
> that are relevant to the protocol design.  As far as the 
> document is currently specified, the attribute that we're 
> interested in is mobility - that is, the fact that location 
> changes.  Do not mistakenly assign this attribute to wireless 
> networks.
> 
> For an example of how this is harmful, imagine that it is 
> possible that a wired connection on a plane (now, why don't 
> they do that...seems logical).
> If we had a client that was on a wire, there is the risk that 
> they continue this assumption to detrimental effect.
> 
> Cheers,
> Martin
> 
> > What I was asking for, (and to my understanding, it was 
> agreed to in 
> > the ecrit meeting), was that since these requirements 
> already mention 
> > > We are moving towards a state where devices support multiple of 
> > > these, and in some cases where they may be active at the same
> > time.
> > >
> > > > > > wireline environment. I think that organizations that can 
> > > > > > drive requirements for devices intended to be use in an
> > > > environment where
> > > > OMA/SUPL (as we

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 21 Nov 2008 13:29:36 -0600

Hi Roger,

To answer this question, you have to first answer the question: how many reference frames exist?  My answer is one.

It helps to only have a single reference frame for this purpose.  That is, earth-centred, earth-fixed is the single reference frame we use to determine movement.  Anything moving in that reference frame is moving.  Establishing ad hoc reference frames increases the complexity of any solution that we develop.

In the plane example, you might use a complex of the geodetic location of the plane with uncertainty, plus a civic address with SEAT=34C.  However, this would be considered to be moving at 3500m/s.

Thanks,
Martin

> Sent: Friday, 21 November 2008 12:54 PM
> To: Brian Rosen; Thomson, Martin
> Cc: [email-masked]
> > > > > > > > every access technology that's out there.  What we can
> say
> > > > > > > is that the
> > > > > > > > > I think we need to pull up a level.  It's not
> reasonable
> > > > > > > > for an RFC to
> > > > > > > > > SHOULD support all location protocols supported at
> lower
> > > > > > > layers by
> > > > > > > > >> general Internet model. The reality is that most of
> the
> > > > > > > > devices with

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 21 Nov 2008 11:28:22 -0800

> I'm not trying to be flippant - but what about APs that do 
> not triangulate, in which any location will be based on the 
> wiremap DB off a specific Ethernet switch port?

Phonebcp has requirements that rightly distinguish between 'wireless'
access networks and 'mobile' end devices which communicate over them.

If the end device 'inherits' an AP's location that is pre-provisioned
into a wire database, (i.e., given), then the location were talking
about is that of the AP - only roughly associated with the actual
location of the radio connected end device, and in a sense, has nothing
to do with the end device being mobile or not.  

Mobile device classification, according to the draft, requires location
updates to be possible, something that is separate from the initial
above scenario, since a radio connected end device (e.g., cordless DECT
phone) might not be 'mobile' in terms of the following requirement.

   ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get
   repeated location updates to track the motion of the device during
   the complete processing of the call.

Again, I don't see any problems with above, or other mobile device or
access network requirements in phonebcp.

-roger.

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Friday, November 21, 2008 7:43 AM
> To: Roger Marshall; DRAGE, Keith (Keith); Brian Rosen; Stark, 
> Barbara; Richard Barnes
> I'm not trying to be flippant - but what about APs that do 
> not triangulate, in which any location will be based on the 
> wiremap DB off a specific Ethernet switch port?
> 
> >What I was asking for, (and to my understanding, it was agreed to in 
> > > these, and in some cases where they may be active at the 
> same time.
> > >

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 21 Nov 2008 11:39:18 -0800

Martin:
I agree with your excellent reference frame explanation, and would
support additional documentation/discussion around how we assemble and
use the location 'complex' you've mentioned - since phonebcp
requirements provide for these kinds of location information by which a
complex could be formed.

-roger.

> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: Friday, November 21, 2008 11:30 AM
> To: Roger Marshall
> Cc: [email-masked]
> To answer this question, you have to first answer the 
> question: how many reference frames exist?  My answer is one.
> 
> It helps to only have a single reference frame for this 
> purpose.  That is, earth-centred, earth-fixed is the single 
> reference frame we use to determine movement.  Anything 
> moving in that reference frame is moving.  Establishing ad 
> hoc reference frames increases the complexity of any solution 
> that we develop.
> 
> In the plane example, you might use a complex of the geodetic 
> location of the plane with uncertainty, plus a civic address 
> with SEAT=34C.  However, this would be considered to be 
> moving at 3500m/s.
> 
> Thanks,
> Martin
> 
> > The airplane example provides two notions of location.  One may 
> > relative to a wired database, which is inside a closed 
> system, which 
> > can only provide a relative location (e.g., you're in seat 
> 34C).  The 
> > other view is that of being mobile, in this case, best 
> given by some 
> > 3space datum coordinate set (it could either represent the plane's 
> > position or the end device location - you pick).  The two 
> forms have 
> > different levels of importance, but each is relevant.
> > 
> > > The plane is a great example of an indirect connection to 
> a network. 
> > > My RV was another.  You can't make assumptions about mobility or 
> > > anything else of relevance to the group from the 
> characteristics of 
> > > the device placing the emergency call, or it's first hop 
> connection.  
> > > It's another example of how difficult it is to make use 
> of layer 2 
> > > specific LCPs.
> > > Generally, assuming that bridging devices will bridge LCPs is a 
> > > losing proposition.
> > >
> > > Brian
> > >
> > > Behalf Of Thomson, Martin
> standpoint.  Type 
> > > of access should only affect protocol design where attributes of 
> > > that access affect the protocol.
> > >
> > > For instance, we design protocols for networks with long delays, 
> > > which happen to be applicable to inter-planetary communication.  
> > > This means that when someone uses that protocol for 
> shipping data on 
> > > reindeer, it doesn't break because someone assumes that 
> it a radio 
> > > link in space.
> > >
> > > So, what we need to do is identify attributes of the network that 
> > > are relevant to the protocol design.  As far as the document is 
> > > currently specified, the attribute that we're interested in is 
> > > mobility - that is, the fact that location changes.  Do not 
> > > mistakenly assign this attribute to wireless networks.
> > >
> possible 
> > > that a wired connection on a plane (now, why don't they do 
> > > that...seems logical).
> > > If we had a client that was on a wire, there is the risk 
> that they 
> > > continue this assumption to detrimental effect.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > requirements - certainly, I would think those that mention the 
> > > > term 'wire database' - those imply their application to a fixed 
> > > > type of network access (it wouldn't work to well for mobile).
> > > >
> > > > > >        6.2.3.  End-system measured location 
> information . . .
> > > > > > . . . .  7
> > > > > >        6.2.4.  Network-measured location 
> information  . . . .
> > > > > > . . . .  8
> > > > > >
> > > > > > -roger.
> > > > > >
> > > > > >
> > > > > > > distribution bias.  Fixed vs. Mobile has been the 
> > > > > > > fundamental difference between how the IETF looks 
> at things 
> > > > > > > vs. these
> > > > > mentioned
> > > > > > > > All 3GPP networks I know of support a raw 
> packet service.
> > > > > >  On that
> > > > > > > > They won't, and the 3GPP access network must conform to 
> > > > > > > > all the -phonebcp requirements.
> > > > > > > >
> > > > > > > > I agree that nothing in phonebcp should 
> preclude the use 
> > > > > > > > of
> > > > > > > SUPL, or
> > > > > > > > be incompatible with the use of SUPL. And I 
> don't think it
> > > > does.
> > > > > > > > Barbara
> > > > > > > >
> > > > > > > > SUPL stack included.  In the same time frame, many of 
> > > > > > > > those
> > > > > > > will also
> > > > > > > > Let's encourage continued IETF communication 
> with OMA/SUPL
> > > > > > > - not block
> > > > > > > > especially given that the location of the 3G aircard in 
> > > > > > > > the
> > > > > > > router is
> > > > > > > > *WILL* (I believe) interoperate with a number of end 
> > > > > > > > client applications to initiate and complete a 
> > > > > > > > location-routed,
> > > > > > 3261 style
> > > > > > > > > used SUPL.  It's possible for the PC Card that is 
> > > > > > > > > plugged
> > > > > > > into the
> > > > > > > > > Cc: [email-masked]; 
> > > > > > > > > [email-masked]; [email-masked]; 
> > > > > > > > > [email-masked];
> > > > > > > > > paradigm for those protocols should be the same as at 
> > > > > > > > > the
> > > > > > > IP layer:
> > > > > > > > > All I'm saying is that we shouldn't try to 
> enumerate all
> > > > > > > > the possible
> > > > > > > > > > of optional ones, then every network has to 
> implement
> > at
> > > > > > > > > least one of
> > > > > > > > > > those
> > > > > > > > > two
> > > > > > > > > > LCPs, and any number of optional ones.  That means 
> > > > > > > > > > that
> > > > > > > > > "any number of
> > > > > > > > > > RV traveling down the road with wireless 
> data card in 
> > > > > > > > > > a
> > > > > > > > > router.  These
> > > > > > > > > > EXIST, now.
> > > > > > > > > >
> > > > > > > > > > Brian
> > > > > > > > > > try to list all of the location protocols 
> out there, 
> > > > > > > > > > if for
> > > > > > > > > no other
> > > > > > > > > > INT-12 Devices MUST support the DHCP 
> location options
> > > > > > > > [RFC4776] and
> > > > > > > > > > [RFC3825] and HELD
> > > > > > > > > >> The problem with SUPL is that the majority of 
> > > > > > > > > >> networks
> > > > > > > > where SUPL
> > > > > > > > > >> would
> > > > > > > > > be
> > > > > > > > > >> available have a proxy (E-CSCF) insert 
> location.  It
> > > > > > > also has an
> > > > > > > > > >> happened.  If, as part of a comprehensive 
> agreement 
> > > > > > > > > >> to
> > > > > > > > accomplish
> > > > > > > > > >> Is the intent to list the LCPs which are 
> access-type
> > > > > > > > > agnostic but not
> > > > > > > > > >>   >Cc: [email-masked]; Tschofenig 
> Hannes (NSN
> > > > > > > - FI/Espoo)
> > > > > > > > > >>   >The list of LCPs in the phone BCP is a must 
> > > > > > > > > >> support
> > > > > > > > list, and is
> > > > > > > > > >> access-
> > > > > > > > > >>   >type agnostic.
> attachments
> > > > > > from your

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 21 Nov 2008 13:49:49 -0600

PIDF-LO profile already discusses forming a complex.  In my opinion, that's all we can sensibly do.  I don't think that enumerating all the alternatives would be productive.

> Sent: Friday, 21 November 2008 1:39 PM
> To: Thomson, Martin
> Cc: [email-masked]
> > > > > > > > > will need to be able to make emergency chats.   To
> route
> > > > > > > > > properly, they need
> > > > > > > > > have WiFi support, others will have LTE or WiMAX
> support
> > > > > > > as hybrids.
> > > > > > > > >
> > > > > > > > > heard in the geopriv mtg. on Tuesday) w/respect
> expected
> > > > > > > proposals
> > > > > > > > > > that non L2 aware devices can work, but you have to
> do
> > > > > > > that, and
> > > > > > > > > > usually, that's impractical.  Use my example.
> Suppose
> > > > > > > > that the L2
> > > > > > > > > > router could implement a SUPL client and a HELD
> server
> > > and
> > > > > > > > > interwork
> > > > > > > > > > Clients MUST implement all, networks MUST implement
> at
> > > > > > > least one.
> > > > > > > > > >
> > > > [email-masked];
> > > > > > > > > > >>   >Subject: RE: [Ecrit] Location Protocols in
> Phone
> > > BCP
> > > > > > > > > > >>   >
> > > > > > > > > > >>   >Hi Gabor,
> > > > > > > > > > >>   >
> > > > > > > > > > >>   >Subject: Re: [Ecrit] Location Protocols in
> Phone
> > > BCP
> > > > > > > > > > >>   >
> > > > > > > > > > >>   >  ED-21/INT-12 Devices MUST support all of:
> DHCP
> > > > > > > > > > location options
> > > > > > > > > > >>   >   [I-D.ietf-geopriv-http-location-delivery]
> and
> > > > > > > > > > LLDP-MED [LLDP-MED].
> > > > > > > > > > >>   >
> > > > > > > > > > >>   >

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Nov 2008 15:51:29 -0500

While I think this is generally true, there are reasonably-common  
exceptions. For example, on a cruise ship, the fire warden or EMT  
cares about the cabin the emergency is in, not the current longitude  
and latitude the cabin happens to be located at, which would be  
utterly useless. Same is probably true for other "closed" systems,  
such as large buildings or an underground mine. Even on a plane, the  
flight attendant finds you by seat number when you press that orange  
button, not by longitude and latitude, so it doesn't matter whether  
you can determine the latter.

Henning

On Nov 21, 2008, at 2:29 PM, Thomson, Martin wrote:

> Hi Roger,
>
> To answer this question, you have to first answer the question: how  
> many reference frames exist?  My answer is one.
>
> It helps to only have a single reference frame for this purpose.   
> That is, earth-centred, earth-fixed is the single reference frame we  
> use to determine movement.  Anything moving in that reference frame  
> is moving.  Establishing ad hoc reference frames increases the  
> complexity of any solution that we develop.
>
> location of the plane with uncertainty, plus a civic address with  
> SEAT=34C.  However, this would be considered to be moving at 3500m/s.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 21 Nov 2008 15:10:22 -0600

Good point.  

In general, it might not even be necessary to assume a single reference frame.  To the extent possible, we should try to avoid making unsafe assumptions either way.  However, when it is unavoidable we need to be clear.

>From the perspective of general advice to device manufacturers (the original topic), I believe that the only necessary advice is to note that location might change and the device MUST allow for that possibility.  While urn:service:sos.fire on the cruise ship might not perceive movement; urn:service:sos.terrorist might [1].  Better avoid the assumptions on the device end altogether.

The consumer of location information might define their own means of handling these special cases.  Within such closed systems, conventions are possible.  On the plane, the filter rules might ignore lat/long.

Ta,
Martin

[1] Speed 2 was two hours of my life that I want back.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 21 November 2008 2:51 PM
> To: Thomson, Martin
> Cc: Roger Marshall; [email-masked]

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 28 Nov 2008 14:35:24 -0800

Brian:
Below is a proposed change in text to the current phonebcp-06 that adds
some background for various requirements later in the draft that specify
"wireless" and "mobile", per remarks made in the 11/20 ECRIT wg meeting.

1. Section 6. Location and its role in emergency calls

change from:

In Internet emergency calling, where the endpoint is located 
is "determined" using a variety of measurement or wiretracing 
methods.  Endpoints may be "configured" with their own location 
by the access network.

change to:

In Internet emergency calling, the endpoint location 
is "determined" using a variety of measurement or wiretracing 
methods.  Requirements for endpoint location determination vary, 
depending on whether an endpoint's resulting location is based 
on internal (device-based) or external (network-based) 
measurements, or by manual provisioning - for mobile capable, or 
fixed environment endpoints, respectively.  Once location has 
been determined, endpoints may then be "configured" with their 
own location by the access network via some Location Configuration 
Protocol (LCP).

-roger marshall.