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

At 04:33 PM 8/24/2006 +0200, Drage, Keith \(Keith\) wrote:
>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?

god I hope not....  : (


>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]
> >
>
>_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
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