Subject: RE: [Geopriv] HELD - Is HTTP appropriate

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 3 Aug 2005 12:04:36 -0500

I've been lurking on this exploder for awhile now. Just to introduce
myself, I'm Barbara Stark, and I work for BellSouth, which is an ILEC
(which does routing to PSAPs today, and maintains extensive address
databases for support of E911), a broadband access provider (mostly
DSL), an ISP, a VoIP provider-to-be (for enterprise and consumer), and
owns a considerable share of Cingular Wireless. So, I'm interested in
what's going on here (and in ecrit) at many levels.

HELD is particularly interesting, since I don't see the DHCP solution
meeting my needs. A L7 solution is exactly what I want and need, both
for getting location info to location-aware broadband routers and VoIP
devices, and to be able to do OBO location discovery for
location-unaware devices. I believe that the OBO functionality will be a
great step forward from the static location info VoIP providers have to
maintain today, until all VoIP devices are location-aware.

My comment right now, is on whether HTTP is appropriate.

For my purposes, HTTP is very appropriate, as it provides maximum re-use
of existing software on CPE that is provided to end customers. I'm
currently requiring support for DSL Forum TR-069 configuration mechanism
on both VoIP devices and broadband routers. This mechanism uses RPC
calls with XML/SOAP/HTTP(S). Many of these devices also support UPnP,
which uses XML/SOAP/HTTP. I have nothing that does BEEP in any way shape
or form.

I've followed some of the IETF netconf work, too. They claim that HTTP
isn't great for some things, but admit that HTTP is much more commonly
used than BEEP, and so they had to support it. The main complaint seems
to be that it limits implementations to a client-server type of
relationship. In the case of location discovery with a LIS, that's
exactly what we have, so that seems just fine to me.

If there's a desire to use some SOAP and WSDL in HELD, that works for
me. But I really want to see HTTP supported, in order to maximize re-use
of existing software, and not force CPE vendors to implement a different
protocol (like BEEP) just for location discovery. And I'd prefer to
minimize the number of protocols that LIS servers will need to support
(i.e., prefer not to support both BEEP and HTTP).

Barbara 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Brian Rosen
Sent: Monday, August 01, 2005 9:46 AM
To: 'GEOPRIV'
Subject: [Geopriv] HELD - Is HTTP appropriate

Discussion of HELD was cut off, with a request to bring issues to the
list

One issue is the discussion of whether HTTP is an appropriate protocol
to
use for this purpose.

Let's assume that some L7 protocol is a good idea.  Let's also assume
PIDF-LO, which is XML, is a good format to return location.

That still begs the question: Is HTTP the right protocol?

It would seem that we have a unique use, for which we are not going to
be
able to reuse a lot of existing infrastructure.  We have a fairly
straightforward request/response mechanism, and we have fairly well
understood behaviors with respect to the actual protocol.  Would it not
be
better to consider alternatives?  BEEP for example?  A real web service?
A
new protocol? 

HTTP gets misused for lots of things that can be made to work sort of.
This
one seems like such a misuse.  

Brian

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

*****
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. 162

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 Aug 2005 13:27:10 -0400

I understand the issue of minimizing the software load on end devices.  I'm
not a real BEEP bigot, or even an expert.  What I know is that BEEP is very
small (but I don't have statistics available at hand), open source code
exists for all common platforms, and it's simple and fast.  I'm not
suggesting HELD be implemented on BEEP.  I'm asking that we evaluate whether
HTTP is the appropriate protocol.  I think code reuse and code size on end
devices IS a concern, but not the only one, and we need a better evaluation
of alternatives.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stark, Barbara
Sent: Wednesday, August 03, 2005 1:05 PM
To: GEOPRIV
Subject: RE: [Geopriv] HELD - Is HTTP appropriate

Barbara 

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

Brian

*****
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. 162

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 3 Aug 2005 12:29:40 -0500 (EST)

Just to underscore what Barbara has stated from an operational reality
perspective: All the Location Services interface standards work of the OGC
membership currently assumes an HTTP or HTTP/SOAP environment. As there
are now numerous implementations of these OGC standards, there will also
be a sensitivity within that community to having to implement yet another
environment such as BEEP.
Regards

Carl

> location-unaware devices. I believe that the OBO functionality will be
> a great step forward from the static location info VoIP providers have
> to maintain today, until all VoIP devices are location-aware.
>
> For my purposes, HTTP is very appropriate, as it provides maximum
> re-use of existing software on CPE that is provided to end customers.
> I'm currently requiring support for DSL Forum TR-069 configuration
> mechanism on both VoIP devices and broadband routers. This mechanism
> uses RPC calls with XML/SOAP/HTTP(S). Many of these devices also
> support UPnP, which uses XML/SOAP/HTTP. I have nothing that does BEEP
> in any way shape or form.
>
> me. But I really want to see HTTP supported, in order to maximize
> re-use of existing software, and not force CPE vendors to implement a
> different protocol (like BEEP) just for location discovery. And I'd
> prefer to minimize the number of protocols that LIS servers will need
> to support (i.e., prefer not to support both BEEP and HTTP).
>
> Barbara
>
> better to consider alternatives?  BEEP for example?  A real web
> service? A
> new protocol?
>
> 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. 162
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 04 Aug 2005 03:27:11 -0400

Independent of the merit of HELD:

My perception is that very small HTTP servers are available on almost 
any conceivable platform, from plug-size processor-in-Ethernet-plug on 
up. Almost all modern network equipment already has embedded HTTP 
servers for network management.

BEEP seems to be mostly used by a small group of people associated with 
certain working groups and has almost no commercial support. I don't see 
how it could be significantly simpler given that it requires XML 
processing. (HELD and similar would not, as it simply delivers a 
fixed-format response, which you could implement with sprintf if you 
wanted to.)

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Aug 2005 08:51:15 -0500

At 12:04 PM 8/3/2005 -0500, Stark, Barbara wrote:

>meeting my needs.

Can you articulate why DHCP does not meet your needs?

>A L7 solution is exactly what I want and need,

I'm trying to understand how you have jumped to the conclusion that an L7 
protocol is "what you want and need" if the requirements have not been 
either agreed upon and worked out. Can you explain this from your point of 
view?

>both
>for getting location info to location-aware broadband routers

"location-aware broadband routers"

Can you tell me what these are to you?

In other words, is this *router* an ESRP or a DSL modem?

>and VoIP
>location-unaware devices.

How is the location of an endpoint "discovered" if there is zero indication 
in the SIP INVITE message that is *to* 911?

And if there is no location of the endpoint known, how is the SIP message 
ever routed correctly?

>I believe that the OBO functionality will be a
>great step forward

I am still attempting to figure out how it can work.

>Barbara

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Aug 2005 12:30:56 -0400

On Aug 4, 2005, at 3:27 AM, Henning Schulzrinne wrote:

> My perception is that very small HTTP servers are available on  
> almost any conceivable platform, from plug-size processor-in- 
> Ethernet-plug on up. Almost all modern network equipment already  
> has embedded HTTP servers for network management.
>
> BEEP seems to be mostly used by a small group of people associated  
> with certain working groups and has almost no commercial support. I  
> don't see how it could be significantly simpler given that it  
> requires XML processing. (HELD and similar would not, as it simply  
> delivers a fixed-format response, which you could implement with  
> sprintf if you wanted to.)

I find the generalizations in this conversation to be troublesome  
and, depending on what is needed, to be misleading.

Yes, there are HTTP servers that fit on small platforms.  And yes,  
there are many an HTTP libraries.  But that should not be all that is  
considered.  I recently did a survey of popular HTTP client libraries  
and learned that common HTTP implementation do not support two  
features that have been standardized and that my application needed.   
The focus should not be on easy spec writing but on getting the job  
done correctly and properly.

Additionally, this conversation is being partially conducted under  
the context of emergency services.  Because of the importance of it,  
any use of HTTP for this application MUST take into consideration BCP  
56.

BTW, with regard to BEEP having no commercial support, I'm sure that  
both Apple and IBM should be notified of their re-classification to  
non-profit status.

-andy