[Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

Adrian Georgescu <ag@ag-projects.com> Wed, 22 October 2008 09:41 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911DE28C153; Wed, 22 Oct 2008 02:41:55 -0700 (PDT)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2C528C148 for <sipping@core3.amsl.com>; Wed, 22 Oct 2008 02:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level:
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL+eshF5wo9i for <sipping@core3.amsl.com>; Wed, 22 Oct 2008 02:41:53 -0700 (PDT)
Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 581F228C154 for <sipping@ietf.org>; Wed, 22 Oct 2008 02:41:52 -0700 (PDT)
Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from <ag@ag-projects.com>) id 1KsaBN-0000Qd-US; Wed, 22 Oct 2008 11:39:15 +0200
Message-Id: <75F68726-92DB-4D63-8087-C91A4C57F987@ag-projects.com>
From: Adrian Georgescu <ag@ag-projects.com>
To: sipping@ietf.org
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 11:42:49 +0200
X-Mailer: Apple Mail (2.929.2)
X-SA-Exim-Connect-IP: 80.101.96.20
X-SA-Exim-Mail-From: ag@ag-projects.com
X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000)
X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info)
Subject: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hi Paul,

I believe Henry is heading into one direction only. The idea is to  
help developers implement the minimum necessary features in their User  
Agent and not biased towards a voice only application. The SIP end- 
points as describe by Henry would work with any service provider as  
long as they talk plain SIP. So 911 and voicemail and other services  
can be performed in the network as well, they are just another end- 
point.

If I were to develop a SIP UA today (which  I do actually) Henry's  
draft would be the starting point. I would definitely add MSRP to it,  
without relays as a minimum but adding relay extension is not that  
difficult, because any application that requires reliable or large  
data transport need a TCP media plane that SIP signalling or RTP does  
not provide. End-to-end encryption can also be realized on top of  
established MSRP session. File transfer and session based IM are  
applications that an end user would take for granted today and SIP  
lacks both.

Also the rich presence conflicts with the basic presence PIDF, I would  
go for rich presence even if the "richness" of the information is  
something that would be avoided due to its complexity in the  
presentation to end-user interface.

For the rest I would not do much changes to the draft.

Regards,
Adrian

 >>>>>>>>




Henry,

Based on this discussion, it now sounds like you are heading in *two*
directions:

- connecting to a SP that provides services (e.g. 911, maybe others,
    like voicemail, forwarding, ...)
    The SP in this case is largely looking for a "dumb" device and
    provides the services in the network. The "request for service"
    is then "tunneled" via simple services like invite, with the
    service request encoded in the AOR. (e.g. the "911", or "star"  
codes).
    In this case you are then competing with other profiles, such as
    SIPConnect or PacketCable.

- very low added value SP, that simple provides registration
    and routing. All services are provided by the UAs.

I'd like to see the goals spelled out better. Then we can discuss if
they are met.

	Thanks,
	Paul

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP