Re: 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]


_______________________________________________
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