Subject: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer services?

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 20 Dec 2006 14:30:59 -0500

Open Issue #4: Can clients offer services? Or are services only  
offered by peers?

Philip's Strawman Proposal: Only peers can offer services. Clients  
can use services, but  do not offer them.

There are two reasons for this proposal:
One is that, to offer a service, a client would presumably need some  
sort of ID in order to identify the client offering the service, and  
the Concepts Draft currently states clients do not have IDs.
The second is that this is consistent with the view that the client  
protocol could be just vanilla SIP. It is not clear how to offer  
services if the client protocol is SIP.

The authors of the Concepts Draft have not been able to resolve this  
amongst ourselves, so we are throwing the issue out for general  
debate. (Err ... to be honest, we haven't tried very hard either, as  
people are busy with other things).

- Philip

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 20 Dec 2006 12:10:44 -0800

This sounds good enough for me, unless someone comes up with a
compelling usage scenario to the contrary.

Happy holidays and a successful new year!

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews
Sent: Wednesday, December 20, 2006 1:31 PM
To: P2P-SIP
Cc: David A. Bryan
Subject: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer
services?

- Philip

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Dec 2006 15:56:12 -0600

I agree with Philip's proposal. I'm not doing well on understanding why a 
client offering a service *could not* be a peer instead of being a client - 
in addition to Philip's two reasons stated below, which both make sense to 
me.

Like Henry, I'd appreciate counterexamples in the form of use cases.

Thanks,

Spencer

From: "Henry Sinnreich" <hsinnrei at adobe.com>

---

From: br at brianrosen.net (Brian Rosen)
Date: Wed, 20 Dec 2006 17:26:09 -0500

I admit to not having enough experience here to really stick my neck out too
far, but suppose that the only role of a "peer" was to relay messages to
clients (it could be a client itself), e.g. Nat traversal relays.

Then a client is really all there are, and all services come from clients.

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Spencer Dawkins
> Sent: Wednesday, December 20, 2006 4:56 PM
> To: P2P-SIP
> Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can
> clientsofferservices?
>

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Dec 2006 16:59:35 -0600

This would be a reasonable view of the world, but it doesn't seem to be the 
view of the world described in the Concepts draft.

Section 3.2 has a reference architecture diagram that pretty clearly shows 
combination peer/proxies, etc. and does not show any services on a client.

Not that this is a working group draft, or even a working group yet, but if 
other people have been waiting to look at the proposed architecture more 
closely, this would be a lovely time for that to happen...

Thanks,

Spencer

From: "Brian Rosen" <br at brianrosen.net>

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 21 Dec 2006 01:52:24 +0100

> services if the client protocol is SIP.

I think it would be a big mistake to take such a decision now.  First of
all, we don't really know what a service is (anybody subscribed to the
sipping mailing list knows what I mean); it could be a conference server
identified by a common SIP URL, or a STUN or TEREDO relay, identified by
a URI following a non-yet-defined schema.  Then we neither actually know
what a peer is; possibly a device behind a NAT could be a perfect
voicemail server (i.e. could host a service) while being unable to
participate in the DHT maintainance because of network limitations.

Such an issue is too technical for being in the scope of the concept draft.

> people are busy with other things).

I don't see the need to address such an issue in the concept draft;
again, it is a merely technical decision and perhaps it is worth
deferring it to the deployer's will.

-- 
Ciao,
Enrico

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Thu, 21 Dec 2006 10:12:29 +0800

Hi, all:
IMHO, I think client and service are two independent concepts. First, a
client is a client because it has some limitations to participate in overlay
and maintain overly. The reasons include small storage, low computing
capability, the node being behind NAT, and the like. Second, services could
be thought of as a function which could help others. In the P2PSIP case,
what clients do is to publish the service and do not maintain overlay and
what peers do is to not only publish service but also participate in and
maintain the overlay. If others want to get a specific service, they could
search through the overlay made up of peers and find out who could provide
the service. Maybe service providers are clients. 
So, in my view, it is no need to put a limitation on the client. Comments
are welcome. 
Regards!
--
Jiang XingFeng
> Sent: Thursday, December 21, 2006 3:31 AM
> To: P2P-SIP
> Cc: David A. Bryan
services?

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Wed, 20 Dec 2006 22:01:05 -0500

Does it mean that clients can will a "subset" of functionalities of those of peers, while peers will have the "full-set" of functionalities in P2P-SIP? 
 
If not, what does differentiate between peers and clients in P2P-SIP?
 
Best regards,
Radhika
 
Note: I did not use the term "service" as we have not yet defined what a service means. Or, it may so happen, like SIPPING WG as Encrico mentioned, we may NOT even need to define the term "service" in the first place.

________________________________

From: p2p-sip-bounces at cs.columbia.edu on behalf of JiangXingFeng
Sent: Wed 12/20/2006 9:12 PM
To: 'Philip Matthews'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer services?

Hi, all:
services?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061220/15c76364/attachment-0001.html

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Thu, 21 Dec 2006 11:24:01 +0800

Hi? Roy:

   Please see inline.

Regards!

--
Jiang XingFeng

  _____  

From: Roy, Radhika R. [mailto:RADHIKA.R.ROY at saic.com] 
Sent: Thursday, December 21, 2006 11:01 AM
To: JiangXingFeng; Philip Matthews
Cc: P2P-SIP
Subject: RE: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer
services?

Does it mean that clients can will a "subset" of functionalities of those of
peers, while peers will have the "full-set" of functionalities in P2P-SIP? 

Yes.  The functionalities what we are discussing here are related to P2P
overlay, not including others, such as stun, media relay. 

Peers could provide routing and storage service which clients could not
provide. I think it is the essential difference between peers and clients. 

Best regards,

Radhika

Note: I did not use the term "service" as we have not yet defined what a
service means. Or, it may so happen, like SIPPING WG as Encrico mentioned,
we may NOT even need to define the term "service" in the first place.

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of JiangXingFeng
Sent: Wed 12/20/2006 9:12 PM
To: 'Philip Matthews'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer
services?

Hi, all:
services?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061220/1978cc26/attachment.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 14:32:17 -0500

> Then a client is really all there are, and all services come from  

Interesting.
As I see it,  what you are calling a "client" is what the Concepts  
draft calls a "peer" !!
With a small difference that some of these clients/peers help with  
forwarding messages to other clients/peers (assuming we adopt this  
proposal for the resolution of Open Issue #2, which most people seem  
to support).

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 14:39:06 -0500

> closely, this would be a lovely time for that to happen...

I would like to second Spencer's sentiment.

We don't have an official WG yet (though the last think I heard was  
that things are looking very good that there will be by March), so  
there is no such thing as official WG documents yet, but my co- 
authors and I are trying hard to reflect the ideas of the group in  
the Concepts draft. So if you have a different view of what a P2PSIP  
network looks like, speak up. If the rest of the group agrees with  
you, then we will update the Concepts draft to match.

It is precisely for this reason that we are bringing the open issues  
(as we see them) to the mailing list before doing the next revision.

- Philip

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 21 Dec 2006 14:54:30 -0500

Okay, so we just used this argument with the "DNS is all we need" folks, and
now I'm on the other side a little.  This view would NOT conflict with the
charter, I would note.

I have been bothered by the special status we give to peers over clients.
We need to have two kinds of entities for one very good reason: clients
can't talk to other clients (or peers) directly, primarily because of NAT
issues.

However, we have taken that very real problem, and, for some reason I don't
understand, decided that SINCE you can't exchange messages directly, THEN
peers should have other distinguishing characteristics from clients.  That's
the part I don't get.  Why is that?  Why should being behind a NAT
automatically make you a dumb client instead of a smart peer?  Why can't
clients store data for example?  In this case, why can't they provide
services?

What is the requirement, or the practical reality, that makes the difference
between a client and a peer more than just a NAT traversal problem?

Brian

Who still admits to not being an expert here and thus gets to ask the stupid
questions that sometimes generates "aha's" from those that are.

> bounces at cs.columbia.edu] On Behalf Of Philip Matthews
> Sent: Thursday, December 21, 2006 2:39 PM
> To: P2P-SIP
> Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4:
> Canclientsofferservices?
> 
>

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 17:40:11 -0500

On 20-Dec-06, at 14:30 , Philip Matthews wrote:

> One is that, to offer a service, a client would presumably need  
> some sort of ID in order to identify the client offering the  
> service, and the Concepts Draft currently states clients do not  
> have IDs.
> The authors of the Concepts Draft have not been able to resolve  
> this amongst ourselves, so we are throwing the issue out for  
> general debate. (Err ... to be honest, we haven't tried very hard  
> either, as people are busy with other things).
>
> - Philip
>

Folks:

I have thought about this issue some more, and would like to change  
some of the things I said above.

I now think it is possible to treat service registration in a way  
similar to user registration. In particular, if clients offered  
services, this could be done using the same techniques as user  
registration.

IF this technique is acceptable,  then services can be offered using  
standard SIP mechanisms, and this can be done without requiring a  
client to have an ID. This applies at least to services that are  
invokable using a SIP Invite.

Below is an example of how a C/S SIP UA might offer voicemail  
services to a P2PSIP Overlay:
1. The C/S SIP UA (call it X) registers the URI   
"sip:voicemail.p2psipNetwork.org" with a peer (call it Y) that acts  
as a SIP proxy and registrar. Here "p2psipNetwork.org" is the Overlay  
Identifier, and "voicemail" indicates the service.  (This is one way  
we might name services in a P2PSIP overlay.)
2. Peer Y publishes this name into the Overlay using the peer  
protocol. If X does not have a public IP address, then X is reachable  
only by sending a message through the Overlay to Y, which then  
proxies it on to X, so peer Y needs to change the contact URI for  
this registration to be itself (or add itself as an alternative  
contact for this service).
3. A peer Z which wishes to use the service does a lookup on  
"sip:voicemail.p2psipNetwork.org" and gets back a bunch of contact URIs.
4. Peer Z decides that it wishes to use the service offered by X.
5. Peer Z sends an Invite to X. This Invite is actually sent to Y,  
since Y changed the contact URI in the registrar to point at itself.
6. Peer Y receives the Invite and proxies it on to X. The call is  
established, and X and Z negotiate the details of the voicemail  
service that X will offer Z. Z asks X to handle voicemail on behalf  
of "alice at p2psipNetwork.org"
7. Peer X registers "alice at p2psipNetwork.org" with Y (with a Q value  
of .5, so this contact is less preferred than other contacts for  
Alice). Y publishes this contact into the Overlay.

To summarize, I think that it is possible for us to allow clients and  
C/S SIP entities to offer at least certain services, using the same  
mechanisms as used for user registration.

Comments?

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 17:43:53 -0500

> deferring it to the deployer's will.

Enrico:

If we do service registration in the same way as we do user  
registration (see the e-mail I just sent to the list), then I agree  
with you that we can defer this question.

If we want to use a different mechanism (e.g. a mechanism that can  
not be implemented using standard SIP and/or requires clients to have  
unique client IDs), then I think this question will interact with  
other design decisions and we need to consider it now.

- Philip

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 22 Dec 2006 00:27:30 +0100

Philip Matthews wrote:
> If we do service registration in the same way as we do user registration
> (see the e-mail I just sent to the list), then I agree with you that we
> can defer this question.
> 
> If we want to use a different mechanism (e.g. a mechanism that can not
> be implemented using standard SIP and/or requires clients to have unique
> client IDs), then I think this question will interact with other design
> decisions and we need to consider it now.

I get your point, but I still think that forcing such kind of decision
now would be a mistake.  Talking about services, we should now only
define the _concept_; how it will be registered, stored and accessed
within the overlay is technical matter and should be separate from the
concept.

I'd propose to address this issue starting with some general text, such
as: "Sevices are identified by specific URIs and possibly by other
means, can be accessed by clients and peers and can be offered by peers
or by clients and peers."  Then, if when working on protocols
specifications we realize that such a definition is too vague, we'll
still be able to replace it with a more restrictive one.  Doing the
contrary is dangerous because it would discourage the proposal of
possibly valid solutions just because they are not compliant with a too
strict concept draft.

My two cents.

-- 
Ciao,
Enrico

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Dec 2006 18:47:04 -0500

Philip:
 
URL does not represents any services. A URL is a url. That URL is a resource used like an address.
 
So, just using "voicemail" in the URL does not mean that the "voice services" are available in this address.
 
In SIP, there is no standard for any services. It just sets up a session: p2p or mpt.
 
I do not think that you can standardize any services in P2P-SIP as well.
 
Best regards,
Radhika

From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews
Sent: Thu 12/21/2006 5:40 PM
To: P2P-SIP
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offerservices?

Folks:

Comments?

- Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/aa30dd07/attachment-0001.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Dec 2006 18:56:55 -0500

Enrico:
 
You can see a separate email sent to Philip why you cannot specify services using URLs. There are other standards in IETF for services registration. Let us use those standards.
 
It seems to be easy to say like this - using URL for services registration. SIPPING WG also debated this for sometime to clarify this mis-concepts. But in practice, a lot of works have been done in IETF in this direction for services registration and how to use and get services. 
 
Standards are already there in the IETF and we need to see those standards first before re-inventing the "services" wheel! It will simply be wastage of our energy and time at this point of time for P2P-SIP as people debated for years for creation of services registration standards.
 
Best regards,
Radhika

From: p2p-sip-bounces at cs.columbia.edu on behalf of Enrico Marocco
Sent: Thu 12/21/2006 6:27 PM
To: Philip Matthews
Cc: P2P-SIP; David A. Bryan
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer services?

My two cents.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/411036d3/attachment.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 19:29:23 -0500

> questions that sometimes generates "aha's" from those that are.

Brian:

According to the Concepts draft, peers CAN be located behind NATs,  
and the difference between clients and peers is simply that peers  
support storage and routing, while clients do not.

However, recently I have started to wonder if, rather than the black- 
and-white peer vs. client distinction, we don't want instead the  
concept of more- vs. less-capable peers. That is, some peers have  
more memory and can store more registrations (think softphone on a  
computer with a large disk), while other peers have less memory and  
can store fewer registrations (think hardphone with limited memory  
and no disk). Similarly, some peers have higher bandwidth  
connections  and can forward more messages on behave of others (think  
PC with gigabit ethernet connection), while others have less  
bandwidth and can forward fewer (think cell phone with limited  
battery lifetime).

Clients then become an extreme point in this space: a peer that  
cannot store any registrations and cannot forward any messages.

- Philip

PS. Just so you know, I was not the person who asked for the concept  
of clients, and I too am still trying to understand the use-cases for  
them.

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 19:51:04 -0500

On 21-Dec-06, at 18:27 , Enrico Marocco wrote:

>> registration
>> not

You are right. We could limit the discussion of service lookup in the  
next revision of the draft to something as general as this.

It would be nice to add an example of service lookup in section 3.4,  
and I suggest the example be the lookup of a STUN Server service, but  
we could do this without going much beyond what you said above.

Anyone else have comments on Enrico's proposal?

- Philip

PS. We still need some definition of a "service". That is going to be  
my next open issue ...

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Dec 2006 19:59:39 -0500

> I do not think that you can standardize any services in P2P-SIP as  

and

> Enrico:
>
> You can see a separate email sent to Philip why you cannot specify  
> services using URLs. There are other standards in IETF for services  
> registration. Let us use those standards.
>
> It seems to be easy to say like this - using URL for services  
> registration. SIPPING WG also debated this for sometime to clarify  
> this mis-concepts. But in practice, a lot of works have been done  
> in IETF in this direction for services registration and how to use  
> and get services.
>
> Standards are already there in the IETF and we need to see those  
> standards first before re-inventing the "services" wheel! It will  
> simply be wastage of our energy and time at this point of time for  
> P2P-SIP as people debated for years for creation of services  
> registration standards.
>
> Best regards,
> Radhika

Radhika:

I am not familiar with these discussions -- perhaps you could  
summarize them for us?

- Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/2a6f1f8e/attachment.html

---

From: edpimentl at gmail.com (EdPimentl)
Date: Thu, 21 Dec 2006 20:06:08 -0500

These are all excellent discussions on services..
I like to submit to look and borrow from the guiding principles supporting
XML WebServices SOBA (Service OrientedBusiness Applications)
Where these are automagically orchestrated and choreograph and essentially
programatically established a business contract using the above dejure
standards..

Sincerely and Best Regards,
-Ed

Mail:       edpimentl[at]gmail[dot]com
VoIP:      edpimentl [Skype | GoogleTalk]
IM:          edpimentl [ AOL | Jabber | Yahoo | MSN ]

Mobile Content Management
http://mobilecentral.ws

Mobile Social Networks(Private Label)
http://GooGaYa.com

Business At the Speed of Thought
http://biscentral.biz

Mobile Payment
http://AgilePAY.ws
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/51e2aee0/attachment-0001.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Dec 2006 22:42:49 -0500

Philip:
 
That's it what has been explained in my emails.
 
SLP is the protocol in the IETF for services registration, services query, and services to be invoked. Other than this, there is no other standards for services in the IETF.
 
By the way, SLP is not p2p protocol per se.
 
Best regards,
Radhika
 
PS.
 
1. If people think, p2p-SIP protocol is a service, then it is a different story. 
 
2. Some people also think routing services, QOS services, NAT/FW crossing services, VoIP services, security services, voice mail services, ptp/mpt conferencing services, and others as a part of services. In this case, we will be mixing between "apples" and "oranges." That is, we confusing the protocol features and (application) services.
 
3. Some people want to register voice mail services. SLP is there to do so. That's it.
 
4. People need to see URL standards what they are. In URL, there is no connotation of services. Period.
 
5. There is no standard in SIP for services. Period. SIP just provides standardization how to set up sessions. All the features that are invoked in SIP during the session are the requirements to set up the session between the parties satisfying the needs of setting up a session successfully after negotiations that all parties agree on.
 
6. People should examine item 5 very carefully going through all SIP standards/RFCs and must NOT confuse between session setups after negotiations to have all the features to satisfy the needs, protocol features, and services like voice mail.
 
7. There is a very fine line between items 5 and 6, for example, how voice mail service/server, media servers for media bridging, and other servers are brought as a part of the session establishment. It is not a "crude" thing like register a voice mail service using URL as an indicator of the service and then just use those services as a part of the session. If people think so, they are highly confused after so many years SIP standardization in the IETF.
 
8. Like SIP, p2p-SIP also follow the same standards. They will have no scope for standardization of services like voice servers, etc.
 
9. What p2p-SIP needs to focus on is to provide all features and functionalities in setting up the sessions (ptp and mpt) in just peer-to-peer mode and, like SIP, not to standardize any "services." (If people think that SIP is providing services by invoking voice mail servers/services, then again they are HIGHLY confused.)
 
10. For example, SIP session has a need for audio and video codec and even announcement (for example, pre-paid call where the caller needs to be made aware of the payment or for other reasons) as a part of the session. It is true that an announcement application server is needed to provide announce. Here is a fine line. In the session establishment layer, there is no knowledge that there is an announcement application server that provides the announcement services. The entity that has the knowledge of this service may be a SIP proxy/call control/application server. Here is the catch: How does the SIP proxy/call control/application server will have this knowledge of this announcement application server? In any case, it is not the SIP protocol. For example, how a DNS service is invoked for resolving an IP address from a SIP URL? It is not a SIP protocol.

From: Philip Matthews [mailto:philip_matthews at magma.ca]
Sent: Thu 12/21/2006 7:59 PM
To: Roy, Radhika R.
Cc: P2P-SIP
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer services?

	Philip:

	Best regards,
	Radhika

and

	Enrico:

	 

	Best regards,
	Radhika

Radhika:

I am not familiar with these discussions -- perhaps you could summarize them for us?

- Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/8206ca6f/attachment.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Dec 2006 22:46:08 -0500

Ed:
 
What is the point from standard point of view?
 
Do you want LAN services? IP services? QOS services? Security services? Web services? Routing services? Bandwidth services? Voicemail services? Multicast services? Multimedia conferencing services? Email services? Brokering services? Session establishment services? HTML-XML conversion services? .....?????
 
Best regards,
Radhika

From: p2p-sip-bounces at cs.columbia.edu on behalf of EdPimentl
Sent: Thu 12/21/2006 8:06 PM
To: Philip Matthews
Cc: P2P-SIP
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offerservices?

These are all excellent discussions on services..
I like to submit to look and borrow from the guiding principles supporting
XML WebServices SOBA (Service OrientedBusiness Applications)
Where these are automagically orchestrated and choreograph and essentially programatically established a business contract using the above dejure standards.. 

Mobile Content Management 
http://mobilecentral.ws <http://mobilecentral.ws/> 

Mobile Social Networks(Private Label)
http://GooGaYa.com <http://googaya.com/> 

Business At the Speed of Thought
http://biscentral.biz <http://biscentral.biz/> 

Mobile Payment
http://AgilePAY.ws <http://agilepay.ws/>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061221/d1984131/attachment.html

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 22 Dec 2006 09:01:40 -0800

Ed,

These are excellent technologies, but a distraction from the present
charter. We must walk first before we run.

Besides, we badly need to revive the old good habit in the IETF of
having running code before working at a standard and debating all kinds
of ideas in this list.

Not to mention open source code as well.

We can keep SOBA on the back of our minds until someone is willing to
spend their money and/or their time on a prototype before coming to the
WG (which it is not even yet).

Please y'all help us stay focused and get something accomplished. In
defining _Basic_ P2P SIP.

As for defining URLs for P2P SIP standards, can we please defer this
until the participants on this list can make a P2P SIP call?

That is, unless you want to keep using Skype forever :-)

Happy Holidays!

Henry

From: EdPimentl [mailto:edpimentl at gmail.com] 
Sent: Thursday, December 21, 2006 5:06 PM
To: Philip Matthews
Cc: Enrico Marocco; P2P-SIP; Henry Sinnreich
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer
services?

These are all excellent discussions on services..
I like to submit to look and borrow from the guiding principles
supporting
XML WebServices SOBA (Service OrientedBusiness Applications)
Where these are automagically orchestrated and choreograph and
essentially programatically established a business contract using the
above dejure standards.. 

Mobile Payment
http://AgilePAY.ws 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061222/0774155f/attachment-0001.html

---

From: edpimentl at gmail.com (EdPimentl)
Date: Fri, 22 Dec 2006 12:48:01 -0500

Hello Henry, Et Al,

I am in vehement agreement with your insightful feedback.
To that end I am willing to devote a resource to flesh out open-source code
which embodies the IETF current draft...
Then other like mind and join in....

For clarity I am in favor of a "kinder, gentler, 1000 point of light" open
p2p-sip infrastructure.

Best to all,
-E

On 12/22/06, Henry Sinnreich <hsinnrei at adobe.com> wrote:
> Besides, we badly need to revive the old good habit in the IETF of having
> running code before working at a standard and debating all kinds of ideas in
> this list.
>
>
>
> spend their money and/or their time on a prototype before coming to the WG
> (which it is not even yet).
>
>
>
> defining _*Basic*_ P2P SIP.
>
>
>
> As for defining URLs for P2P SIP standards, can we please defer this until
> the participants on this list can make a P2P SIP call?
>
>
>
> That is, unless you want to keep using Skype forever J
>
>
>
> Happy Holidays!
>
>
>
> Henry
>
>
>  ------------------------------
>
> *From:* EdPimentl [mailto:edpimentl at gmail.com]
> *Sent:* Thursday, December 21, 2006 5:06 PM
> *To:* Philip Matthews
> *Cc:* Enrico Marocco; P2P-SIP; Henry Sinnreich
> *Subject:* Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offer
> services?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061222/f709db77/attachment.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Sat, 23 Dec 2006 12:41:35 -0500

Ed:
 
I appreciate your email.
 
These kinds of things were discussed before. It is nothing new.
 
These are NOT standards to use URLs with service connotations. These are used defying standards to do some applications here and there having some like-minded people.
 
If billions of people start using with billions and billions of services with those services names specifying URLs, nothing will left in this universe that will not be termed as "services."
 
That is why, we go for standardization bringing sanity throughout the whole world.
 
If people feel so strongly for using URLs specifying services, why do they need to go via back door "violating" standards?
 
Rather, they will be welcomed to make their case and create standards like this. It is so simple to do so, but there must not be violation of standards.
 
Best regards,
Radhika
 
PS: Please analyze the XML script that has been used as an example by you.
 
1. The word SMS is a service known as "standard." This SMS has been used to qualify the URL. So, it is perfectly alright because it is not the URL itself that specifies services.
 
2. If you want to build features as shown in you example, it will NOT violate URL standard so far I think.
 
3. For all other features that you have described in the example, we have to examine in terms of the scope of the standards. For sending SMS to Henry means invocation of the SMS application service probably using the SMS application server. Whether we are allowed to invoke other services "directly" in p2p-SIP layer is debatable as a matter of standardization. I would say no. For example, in SIP, the invocation of SMS application is not a part of the session establishment. A call control SIP proxy might have some extra intelligent what to do next if the Henry's phone is busy. 
 
3a. Here is the most important fine line: To invoke SMS is called another service initiation and it is not done in the SIP layer. That is, in service creation/execution environment, an intelligent proxy (that has the knowledge beyond SIP layer) may be able to invoke SMS application. If so, it is called service creation/execution capability of the proxy server which is NOT in the SIP layer.
 
3b. Now, you have got the whole new services paradigm - Services Creation/Execution Environment. In fact, SIP has created a whole application services industry where all those application servers are being invoked as a side effects of the SIP session establishment: Parlay, CORBA, Open Source, OMA, just to mention a few. This is not in the SIP layer.
 
4. Conclusion: The example that you have provided it should not be for the p2p-SIP layer. It will be a perfect example for p2p-SIP services creation/execution environments that reside above the p2p-SIP Layer.

From: EdPimentl [mailto:edpimentl at gmail.com]
Sent: Fri 12/22/2006 11:49 AM
To: Roy, Radhika R.
Cc: Philip Matthews; P2P-SIP
Subject: Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients offerservices?

Hello Roy,

I read your previous post and agree with many of your comments.
We respectfully differ on your URL is just a url.... since today a URL  can be equivalent to
the hard coded/brittle closely couple CORBA like "SERVICES" offer by the unwilling (telcos)partners. 

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..
Regards,
-E

On 12/21/06, Roy, Radhika R. <RADHIKA.R.ROY at saic.com> wrote: 

	Ed:

	 
	Best regards,
	Radhika

	

	

	
	Mobile Payment

-- 
-Ed

Direct:     678.522.8511

Mobile Payment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061223/e0de5e1c/attachment-0001.html

---

From: edpimentl at gmail.com (EdPimentl)
Date: Sat, 23 Dec 2006 15:07:36 -0500

Hello Roy,

Hope this message finds you well.
To follow Henry's suggestion, let us table discussing P2P client services in
this forum after WG is established and we have contributed open-source code
as the foundation for the WG.

However I would be glad to continue this healthy discussion on a blog or
privately if you wish.... We are actually extremely involved in  the "real"
orchestration and choreographing (as well as Amazon,  Google and
Micro$oft)of SOA WebServices... and if interested talk about some more...
:-)
Sincerely and best regards,
-E
Edpimentl : Skype | Google | MSN | Yahoo
http://edpimentel.com

On 12/23/06, Roy, Radhika R. <RADHIKA.R.ROY at saic.com> wrote:
> These are NOT standards to use URLs with service connotations. These are
> used defying standards to do some applications here and there having some
> like-minded people.
>
> If billions of people start using with billions and billions of services
> with those services names specifying URLs, nothing will left in this
> universe that will not be termed as "services."
>
> If people feel so strongly for using URLs specifying services, why do they
> need to go via back door "violating" standards?
>
> Rather, they will be welcomed to make their case and create standards like
> this. It is so simple to do so, but there must not be violation of
> standards.
>
> Best regards,
> Radhika
>
> 1. The word SMS is a service known as "standard." This SMS has been used
> to qualify the URL. So, it is perfectly alright because it is not the URL
> itself that specifies services.
>
> 3. For all other features that you have described in the example, we have
> to examine in terms of the scope of the standards. For sending SMS to Henry
> means invocation of the SMS application service probably using the SMS
> application server. Whether we are allowed to invoke other services
> "directly" in p2p-SIP layer is debatable as a matter of standardization. I
> would say no. For example, in SIP, the invocation of SMS application is not
> a part of the session establishment. A call control SIP proxy might have
> some extra intelligent what to do next if the Henry's phone is busy.
>
> 3a. Here is the most important fine line: To invoke SMS is called another
> service initiation and it is not done in the SIP layer. That is, in service
> creation/execution environment, an intelligent proxy (that has the knowledge
> beyond SIP layer) may be able to invoke SMS application. If so, it is called
> service creation/execution capability of the proxy server which is NOT in
> the SIP layer.
>
> 3b. Now, you have got the whole new services paradigm - Services
> Creation/Execution Environment. In fact, SIP has created a whole application
> services industry where all those application servers are being invoked as a
> side effects of the SIP session establishment: Parlay, CORBA, Open Source,
> OMA, just to mention a few. This is not in the SIP layer.
>
> 4. Conclusion: The example that you have provided it should not be for the
> p2p-SIP layer. It will be a perfect example for p2p-SIP services
> creation/execution environments that reside above the p2p-SIP Layer.
>
> *Sent:* Fri 12/22/2006 11:49 AM
> *To:* Roy, Radhika R.
> *Cc:* Philip Matthews; P2P-SIP
> *Subject:* Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients
> offerservices?
>
> Hello Roy,
>
> Regarding the standard point is that we can "consume" and "produce"
> Network Services, Applications (Note VoIP is an Application over IP)
> Services, Payment Services...
> 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.
>
>  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.
> > Do you want LAN services? IP services? QOS services? Security services?
> > Web services? Routing services? Bandwidth services? Voicemail services?
> > Multicast services? Multimedia conferencing services? Email services?
> > Brokering services? Session establishment services? HTML-XML conversion
> > services? .....?????
> >
> > Best regards,
> > Radhika
> >
> > *From:* p2p-sip-bounces at cs.columbia.edu on behalf of EdPimentl
> > *Sent:* Thu 12/21/2006 8:06 PM
> > *To:* Philip Matthews
> > *Cc:* P2P-SIP
> > *Subject:* Re: [p2p-sip] Concepts Draft: Open Issue #4: Can clients
> > offerservices?
> >
> > essentially programatically established a business contract using the above
> > dejure standards..
> >

Mobile Payment

-- 
-Ed

Mobile Payment
http://AgilePAY.ws
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061223/f741c088/attachment.html