RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol

I guess that I was trying to be inflammatory. ;)

What would be nice on your strawman is a hat, a pipe, a carrot nose and some eyes.  That is, I don't think it's complete as a strawman until you address the RFC 3693 requirements.  The lawyering has devalued the term "using protocol" but I still see value in the underlying requirements - evidently you do too.  Irrespective of whether it's a "using protocol" or not, it needs to provide some level of privacy protection.

We can quibble over terminology, but I'd prefer to see this address the requirements.

Req 1. See RFC 4119
...
Req 6. Interesting one... I'd suggest that this might not be very easy to meet. 
Req 7. ...

That would be a better strawman for me.  Aside from Req.s 6 and maybe 15.3 I don't think you will have to equivocate to meet the requirements.

> -----Original Message-----
> From: Ted Hardie [mailto:[email protected]]
> Sent: Friday, 28 July 2006 3:29 PM
> To: Thomson, Martin; Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV
> Subject: RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol
> 
> At 11:14 PM -0500 7/27/06, Thomson, Martin wrote:
> >
> >Or, are we above the scrabbling for loopholes - after all we[1] wrote the
> rules, we know the reasons for the rules[2], so why are we playing games
> with definitions?  This is avoiding RFC 3693, and I'm guilty of that[3]
> (if I recall, you told me to stop).  Why not simply address the
> requirements?
> >
> >The point that Martin (D) was making is related to the fact that
> conveyance doesn't have to specify how a reference is used.  That doesn't
> mean that it doesn't have to be specified at all, but SIP can treat this
> as opaque data (except cid:, of course).
> >
> >Cheers,
> >Martin
> 
> Going through 3693 again was what inspired me to put up a strawman.  I
> hope
> setting it alight gets us some light and not too much heat.
> 
> My own reading says that if you want to use HTTP as a transport of PIDF-
> LO, rather
> than as a using protocol, you have to use it in a way that protects the
> privacy
> of the object in flight (encrypting TLS in the strawman, but it could be
> mandating
> s/mime or something else), and you have to be sure that the parties
> transporting
> it are authenticated to each other (to protect against monkey-in-the-
> middle attacks
> as a start).
> 
> More importantly, you have to use it in a protocol context where it is
> handed off
> after transport to some other protocol or application which then does the
> real
> work of reading or modifying the object and of obeying the rules.  To me
> that
> means that it can't be used in this way loosely--just implementing this
> strawman
> and calling it a using protocol would be utterly bogus, since once it
> arrives
> at the client, you haven't said what to do with it all or how the geopriv
> requirements are met.  But I think it *might* be valid in very specific
> protocol
> contexts where you have said what happens when the *using protocol*
> (SIP, in this example) does from there.
> 
> It may be, of course, that I was thinking to hard and need to take a bit
> of
> a lie down to recover.  But I thought about the URI schemes which encode
> data in the URI itself, and I thought:  how can those be using protocols?
> Obviously, they aren't; they're just ways of carrying the data around for
> the benefit of real using protocols.  If that is the case, we may be able
> to do something simple to specify how to use a suitably protected
> transport
> to dereference a URI rather than carrying the data inside the using
> protocol.
> But I think that this fundamentally requires that the
> transport/dereference
> occur in a very bounded protocol context inside the real using protocol.
> Otherwise, you are absolutely right that it is just an end-run.
> 
> To re-iterate:  this a strawman; feel free to rip up the innards and use
> as
> a pillow, flammable materials, or use as you see fit.  I won't be offended
> if
> the response is any of the above.
> 			regards,
> 				Ted
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

------------------------------------------------------------------------------------------------
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