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











_______________________________________________
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