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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 27 Jul 2006 16:39:34 +0200

(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-masked]] 
> 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-masked]]
> > 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-masked]
> > 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2006 11:33:39 -0400

> be supported at the dereferencer, and therefore that the list needs to

This isn't quite true. It is quite possible to include multiple options, 
as long as one of them is universally supported. For example, you can 
support a "universal & slow" and a "sometimes & fast" solution, and 
everybody wins.

This approach is not new: MIME email does exactly that, where messages 
with HTML or rich text often also contain an alternate plain text rendering.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 17:35:49 +0200

Hi Keith,

> at least informational RFC required.

The presence based using protocol we did was meant to be used in a 
different environment. Let me point you to one main difference: The Rule 
Maker had a relationship with the Location Server. The Rule Maker might, 
in many cases, be the Target. In the discussions about a 
location-by-reference being added by a SIP proxy this is not the case.

I strongly believe that there is not a single 1-to-1 translation between 
the presence work and the work we do here when it concerns 
location-based routing as argued in other mails. You can convince me 
that this is not true (and you would probably also solve our Geopriv-L7 
  challenge as a side effect).

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

Where do these requirements come from?

> i)	the dereferencing protocol must be a geopriv using protocol

I think that there is a terminology problem here.

> be supported at the dereferencer, and therefore that the list needs to
This is indeed an issue but seems to be similar to the topics we deal 
with in the phone BCP.

In fact we already have this problem today if I understood 
draft-hdesinen-geopriv-pidflo-extn-00.txt correctly.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jul 2006 13:56:38 -0500

>support a "universal & slow" and a "sometimes & fast" solution, and 

Are you saying that the doc now has to state that more than one schema has 
to be supported within the same Location header?