RE: [Geopriv] Henning's Suggestion

Sounds like Hannes and Henning are moving down the right track. Focusing
on the location header syntax for the draft.



Marc B

-----Original Message-----
From: Hannes Tschofenig [mailto:[email protected]] 
Sent: Thursday, July 27, 2006 9:35 AM
To: Dawson, Martin
Cc: IETF SIP List; [email protected]; Henning Schulzrinne
Subject: [Geopriv] Henning's Suggestion

Hi Henning,

I like your suggestion.

In fact I would even go a step further. The SIP Location Conveyance 
document just defines a mechanism to carry a PIDF-LO in the body of the 
SIP message. Done.
Adding location-by-reference to the SIP header by the end host sounds OK

but there are still some loose ends where this reference comes from.

The other stuff can be dealt with once we concluded our Geopriv-L7 work 
where all the architectural pieces should are created. The 
subscription-URI is an example where we recently proposed something and 
haven't finished our technical discussions.

I think the draft got fuzzy when it came to the area where a SIP proxy 
adds a location-by-reference. I must admit that I proposed to add 
location-by-value into the SIP header as well but in the meanwhile I 
don't think that any of the SIP proxy stories belong in there.

Ciao
Hannes

>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:[email protected]]
>>Sent: Thursday, 27 July 2006 1:25 PM
>>To: Brian Rosen
>>Cc: IETF SIP List; [email protected]
>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
>>conveyance
>>
>>My suggestion would be
>>
>>- to focus the draft on just defining the Location header syntax,
>>without ruling out any particular mechanism or scheme; this would
>>make the draft really short (which I would find helpful).
>>
>>- and then add one section to the draft that prototypically defines
>>what a particular scheme that wants to appear in the Location header
>>needs to define, using the non-controversial cid mechanism as the
>>example. Other, separate, drafts can then define other modes,
>>following the same template. Documents such as the phone-bcp can then
>>pick some suitable must-implement subset and make emergency-call-
>>specific recommendations, rather than sprinkling these throughout the
>>conveyance document and repeating some in the phone-bcp. Most of
>>these are, in any event, operational recommendations, not for
>>ensuring protocol-level interoperability.
>>
>>That way, the conveyance draft can be extremely short (even shorter
>>if the requirements are omitted...) and can get done, and we avoid
>>engineering operational requirements on the fly, commingling
>>emergency and non-emergency cases, as seems to be happening now.
>>
>>I think protocol documents should define what's needed for
>>interoperability; BCPs can make more specific, situation-specific
>>recommendations. Commingling the two seems to be a recipe for
>>deadlock or arbitrary, non-technically-grounded decisions that are
>>more lawyer-like than engineering-like ("you did not mention
>>technique X in some meeting N years ago and thus you can't bring it
>>up now!")
>>
>>Henning
>>
>>On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote:
>>
>>
>>>At this point, I think we need some chair guidance and by that I
>>>think it's
>>>a combo of geopriv and sip chairs.
>>>
>>>We seem to have a couple of significant open questions.  I think
>>>most of the
>>>other stuff (like the "allow sending to router") will converge.
>>>
>>>There seems to be some opposition to allowing sip/sips/pres: in a
>>>Location
>>>Header.  The opposition seems to be that despite 4119, somehow, SIP
>>>(presence subscription) is not a "using protocol".  I "think" a
>>>ruling from
>>>the bench on that would work.
>>>
>>>There is also opposition to defining the allowed schemes as a
>>>specific list,
>>>with a defined (easy) extension mechanism.
>>>
>>>Related to that, there are some who want location-conveyance to
>>>define an
>>>HTTP based location dereference mechanism, and on the opposite end,
>>>we have
>>>people saying we haven't even agreed to support any form of
>>>location-by-reference.
>>>
>>>The authors would like to know what to do now.
>>>
>>>Brian
>>>
>>>
>>>>-----Original Message-----
>>>>From: Andrew Newton [mailto:[email protected]]
>>>>Sent: Wednesday, July 26, 2006 9:58 PM
>>>>To: Winterbottom, James
>>>>Cc: [email protected]; [email protected]; Abbott, Nadine B; Henning
>>>>Schulzrinne
>>>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
>>>>conveyance
>>>>
>>>>
>>>>On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote:
>>>>
>>>>
>>>>>Andy,
>>>>>
>>>>>RFC-4119 says "However, the usage of this location object format
> 
> is
> 
>>>>>not
>>>>>   limited to presence-using protocols-- any protocol that can
>>>>>carry XML
>>>>>   or MIME types can carry PIDF."
>>>>>
>>>>>It seems to me that restricting the allowed schema in what is
>>>>>supposed
>>>>>to be a location conveyance specification is in opposition to this
>>>>>statement.
>>>>
>>>>Did somebody say that HTTP was a presence-using protocol?
>>>>
>>>>-andy
>>>>
>>>>ps.  you can find my location with the following reference URIs:
>>>>
>>>>gopher://fatchance.hxr.us/you-still-have-a-gopher-client
>>>>news:alt.locations.people.secretly-being-watched
>>>>telnet://screen-scrapers.are.us/
>>>>dns:cached-publicly-around-the-world.com?type=HOST
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Geopriv mailing list
>>>>[email protected]
>>>>https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>>_______________________________________________
>>>Geopriv mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
>>
>>_______________________________________________
>>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
> 
> 


_______________________________________________
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