RE: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance)

From: Drage, Keith \(Keith\) ^lt;drage@lucent.com>
Date: Thu Jul 27 2006 - 10:39:34 EDT

(as individual)

It's a GEOPRIV problem to identify what height the bar is. At least my
understanding is that Presence was a location using protocol and the
level of documentation was agreed by GEOPRIV. That makes the bar around
at least informational RFC required.

For use in location by reference I believe we have two criteria to meet:

i) the dereferencing protocol must be a geopriv using protocol

ii) if we have more than one option, we either need some means of
determining that the dereferencer supports the one the client chooses to
use, or require support of all options. As we seem to be lacking any
mechanism for the former, then it would imply that all options have to
be supported at the dereferencer, and therefore that the list needs to
be a small list.

Regards

Keith

> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: 27 July 2006 06:00
> To: Andrew Newton
> Cc: IETF SIP List; GEOPRIV
> Subject: RE: Teasing apart positions (was Re: [Sip] RE:
> [Geopriv] Consensusonchanges to location-conveyance)
>
> Since I raised the question, I'll answer.
>
> We have a set of requirements on a using protocol in RFC 3693.
>
> I believe that HTTP with proper constraints (TLS, etc...) can
> meet, or already meets, those requirements. That is
> irrespective of any decisions that need to be made about
> secondary concerns like whether HTTP is desirable, optimal,
> deployable etc... However, it is clear that people aren't
> happy with this position and are requesting that this be
> documented, as an RFC. Just to get it all out in the open.
> Presumably this would be a standards track RFC that, like
> location-conveyance, highlights how the RFC 3693 requirements
> are addressed.
>
> That's a sound argument, and obviously location-conveyance
> had to meet that standard for us to be happy. Now, I ask
> that you go back, take the above paragraph and perform one
> simple operation and read it again: s/HTTP/SIP/g. Is the
> argument any different in the presence of RFC 4079? Is an
> informational RFC that doesn't address specific requirements
> adequate? I'd suggest that it wouldn't make the grade for HTTP.
>
> > -----Original Message-----
> > From: Andrew Newton [mailto:andy@hxr.us]
> > Sent: Thursday, 27 July 2006 1:55 PM
> > To: IETF SIP List; GEOPRIV
> > Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv]
> > Consensus onchanges to location-conveyance)
> >
> >
> > On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote:
> > > The authors would like to know what to do now.
> >
> > Let's start by trying to tease apart certain positions.
> >
> > Given Jon Peterson's message:
> > http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html
> >
> > Does anybody still believe that subscriptions to PIDF-LOs with pres:
> > requires more definition?
> >
> > -andy
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > 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]
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Jul 2006 16:39:34 +0200

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 10:45:28 EDT