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

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 19 Jul 2006 19:14:38 -0500

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-masked]]
> Sent: Thursday, 20 July 2006 10:09 AM
> To: Winterbottom, James; Brian Rosen; [email-masked]
> Cc: [email-masked]
> 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-masked]]
> > Sent: Wednesday, July 19, 2006 8:00 PM
> > To: Brian Rosen; Rosen, Brian; [email-masked]
> > Cc: [email-masked]
> > 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-masked]]
> > > Sent: Thursday, 20 July 2006 9:52 AM
> > > To: Winterbottom, James; Rosen, Brian; [email-masked]
> > > Cc: [email-masked]
> > > 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-masked]]
> > > > Sent: Wednesday, July 19, 2006 7:26 PM
> > > > To: Rosen, Brian; [email-masked]
> > > > Cc: [email-masked]
> > > > 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-masked]]
> > > > > Sent: Thursday, 20 July 2006 7:33 AM
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > 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-masked]
> > > > > 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-masked] for questions on current
sip
> > > > Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 20:33:17 -0400

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

> Sent: Wednesday, July 19, 2006 8:15 PM
> To: Rosen, Brian; Brian Rosen; [email-masked]
> Cc: [email-masked]