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

Hannes Tschofenig <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.geopriv
Message-ID <[email protected]>
Hi Keith,

Drage, Keith (Keith) wrote:
> (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.

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.

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


> 
> 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]
>>
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 


_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.