Re: [Sip] RE: [Geopriv] Henning's Suggestion

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Thu Jul 27 2006 - 14:53:24 EDT

At 09:44 AM 7/27/2006 -0500, Marc Berryman wrote:
>Sounds like Hannes and Henning are moving down the right track. Focusing
>on the location header syntax for the draft.

Mark

Defining syntax alone doesn't satisfy the SIP requirements for any SIP
extension within RFC 4485, which require per element behaviors be described
too (section 4.7 I believe), which are not exactly the same per SIP request
type, or per call intent type (e2e vs. proxy-routing) which gets use back
to a better version of the -03 ID we have, that the authors have committed
to submitting in the first half of August.

>Marc B
>
>-----Original Message-----
>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>Sent: Thursday, July 27, 2006 9:35 AM
>To: Dawson, Martin
>Cc: IETF SIP List; geopriv@ietf.org; 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:hgs@cs.columbia.edu]
> >>Sent: Thursday, 27 July 2006 1:25 PM
> >>To: Brian Rosen
> >>Cc: IETF SIP List; geopriv@ietf.org
> >>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:andy@hxr.us]
> >>>>Sent: Wednesday, July 26, 2006 9:58 PM
> >>>>To: Winterbottom, James
> >>>>Cc: sip@ietf.org; geopriv@ietf.org; 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
> >>>>Geopriv@ietf.org
> >>>>https://www1.ietf.org/mailman/listinfo/geopriv
> >>>
> >>>
> >>>_______________________________________________
> >>>Geopriv mailing list
> >>>Geopriv@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >>
> >>_______________________________________________
> >>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]
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> >
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>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 sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Jul 2006 13:53:24 -0500

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 15:00:06 EDT