Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS Systems

From: drage at lucent.com (Drage, Keith (Keith))
Date: Wed, 18 Oct 2006 15:22:15 +0200

First, I believe the proposed charter for p2p-sip precludes discussion
of this in the new working group if it is formed.

Having said that, lets discuss it.

Rather than trying to make mileage out of 100 versus 11, presumably
based on the fact that a lot of things that are useful are simulating
the telephone network and not therefore required (like the ability to
describe a voice only session in SDP - no RFC 4566 reference), can I
suggest that the better way of doing this would be to describe what is
in the current sip hitchhiker document that is NOT needed because it is
a centralised function that is no longer required in the p2p-sip
architecture. As such it will need to track the SIP hitchhiker document
as that develops. If the feature is still required, then it would need
to indicate the means of supporting that feature.

Further, to take an example, it does not show the sip-identity document
(RFC 4474). Either authenticated identity is regarded as too telephony
like and it is eliminated for those purposes (in which case I note some
email systems seem to be doing it), or it is eliminated because it needs
some sort of server to provide a certification body. My understanding is
that even p2p-sip will have to have centralised certification, and
therefore that criteria for elimination would be unreasonable. I do
accept that RFC 3325 would not figure because it requires centralised
capabilities.

Regards

Keith

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich
> Sent: 17 October 2006 00:14
> To: p2p-sip at cs.columbia.edu
> Subject: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic 
> CS Systems
> 
> The Internet Draft "Lightweight SIP Toolkit for P2P and Basic 
> CS Systems" has been posted by the IETF:
> 
> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt  
> 
> The I-D is also available at p2psip.org 
> 
>      The number of SIP related standards can be significantly 
>      reduced for various application scenarios by (1) using SIP 
>      without "network based services" and (2) without emulating the 
>      telephone network.  
> 
>      Such an approach reduces the number of SIP related standards 
>      (as by mid 2006) from roughly 100 to about 11. Core SIP 
>      interoperability and SIP compliance can be preserved without 
>      relying on complex server based networks. 
> 
>      Successful IP communications must also include the relevant 
>      standards for NAT traversal, some of which are not directly 
>      related to SIP and also several standards for security. These 
>      standards are included here as well.
> 
> Any suggestions and your FRANK opinion would be most welcome. 
> Please use the list.
> 
> Thanks, Henry
> 
> _______________________________________________
> 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: Thu, 19 Oct 2006 14:34:28 -0500

Hi, Keith,

> of this in the new working group if it is formed.

Just as an aside, I believe that one common AD metric for evaluating 
in-scope/out-of-scope discussions is whether the WG is making progress on 
the work it's already chartered to do.

> Having said that, lets discuss it.

:-)

> to indicate the means of supporting that feature.

I'm actually not finding a list of "about 11" references called out in the 
00 draft. The draft has 11 normative references, but this includes 2119, so 
I think I'm missing something.

Could the list be called out more clearly in the text?

Having said this ... Jonathan has been trying valiantly to limit the scope 
of the hitchhiker's guide to SIP and its extensions. Will this limitation 
affect our ability to use the hitchhiker's guide for the purpose Keith 
suggests?

> accept that RFC 3325 would not figure because it requires centralised

I agree with Keith mostly here.

I'm not sure if Keith means "will have to have" as a default requirement, a 
mandatory-to-implement requirement, or a mandatory-to-deploy requirement. 
One of the use cases was "Presence Using Multimedia Consumer Electronics 
Devices", with something like P2PSIP as the application protocol over 
bluetooth, and mandatory-to-deploy centralized certification would be 
overkill in these situations.