Subject: [P2PSIP] Concept draft: Open issues #5 - 8

From: Philip Matthews <[email-masked]>
Date: Mon, 26 Feb 2007 13:22:58 -0500

Folks:

Back in late January I posted four more open issues for the Concepts  
draft.
There was some discussion on these, and I am going to summarize here
what I think was agreed to as a result of these discussions.

I plan to make these changes to the draft in the next couple of days.

- Philip

Open issue #5: Users vs. Resources vs. Services.
https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html
=======================================
I propose to go with the following description of these. This is my  
original proposal above
except for the addition of a change suggested by Richard Barnes.

Users are humans. A user may be represented in the P2P Overlay by
multiple UAs, which represent the various different ways that the
user may be contacted (e.g., desk phone, mobile). Some of these may
answer even if the user is not available (e.g., voicemail server).

A service represents something that a peer can do on behalf of
another peer.  Multiple peers may offer the same service. Within a
service type (e.g., "STUN server"), there may be differentiation
between the peers on the exact sub-type of the service provided
(e.g., "STUN server" vs. "STUN server with relay service"). However,
once the sub-type is selected, the service is identical  between
peers, so which one to contact can be determined by things such as
net-path efficiency.

Information about a UA, user, or service may be stored in the  
distributed
database. The information is stored in a "record", which has an
associated "key" which is used for lookup.

It may be that a P2PSIP Overlay will store other information in the
distributed database. Generically, we use the term "resource" for
the information that can be stored in the distributed database.

Open issue #6: Data Model vs Service Model
https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html
=========================================================
I propose to add the concept of a Data Model vs a Service Model,
as described in
     http://mice.cs.columbia.edu/getTechreport.php?techreportID=388
and
     http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt
Dan Romascanu requested that we come up with different terms,
and I will try to do that. (Feel free to make suggestions!)

Open issue #7: Admitting Peer
https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html
=========================================================
I propose to add the terms "Joining Peer" and "Admitting Peer"
and change "Peer  Insertion" to "Peer Admission".

Open issue #8: Expressing "Client protocol = SIP?"
https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html
=========================================================
I propose to rephase this question as "Do clients exist?".

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 26 Feb 2007 12:38:24 -0600

Hi, Philip,

Thanks for the heads-up on these proposed changes. Comments follow.

Spencer

> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html

After reading current shake-and-bake discussions about "service ID" on the 
SIPPING mailing list, if we can avoid using the word "service" in P2PSIP, 
that would be lovely. At the very least, the question of addressing should 
be mentioned - some people have assumed there's a SIP URI for services, 
while others are using service to include non-SIP "services" like STUN.

> Information about a UA, user, or service may be stored in the  distributed

I agree that both of these are overloaded now...

> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html

I agree with this proposed change.

> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html

I agree with this proposed change, but isn't there a parallel question like 
"Peer protocol = SIP?"?

---

From: Philip Matthews <[email-masked]>
Date: Mon, 26 Feb 2007 13:56:17 -0500

See inline.
- Philip

On 26-Feb-07, at 13:38 , Spencer Dawkins wrote:

>> Back in late January I posted four more open issues for the  
>> Concepts draft.
>> I propose to go with the following description of these. This is  
>> my original proposal above
> After reading current shake-and-bake discussions about "service ID"  
> on the SIPPING mailing list, if we can avoid using the word  
> "service" in P2PSIP, that would be lovely. At the very least, the  
> question of addressing should be mentioned - some people have  
> assumed there's a SIP URI for services, while others are using  
> service to include non-SIP "services" like STUN.

Do you have a proposal for an alternative name for "service"?
(You knew that was coming, didn't you? :-)

As for the URI question, I will discuss this.

> I agree with this proposed change, but isn't there a parallel  
> question like "Peer protocol = SIP?"?

I think this is already mentioned, but I will make sure it is there  
in the next version.

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 26 Feb 2007 14:59:27 -0500

Only question I have is about services that are people specific (wow,
I'm digging into odd turf here). What about things like VM? It is a
service, but located on a per-user basis.

I'm personally fine just treating that as a user-level resource, but
wanted to see what others thought.

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Philip Matthews <[email-masked]>
Date: Mon, 26 Feb 2007 15:14:49 -0500

Regarding VoiceMail, here is one way to make it work.

A peer that is willing to act as a VoiceMail server registers
as a contact for the "VoiceMail" service.

When a User wants to enable VoiceMail, her UA does a lookup
on the VoiceMail service and gets back  a list of peers.
The UA picks one of these peers and contacts it and arranges
for it to act as a "VoiceMail taker" for the user.
The peer then registers with the UA as a contact point for the user,
presumably with a q value of .5 or similar.

So the "service" is the ability to take voicemail.
To register as a VM contact for a user, the peer registers as a UA for
the user.

- Philip