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

Works for me...

-Marc- 

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

_______________________________________________
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