RE: RE: [Geopriv] Consensus on changes to location-conveyance

This gets my vote.
Barbara

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email protected]]
> Sent: Wednesday, July 26, 2006 11: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
> 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162



_______________________________________________
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