Re: [Sip] SIPit 20 survey summary

"Frank W. Miller" <fwmiller@cornfed.com> Sat, 28 April 2007 23:24 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhwGo-00084p-OC; Sat, 28 Apr 2007 19:24:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HhwGm-00084f-Bo for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 19:24:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhwGm-00084X-2L for sip@ietf.org; Sat, 28 Apr 2007 19:24:00 -0400
Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhwGj-000340-SW for sip@ietf.org; Sat, 28 Apr 2007 19:23:59 -0400
Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id D541F75805B; Sat, 28 Apr 2007 18:23:56 -0500 (CDT)
Subject: Re: [Sip] SIPit 20 survey summary
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com> <001401c78976$5f8dc020$0601a8c0@BEMBUSTER> <17971.5486.819002.96466@tutpro.com> <CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
Content-Type: text/plain
Date: Sat, 28 Apr 2007 17:23:42 -0600
Message-Id: <1177802622.3020.8.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 'IETF SIP List' <sip@ietf.org>, discussion@sipforum.org, Juha Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu, 'Robert Sparks' <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Acknowledged.  However, if we're talking about adding messaging
infrastructure to SIP, then the discussion is quite relevant here.  I
for one would vote for a simpler mechanism than multipart MIME XML blah
blah blah.  With regards to Keith's comments, I would love to sit down
and provide an alternative proposal but I just don't have the time to do
it.  With all due respect, I'll implement whatever the standards
committee comes up with, but I don't think its unreasonable for me or
anyone else to express concern about protocol that is obviously designed
by committee and obviously more complicated that it probably has to be.

FM


On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
> There has been an incredible amount of work on this topic across many  
> standard organizations including the IETF. Before people start in on  
> discussing this in - I strongly suggest they might want to read some  
> of the requirements, uses cases, drafts, and mailing list discussions  
> in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/ 
> GEOPRIV/SIP and take the discussion to the right working group.
> 
> 
> On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
> 
> > Jeroen van Bemmel writes:
> >
> >> Especially for the use case of emergency calls, would it not be  
> >> wise to
> >> select a much more simple approach/syntax, e.g.:
> >> Emergency-Location: lat=x; lon=y
> >>
> >> So no XML, no mime/multipart, as simple as possible (no complex  
> >> semantics,
> >> usage-rules etc), something to reduce the barrier of
> >> implementation/deployment, and to reduce the risk for interop issues?
> >
> > i fully agree with this.  we should follow KISS principle here.  it is
> > highly unlikely that sip ua vendors will even TRY implement such a
> > complex protocol.
> >
> > another reason why it will not get implemented is that sip uas don't
> > know where they are located.  gps does not work well indoors and  
> > mobile
> > operators at least here have refused to make public coordinates of  
> > their
> > base stations.
> >
> > -- juha
> >
> >
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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



_______________________________________________
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