Subject: RE: [P2PSIP] Concepts draft and P2PSIP clients

From: Peili Xu <[email-masked]>
Date: Thu, 01 Mar 2007 14:45:39 +0800

Hi Philip,

We need to separate logical architecture from deployment architecture. 

The first(current) view clearly separate the function of client and peer,
but in deployment, both of the function can be supported by one physical
terminal.

The second view seems considering the combination of both functions into one
implementation, to me this is an implementation choice.

The third view is interesting but seems introducing a different function
which is out of the scope of the current charter,
Where and how the peer store data is transparent to other peer and also
depends on implementation and deployment, I'm not sure whether it can be
standardized.

Thanks
Peili

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 3:38 AM
To: [email-masked]
Subject: [P2PSIP] Concepts draft and P2PSIP clients

There have been various discussions and proposals for clients over the past
few months.

First of all, there was the original proposal that was put forth in the -00
version of the Concepts document.
In this version, clients associated with (usually just one) peer, with the
client acting in a way similar to a SIP UA, and the peer acting in a way
similar to a SIP proxy/registrar.
In this proposal, clients did not store data for the overlay, nor did they
participate in message routing.
In this view, clients do not have a "Client ID".

Second, there was a proposal by Eric Rescorla.
As I understand this proposal, clients are fully meshed into the overlay,
but still do not store data for the overlay.
However, presumably they do participate in message routing.
In this view, clients have a "Peer ID", since they are involved in the DHT.
This view has been described as "a peer with bad memory".

Third, there has been some private  discussion of a model somewhat similar
to the first, but where clients DO store data. In essence, a peer can elect
to store data on one of its associated clients, rather than in its own
memory.
In this view, clients do not have a "Client ID" and do not participate in
the DHT.

I think all three of these views are interesting, albeit contradictory.
So I am proposing to include a section in the next revision of the Concepts
document that describes these three views.
This would mean that the text elsewhere in the document would become
somewhat more vague on what a client's role really is.

Comments?

- Philip

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

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

---

From: Philip Matthews <[email-masked]>
Date: Thu, 1 Mar 2007 02:27:06 -0500

> but in deployment, both of the function can be supported by one  

OK, though I don't see why one would ever want to put a peer and a  
client on the same device.

> implementation, to me this is an implementation choice.

I don't understand how to come to this conclusion.

> depends on implementation and deployment, I'm not sure whether it  

But we are standardizing the interfaces between peers and also  
between clients and peers
(if we decide to keep clients), so this is not really transparent.

Regardless of all this, what I would really like to see someone do is  
write an internet-draft
proposing a particular client role and arguing why we want it.