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

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Fri Aug 25 2006 - 21:02:11 EDT

I certainly don't think a normative reference is necessary. It could
normatively reference the existing Geopriv document that says what the
requirements are for a using protocol.

As James P's reaction indicated, maintaining such a document would be a
pain in the fundament. And, so, if it's not something that is considered
reasonable to do (given the rules for what constitutes a valid using
protocol are documented at the meta-level) as a geopriv document, why on
earth would a SIP conveyance document take it upon itself to represent a
definitive list of valid using protocols?

Just to make this clear - there are several versions of using protocols
that support a reference mechanism under development and proposal. And,
hey, some are not even in the IETF domain. They may well use a transport
other than SIP, but can still get acceptance and ratification as meeting
the requirements of a using protocol. The last thing we need is to then
have the protocol police saying "well sorry, you can't send one of those
references, the *SIP* standard doesn't recognize it. You'll have to go
through a couple of years of more tedious debate to get it added to the
conveyance spec." That's not actually even in the interests of SIP.

Cheers,
Martin

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: Friday, 25 August 2006 12:33 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
>
> 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:Martin.Dawson@andrew.com]
> > 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:drage@lucent.com]
> > > 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:Martin.Dawson@andrew.com]
> > > > 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:andy@hxr.us]
> > > > > 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
> > > > > Geopriv@ietf.org
> > > > > 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
> > > > Geopriv@ietf.org
> > > > 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]
> >

------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 25 Aug 2006 20:02:11 -0500

This archive was generated by hypermail 2.1.8 : Fri Aug 25 2006 - 21:24:30 EDT