Subject: [P2PSIP] Concepts draft respin

From: Philip Matthews <[email-masked]>
Date: Wed, 14 Feb 2007 10:58:43 -0500

Just thought I would let folks know what to expect
in the next version of the Concepts draft.  I am working
away on the respin as time permits, and I fully plan to have it
out by the deadline, but I don't think it will appear much
before the deadline because of other things I have to
work on (including other drafts).

The major technical changes will be:
1) Addressing open issues 1 - 8.  In previous e-mails,
    I have described these issues.
2) Adding the idea that a peer = "peer + (optional) SIP entity".
    This was already mentioned in the BOF in San Diego.
3) Adding the third architecture choice that a client might
    connect to multiple peers. Eric Rescorla suggested this in an e-mail
    message sent to the list shortly before the San Diego meeting.

Other than these changes, I am planning to address the comments
receives from various people, and go a general rewrite and clean-up.

If anyone has any comments on open issues 5 - 8 that I published
a few weeks ago, or has any other comments on the -03 version,
this would be a good time to send them to me.

- Philip

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

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Feb 2007 10:06:15 -0600

Hi, Philip,

>    I have described these issues.

I had responded to your open issues 1-4 posting, at 
https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002012.html. I 
agreed with your proposals for 2 and 3, but pointed out that Brian Rosen had 
suggested a fairly different model in issue 1, at 
https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-December/001912.html, 
which we have not discussed as a working group, and that issue 4 seemed to 
assume that all services could be identified with a SIP URI, which is OK for 
SIP-based services but not for STUN, which I also hear people calling a 
"service".

I didn't see a response, so wanted to ping you on these two comments while 
you were still working on the next version of the Concepts draft.

Thanks,

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Feb 2007 10:34:04 -0600

Hi, Philip,

>    message sent to the list shortly before the San Diego meeting.

Was this the posting that you're referring to?

https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/001598.html

Thanks,

Spencer

---

From: EdPimentl <[email-masked]>
Date: Tue, 20 Feb 2007 11:47:15 -0500

Hello Philip,

Where are the latest comments available?
-E

>     message sent to the list shortly before the San Diego meeting.

Sincerely,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
sip:    sip:[email-masked]
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

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

Mobile ( Context, Ambient, Location ) based Social Network
http://TagR.mobi(apha0

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

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base SKYPE- (open} infrastructure
https://sourceforge.net/projects/viasip/
Mailing List [email-masked]
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 20 Feb 2007 12:32:08 -0500

On 20-Feb-07, at 11:06 , Spencer Dawkins wrote:

> I had responded to your open issues 1-4 posting, at https:// 
> lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002012.html. I  
> agreed with your proposals for 2 and 3, but pointed out that Brian  
> Rosen had suggested a fairly different model in issue 1, at https:// 
> lists.cs.columbia.edu/pipermail/p2p-sip/2006-December/001912.html,  
> which we have not discussed as a working group, and that issue 4  
> seemed to assume that all services could be identified with a SIP  
> URI, which is OK for SIP-based services but not for STUN, which I  
> also hear people calling a "service".
>
> I didn't see a response, so wanted to ping you on these two  
> comments while you were still working on the next version of the  
> Concepts draft.
>

I think you have swapped issues 1 and 4 in your message.
Issue 1 was "Do we need a way to discover which peers offer which  
services?".
Issue 4 was "Do clients offer services?"

Brian's posting was on issue #4.
As I stated in
      https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 
001983.html
my proposal is to basically punt on this issue for now:
 > Open Issue #4: Can clients offer services? Or are services only  
offered by peers?
 > Summary of Mailing List Discussion:
 > Views were mixed. Some supported this proposal, while others did not.
 > Enrico suggested that we simply defer this decision by saying that
 > services are offered by peer or by peers and clients.
 > Proposal: Defer the question and adopt Enrico's proposed wording  
for now.
I am hoping that this will satisfy everyone.

Regarding issue #1.
I see your point about URIs for non-SIP-based services, but I think  
we may
be able to finesse this. We may be able to use a SIP URI to describe  
the service,
and return one or more SIP URIs that describe the peers that offer  
the service,
even if the service is not  SIP-based.
Or we may choose an entirely different way of describing services and  
the
peers that offer them, since some people have suggested that URIs are  
not
the right way to describe services.
I will try to capture this debate in some way in the document.

And, BTW, I don't expect to get to the serious writing until next  
Monday.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 20 Feb 2007 12:34:41 -0500

Actually, I was referring to EKR's original posting
     https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/ 
001583.html

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 20 Feb 2007 12:39:36 -0500

If you mean the latest comments on the draft,
they have been posted by various people to the mailing list.
I plan to try to address all comments posted by people
since the last version (-03) was posted.

If you mean, where is the latest version of the draft itself,
the latest version is still the -03 version of last October.
I am working on some other documents this week
(which are due by the earlier -00 deadline), and
plan to spend all next week working on the -04 version.

- Philip

On 20-Feb-07, at 11:47 , EdPimentl wrote:

> On 2/14/07, Philip Matthews <[email-masked] > wrote:

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Feb 2007 11:41:47 -0600

Hi, Philip,

> I think you have swapped issues 1 and 4 in your message.

Sorry if I confused you - thanks for the work you're doing.

> I am hoping that this will satisfy everyone.

This question would still appear in the next version of the draft? If so, 
this is fine.

> Regarding issue #1.
> I see your point about URIs for non-SIP-based services, but I think  we 
> may
> be able to finesse this. We may be able to use a SIP URI to describe  the 
> service,
> and return one or more SIP URIs that describe the peers that offer  the 
> service,
> Or we may choose an entirely different way of describing services and  the
> peers that offer them, since some people have suggested that URIs are  not

Thanks!

> And, BTW, I don't expect to get to the serious writing until next  Monday.

I understand completely. And thanks for holding the pen on this.

Spencer

---

From: Philip Matthews <[email-masked]>
Date: Tue, 20 Feb 2007 17:44:23 -0500

On 20-Feb-07, at 12:41 , Spencer Dawkins wrote:

> This question would still appear in the next version of the draft?  
> If so, this is fine.

I will probably mention this issue at one spot in the document,  and  
then use the
wording above "peers or peers and clients" or something similar  
elsewhere
when discussing services.

>
>> Regarding issue #1.
>> I see your point about URIs for non-SIP-based services, but I  
>> think  we may
>> be able to finesse this. We may be able to use a SIP URI to  
>> describe  the service,
>> and return one or more SIP URIs that describe the peers that  
>> offer  the service,