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

(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:[email protected]] 
> 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:[email protected]]
> > 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
> > [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