RE: RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined

Hi Keith,

1. I disagree that a HTTP URI indicates anything about the using
protocol other than the transport it uses. HTTP is the transport. A SIP
URI could equally indicate a SIP transport but with a set of protocol
semantics that do not honor the geopriv requirements.

2. No - as above - the reference URI does not convey information about
the nature of the user protocol that the referenced server is going to
support. Also, even if the URI did indicate the nature of the using
protocol, it is not appropriate to have to continually update a SIP
document every time a new geopriv compliant user protocol is invented.
The SIP conveyance cannot assure anything about the integrity of the
using protocol supported by the referenced server and it should not
imply that it can. Services that are provided for the purpose of
location object conveyance will need to be assessed themselves as to
whether they meet the geopriv constraints.

3. I think geopriv could maintain a document of *actual using protocols*
that are considered to meet the geopriv constraints. Noting that listing
the actual protocols also conveys more than the type of URI that could
be used to reference a server supporting those protocols. At least,
then, there would be a single place to maintain this information and the
SIP specification can simply state that the URI, whatever its form, must
be a reference to a server which supports a using protocol that honors
geopriv constraints - as could every one of the other protocols that I
would certainly hope are going to be able to convey a location reference
- and without having to be updated every time a new using protocol is
defined.

Cheers,
Martin

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email protected]]
> Sent: Wednesday, 16 August 2006 4:32 AM
> To: Dawson, Martin; Andrew Newton; Winterbottom, James
> Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have
> anHTTPdereferencemechanism defined
> 
> I must admit I am still having trouble working out what your position,
> and that of Henning and James W. is.
> 
> 1)	The dereferencing protocol is a using protocol according to the
> GEOPRIV RFCs. I assume that GEOPRIV is therefore going to require that
> such a using protocol meets their requirements. HTTP in its current
form
> does not meet those requirements. Is there anything here you disagree
> with?
> 
> 2)	So then we get to the step of should the URI conveyance police
> the using protocol that can be used, which is essentially what Brian
is
> proposing. I certainly understand that it should be policed somewhere,
> and if it is not policed by the syntax of the protocol, it either has
to
> be policed by the dereferencer, or by the location provider itself.
> Where do you stand on this? To me it seems automatic to police it by
the
> types of URI that are allowed to be used, and therefore I need to
> understand how you see this.
> 
> 3)	If you agree that we police by the types of URI to be used, is
> the problem here then that GEOPRIV rather than SIP should write the
> document that makes these constraints?
> 
> Regards
> 
> Keith
> 
> 
> 
> > -----Original Message-----
> > From: Dawson, Martin [mailto:[email protected]]
> > Sent: 01 August 2006 06:14
> > To: Andrew Newton; Winterbottom, James
> > Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance
> > have anHTTPdereferencemechanism defined
> >
> > I'm OK as long as the ABNF includes the AbsoluteURI option
> > and the text does not say anything specifically about
> > excluding HTTP (or any other form of URI).
> >
> > I've attempted to point out previously that the URI doesn't
> > actually convey anything about whether the geopriv rules are
> > going to be respected or not. It's actually a geopriv rule
> > that those rules be respected so it's superfluous, and out of
> > scope, to also require the statement in a SIP conveyance document.
> >
> > AbsoluteURI as a generic form, encompasses sip etc. anyway,
> > so it's also superfluous to include those in the ABNF.
> > However, it's also a harmless waste of space. If Brian is
> > keen to include them for some reason, and as long as neither
> > the text nor the ABNF bias the specification toward those
> > forms in any way, then there are certainly better things to
> > lose sleep over.
> >
> > Cheers,
> > Martin
> >
> > > -----Original Message-----
> > > From: Andrew Newton [mailto:[email protected]]
> > > Sent: Tuesday, 1 August 2006 11:15 AM
> > > To: Winterbottom, James
> > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> > > Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an
> > > HTTPdereferencemechanism defined
> > >
> > >
> > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote:
> > >
> > > > Hi Andy,
> > > >
> > > > That is all I have asked for, do not constrain the ABNF.
> > If "how I
> > > > use HTTP as a reference" goes in a different document
> > that is fine
> > > > providing the ABNF is not constrained in the conveyance
> > > > specification. This is not how I read Brian's statement below:
> > > >
> > > > "This is NOT the discussion of what the ABNF of the
> > location header
> > > > looks like (although it would NOT have http/https in it
> > for sure if
> > > > we
> > agree
> > > > that an HTTP dereference protocol is a separate draft)."
> > > >
> > > > Which to me clearly says the ABNF will be restrict to
> > exclude HTTP/
> > > > HTTPS if there is agreement that the conveyance draft
> > doesn't have
> > > > specific text on how to deference an HTTP reference.
> > > >
> > > > Cheers
> > > > James
> > >
> > > Please keep in mind that this does not stop the draft from
> > using MUST/
> > > SHOULD language from stipulating "the URI MUST be a GEOPRIV
> > standards
> > > track using protocol."
> > >
> > > -andy
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > --------------------------------------------------------------
> > ----------------------------------
> > 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]
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >

------------------------------------------------------------------------------------------------
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]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip