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

"Drage, Keith \(Keith\)" <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.geopriv
Message-ID <[email protected]>
(as SIP WG chair)
(Warning - degree of rant is directly proportional to the value of the
item number, I decided that 6 through 10 were not publishable)

1)	I think we do have a significant amount of discussion and
agreement already that does need to be reflected in a revised draft. You
promised that revised draft in early August, and whatever the state of
the open issues, you should still provide that revised draft, and merely
indicate in the text that open issues exist in particular areas if they
do not get resolved before you hit the send button. We are certainly
getting repeats of comments that relate to stuff that will already be
addressed in the revised version.

2)	This document is making SIP a "using protocol" for location. Any
normative requirements in this document must be consistent with GEOPRIV
documentation in RFC 3693, RFC 3694, RFC 4079 and RFC 4119. Therefore if
comments are being made that are inconsistent with any of these
documents, then the commentors should in the first instance be
addressing their comments to GEOPRIV in terms of corrections to these
RFCs. I don't want a SIP document held hostage because someone either
refused to read a GEOPRIV document before it was approved, or at the
very least failed to understand what was written at that time. If it is
a question of interpretation of the GEOPRIV documents, then I guess
there is room for some discussion, but at least Jon Peterson, who played
a key role in this work in GEOPRIV, has indicated that the presence work
is a GEOPRIV using protocol. On that basis, I would allow him to hum
directly into the microphone if a hum was in progress on this one.

3)	Using protocols are sanctioned by GEOPRIV. If GEOPRIV has not
made a decision, then it does not exist as a using protocol!

4)	We are past the design stage on this document. The document has
had its current technical content for 12 months. In my view that raises
the bar somewhat. If something new is required in this document, then we
are not in the process of just adding it as yet another variant - if
only because that hits interoperability. I want to see clear statements
about why the current stuff does not work, and what is improved by the
new addition. In many cases, I am failing to see reasoned arguments
based on the GEOPRIV documents, or other IETF work, as to why something
is right or wrong - I do not want to see proposals based on general
feelings, or, "that is what I want to implement therefore it has got to
be included". 

5)	We still have to make decisions by concensus. We need consensus
to take something out, we need consensus to put something in. While the
editors do need to represent that consensus, they are also entitled to
their views on the discussion as individuals. At the end of the day, if
we fail to reach consensus about the document, then we kill either the
charter item, or the SIP WG itself.

Regards

Keith

> -----Original Message-----
> From: Brian Rosen [mailto:[email protected]] 
> Sent: 27 July 2006 04:08
> To: 'Andrew Newton'; 'Winterbottom, James'
> Cc: [email protected]; [email protected]; 'Henning Schulzrinne'; 
> 'Abbott, Nadine B'
> Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to 
> location-conveyance
> 
> 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
> 

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