RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol

From: Ted Hardie ^lt;>
Date: Thu Jul 27 2006 - 21:53:27 EDT

Hi Martin,
        Having not seen your note, I already took a stab
it, along much the same lines you suggest. Clearly, the attached
-00 (not yet in the drafts directories) is the barest of bare bones,
but I thought it might be useful to sketch that out as a contrast
to some of the real applications which might use HTTP as a
using protocol.
        I believe this also differs from RELO in that it is
focused on the transport of PIDF-LO, which is slightly different
from RELO's remit. But clearly, there are strong connections there.
        And if the phrase "strawman" in the title doesn't
signal that I don't think this is a done piece of work, allow
this too.
                                Ted Hardie

At 7:50 PM -0500 7/27/06, Dawson, Martin wrote:
>Hi Andy,
>I'll take a stab at it. Not that HTTP is a valid *using protocol* but,
>rather, that the location reference does not actually identify a using
>protocol and, in fact, HTTP would only be the transport protocol...
>3693 states:
> The "using protocol" is the protocol that uses (reads or modifies)
> the Location Object. A protocol that just transports the LO as a
> string of bits, without looking at them (like an IP storage protocol
> could do), is not a using protocol, but only a transport protocol.
> Nevertheless, the entity or protocol that caused the transport
> protocol to move the LO is responsible for the appropriate
> distribution, protection, usage, retention, and storage of the LO
> based on the rules that apply to that LO.
>A location reference which provided an HTTP URI indicates that the
>entity that is going to be used to request the LO is to be communicated
>with using HTTP. Because of the rules associated with the PIDF-LO, it
>can be inferred that the entity and whatever semantics are associated
>with the HTTP communications with that entity will honor the
>requirements. That is, HTTP is only the transport protocol. An HTTP GET
>has to be interpreted by the receiving entity within the scope of a
>using protocol - with its associated set of rules and semantics - which
>go beyond HTTP and which do respect the geopriv requirements. Indeed,
>this is generally the case - sending an HTTP GET to an arbitrary IP node
>can yield any number of results depending what that node actually does.
>The client needs to understand the purpose of that server in the scope
>of some higher level protocol.
>To use another example, a location reference could be an IP address.
>There's nothing inherent in IP that honors the geopriv rules, but that
>doesn't stop the reference being valid nor say that the protocol used
>between a client and that IP address would not honor the rules.
>The purpose of the SIP conveyance specification is to say how a LO or
>reference can be transferred from one entity to another using SIP. It's
>out of scope for a SIP specification to mandate anything about the
>transport protocol or to infer anything about using protocol implied by
>that transport. As has been previously mentioned, this would be subject
>to separate specification and BCP - lest the SIP conveyance
>specification become overly rigid and subject to unnecessary maintenance
>and churn.
>> -----Original Message-----
>> From: Andrew Newton []
>> Sent: Thursday, 27 July 2006 10:45 PM
>> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol
>> There have been a number of opinions regarding HTTP as a using
>> I'd like to know, how many people believe that HTTP requires no or
>> very little specification to meet the requirements in RFC 3693 and
>> RFC 3694. If you believe this, what basis do you have for this
>> conclusion? Or do you believe more specification needs to be done,
>> but it is possible for HTTP to be a GEOPRIV using protocol?
> >
>> Finally, how many people believe that HTTP should not be a using
>> protocol?
>> -andy
>> _______________________________________________
>> Geopriv mailing list
>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.
>Geopriv mailing list

Geopriv mailing list

Received on Thu, 27 Jul 2006 18:53:27 -0700

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 22:09:33 EDT