RE: [P2PSIP] What is a Service?

EdPimentl <edpimentl@gmail.com> Sat, 03 March 2007 13:19 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNU8q-0003Zz-HL; Sat, 03 Mar 2007 08:19:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNU8o-0003Zu-6S for p2psip@ietf.org; Sat, 03 Mar 2007 08:19:14 -0500
Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNU8k-0007Sl-Kz for p2psip@ietf.org; Sat, 03 Mar 2007 08:19:14 -0500
Received: by wr-out-0506.google.com with SMTP id i20so712655wra for <p2psip@ietf.org>; Sat, 03 Mar 2007 05:19:08 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=TLSRPHZBdOD7Xb8vJ1ZTGPZcJp/5BKmMK+mu2WOID1sDK8r3Lsde7ksIs9hw34+3NH0YD/dXVdhD7J3qvieraxhURMPqm9nz5us9oi3FMSxgBoGshOTIlCIm3qLr7M2xe4nIikp1ZvdpvoyBcJg8MXb9kCr8WrVwlwF+0aN+FDw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=LdbIc+OjBxr1J3TGLMFK0SUrzAkE7k37hr1vySySrgiJC+zUEIcCLucLzsSG1pMZVK/tGKTyjfDLfV06RFVN3R8KsOy6a8zBKZGn836UXez+4iVgceacYY6/NhohYIr2SF3AzsG3bQ+kESqHdU411jhjl6//EiH4A4VLIdPc560=
Received: by 10.114.180.1 with SMTP id c1mr616318waf.1172927946990; Sat, 03 Mar 2007 05:19:06 -0800 (PST)
Received: by 10.114.197.10 with HTTP; Sat, 3 Mar 2007 05:19:06 -0800 (PST)
Message-ID: <9dc4a1670703030519p491f13bm50980dc8c9725064@mail.gmail.com>
Date: Sat, 03 Mar 2007 08:19:06 -0500
From: EdPimentl <edpimentl@gmail.com>
To: p2psip@ietf.org
Subject: RE: [P2PSIP] What is a Service?
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1022990261=="
Errors-To: p2psip-bounces@ietf.org

The concept of a service is one we do to expound more in upcoming draft.
Here are some comments being made on previous p2p-sip list as well as other
IETF WG

[p2p-sip] Concepts Draft: Open Issue #4: Can clients offerservices?
This is my previous comment:
Regarding the standard point is that we can "consume" and "produce" Network
Services, Applications (Note VoIP is an Application over IP) Services,
Payment Services...
In fact the recent enormous investment in Web2.0 and MobileWeb type
companies are companies
that "orchestrate, choreograph, compose service which originate in another
company/enterprise/client service catalog...
ParlayX is based upon that very same premise... and I am not advocating
using it in a P2P-SIP but pointing out that P2P-SIP can benefit/borrow the
guiding principles of such standards.

Consider this... SMS on Busy P2P-SIP Subscriber
<p2p-sip_svc>
   <register>
   <disconnected causeCode="CAUSE_BUSY"
     destination=tel:5165551212";                      // comment IE Henry's
number :-)
    connection="terminating" block="false">
 <getOriginatingAddress address="orig"/>
<sendSMS to="sip://henry at adobe.com"
   <content=" ' call attempt by '+%orig;+'on 5165551212'"/>
</disconnected>
</register>
<p2p-sip_svc>

This is only and example and not meant to define or dicatate any real way to
do it...

Therefore I believe that adopting XML ParlayX, XML WebServices SOA
principles on how
 services are produce and consume can be a benefit... and advantage then
trying to create the wheel. The initial services can be Location Based,
Context Based, Ambient Based or Payment based.
Here is another example http://agilepay.ws/ws  of exactly what I am talking
about..
------
Here is an important draft since in the very near future we will be consume
and remix modules/component to orchestrate and produce services, sometime as
simple as copying and pasting a fragment code into our own modules..."ie
mashups"
There are many of us currently consuming and producing and remixing
widget(services) for mobile and online consumption.

http://www.simpleweb.org/ietf/internetdrafts/complete/draft-ietf-widex-requirements-04.txt
------
Then is  following from a IETF Presence and IM Draft expiring in Feb 2007
 Discussion

   The use cases described above may seem to be simple.  However, in
   reality it is not so.  The following describes issues that need to be
   solved in order to enable the creation of the use cases without the
   need to negotiate each peer network relationship separately and
   manually.

   o  Connectivity - A peer network needs a mechanism to learn the
      connectivity setting of the other peer network.  Examples of
      connectivity parameters may be list of domains that the peer
      network is representing, firewall and NAT settings and more.

   o  Security - The peer network or the federation that is being
      connected to may require certain level of security in order to
      accept connections from another peer network.  For example, peer
      network B may require that only TL'S will be used and it can also
      specifies the type and level of certificates that should be used.
      Community A will need a way to discover and use these parameters.

   o  Privacy - In many peer networks that provide real time
      collaboration services there are inter mechanisms that enable a
      user to configure the level of privacy that they wish to achieve.
      for example, a user may say that only certain users will be able
      to see him/her etc.  Similar mechanisms are required to be in
      place in peering and in the federation model.

   o  Services - When two or more peer networks are peering for real
      time collaboration services, each peer network has to have an
      understanding regarding the services that are provided by the
      other peer network.  This may/should include: A) The list of
      services that are provided by the peer network or the federation.
      B) Parameters for each services that may be different between peer
      networks.  For example if the peer network provides for page mode
      IMs or session based IMs or both?  Is presence filtering or
      partial notification is supported?  Are subscription to resource
      lists [3] are supported?

   o  Mappings - Many times one peer network may have different set of
      values for different statuses of a user.  For example "Do not
      Disturb" is translated to "Busy" in the other peer network.

-- 
Thanks in advance and best regards,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
sip:     sip:2150112@truphone.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Relevant, Ambient, Location ) based Social Network
http://TagR.mobi (Alpha)

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base P2PSIP dSIP infrastructure
https://sourceforge.net/projects/viasip/
Mailing List viasip_ng@freelists.org
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip