RE: RE: [Geopriv] More on the contents of the Location header URI- http

Suppose the L7 protocol defines an optional parameter foo.

What is the dereferencer to do?  If it tries foo, but the URI is to a raw
GET processor, it will get a generic error.  There is nothing else it could
do though, since it can't tell from anything it has that foo is optional,
but legal.

A registry and a parameter would tell it that foo is legal (if it was an L7
protocol URI).

I'm not excluding a simple GET; I'm just advocating a parameter and a
registry that says it IS a simple GET.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:[email protected]]
> Sent: Wednesday, July 19, 2006 8:15 PM
> To: Rosen, Brian; Brian Rosen; [email protected]
> Cc: [email protected]
> Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location
> header URI- http
> 
> 
> What it means is that you MUST provide a Get mechanism with no
> parameters, you MAY provide anything you like on top of that. If you are
> prepared to take the hit with trying something specific first then that
> is your prerogative, or you may decide to do the GET first, and
> something special as a second-try, which is also okay. I simply don't
> agree with your reasoning to exclude a simple GET mechanism now.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email protected]]
> > Sent: Thursday, 20 July 2006 10:09 AM
> > To: Winterbottom, James; Brian Rosen; [email protected]
> > Cc: [email protected]
> > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location
> > header URI- http
> >
> > Actually, it means that a base GET/return PIDF is ALL you could
> > implement; you can't get anything back from the PIDF that would tell
> you
> > anything else is acceptable, and you can't tell from the URI.
> >
> > That would mean a SOAP based mechanism could never be specified, for
> > example.  You couldn't have an optional parameter unless you were
> > prepared to try it, have it fail, and then try something else.
> >
> > Brian
> >
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:[email protected]]
> > > Sent: Wednesday, July 19, 2006 8:00 PM
> > > To: Brian Rosen; Rosen, Brian; [email protected]
> > > Cc: [email protected]
> > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the
> Location
> > > header URI- http
> > >
> > > Providing all mechanisms support a base GET AND they return a
> PIDF-LO
> > > there is no problem. That is all that needs to be said.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:[email protected]]
> > > > Sent: Thursday, 20 July 2006 9:52 AM
> > > > To: Winterbottom, James; Rosen, Brian; [email protected]
> > > > Cc: [email protected]
> > > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the
> > Location
> > > > header URI- http
> > > >
> > > > The problem is that HTTP is used as a transport protocol by
> several
> > > > mechanisms, and you need to know from the contents of the location
> > > header
> > > > which mechanism is used.  Is it SOAP, raw GET, LCP, RELO, HELD or
> > > > something
> > > > else, all of which would say "https:blahblah"?
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Winterbottom, James [mailto:[email protected]]
> > > > > Sent: Wednesday, July 19, 2006 7:26 PM
> > > > > To: Rosen, Brian; [email protected]
> > > > > Cc: [email protected]
> > > > > Subject: [Sip] RE: [Geopriv] More on the contents of the
> Location
> > > header
> > > > > URI- http
> > > > >
> > > > > Brian,
> > > > >
> > > > > I am not sure that I agree with you on this one.
> > > > > The problem is not in the request protocol at all, the GET works
> > > fine
> > > > > providing the return type is always a PIDF-LO.
> > > > >
> > > > > Cheers
> > > > > James
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rosen, Brian [mailto:[email protected]]
> > > > > > Sent: Thursday, 20 July 2006 7:33 AM
> > > > > > To: [email protected]
> > > > > > Cc: [email protected]
> > > > > > Subject: [Geopriv] More on the contents of the Location header
> > URI
> > > -
> > > > > http
> > > > > >
> > > > > > I started a discussion of what can be in the location header
> > > besides a
> > > > > > cid:.
> > > > > > We remain convinced that AbsoluteURI is a poor choice; we must
> > be
> > > more
> > > > > > specific, including privacy concerns.
> > > > > >
> > > > > > It is now clear that simply saying "https:" is not enough.
> > There
> > > > > could
> > > > > > be multiple location resolution protocols that use http
> > transport.
> > > We
> > > > > > need something else that would differentiate which one.  The
> > > simple
> > > > > GET
> > > > > > mechanism we proposed would need at least a parameter of some
> > > sort.
> > > > > >
> > > > > > After thinking about it for a while, I think the best
> resolution
> > > is
> > > > > > Andy's suggestion of a registry, used in conjunction with a
> > > parameter.
> > > > > > I'm ambivalent on whether the parameter is a URI parameter or
> a
> > > > > > parameter on the Location header.  We would define the
> registry
> > > (and
> > > > > the
> > > > > > parameter) in location-conveyance and create one entry (the
> > simple
> > > GET
> > > > > > with PIDF-LO return).  It may be, for example, that the
> proposed
> > > L7
> > > > > > location acquisition protocol defines another http based
> > > resolution
> > > > > > protocol.  That document could define another entry in the
> > > registry.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > --
> > > ----------------------
> > > 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]


_______________________________________________
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