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

So in order to complete, we therefore need a new GEOPRIV draft that
defines the list of dereferencing protocols, and which location
conveyance will normatively reference?

Regards

Keith 

> -----Original Message-----
> From: Dawson, Martin [mailto:[email protected]] 
> Sent: 16 August 2006 09:25
> To: Drage, Keith (Keith); Andrew Newton; Winterbottom, James
> Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> Subject: RE: [Sip] 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