<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Mindless Fluffiness &#187; Papers</title>
	<atom:link href="http://www.dial911anddie.com/weblog/category/papers/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dial911anddie.com/weblog</link>
	<description>Random fluffy thoughts, and emergency phone calls</description>
	<lastBuildDate>Sun, 05 Sep 2010 00:50:50 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>UBC Award</title>
		<link>http://www.dial911anddie.com/weblog/2005/11/ubc-award/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/11/ubc-award/#comments</comments>
		<pubDate>Thu, 03 Nov 2005 16:16:03 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Family]]></category>
		<category><![CDATA[Papers]]></category>
		<category><![CDATA[Technical]]></category>
		<category><![CDATA[Travel]]></category>
		<category><![CDATA[VoIP]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/11/ubc-award/</guid>
		<description><![CDATA[Outstanding Young Alumnus Award &#8211; UBC Alumni Association]]></description>
			<content:encoded><![CDATA[<p>
<a href="http://www.alumni.ubc.ca/programs/awards/2005/jennings.html" title="Outstanding Young Alumnus Award - UBC Alumni Association">Outstanding Young Alumnus Award &#8211; UBC Alumni Association</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/11/ubc-award/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Managing Client Initiated Connections in the Session Initiation Protocol (SIP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/10/managing-client-initiated-connections-in-the-session-initiation-protocol-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/10/managing-client-initiated-connections-in-the-session-initiation-protocol-sip/#comments</comments>
		<pubDate>Sun, 30 Oct 2005 23:56:58 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/10/managing-client-initiated-connections-in-the-session-initiation-protocol-sip/</guid>
		<description><![CDATA[&#8220;Managing Client Initiated Connections in the Session Initiation Protocol (SIP)&#8221;, C. Jennings, R. Mahy, October 2005, draft-ietf-sip-outbound-01 Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and NATs, prevent [...]]]></description>
			<content:encoded><![CDATA[<p>
&#8220;Managing Client Initiated Connections in the Session Initiation Protocol (SIP)&#8221;, C. Jennings, R. Mahy, October 2005, <a href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-01.html">draft-ietf-sip-outbound-01</a>
</p>
<ul>
<li>Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and NATs, prevent servers from connecting to User Agents in this way. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS server. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections for high availability systems.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/10/managing-client-initiated-connections-in-the-session-initiation-protocol-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Payment for Services in Session Initiation Protocol (SIP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/10/payment-for-services-in-session-initiation-protocol-sip-2/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/10/payment-for-services-in-session-initiation-protocol-sip-2/#comments</comments>
		<pubDate>Sun, 30 Oct 2005 23:54:08 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/10/payment-for-services-in-session-initiation-protocol-sip-2/</guid>
		<description><![CDATA[&#8220;Payment for Services in Session Initiation Protocol (SIP)&#8221;, C. Jennings, G. Jun, J. Fischl, H. Tschofenig, October 2005, draft-jennings-sipping-pay-03.txt Abstract: Service usage might require some form of compensation and this is also true for many communication systems where an entity receiving a call should be able to charge the caller. This is necessary for allowing [...]]]></description>
			<content:encoded><![CDATA[<p>
&#8220;Payment for Services in Session Initiation Protocol (SIP)&#8221;, C. Jennings, G. Jun, J. Fischl, H. Tschofenig, October 2005, <a href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-pay-03.txt.html">draft-jennings-sipping-pay-03.txt</a>
</p>
<ul>
<li>Abstract: Service usage might require some form of compensation and this is also true for many communication systems where an entity receiving a call should be able to charge the caller. This is necessary for allowing fair communication between two communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP using the Security Assertion Markup Language (SAML). It relies on a third party to act as a payment provider and is designed for low value transactions. It does not aim to provide the same capability as other authentication, authorization and accounting systems. This draft is in a fairly early state and has many details that are missing. Earlier versions of this document did not use SAML. This version offers a sketch of what the SAML based solution would look like but still lacks many details that would be needed for an actual implementation.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/10/payment-for-services-in-session-initiation-protocol-sip-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Remote Call Control in SIP using the REFER method and the session-oriented dialog package</title>
		<link>http://www.dial911anddie.com/weblog/2005/10/remote-call-control-in-sip-using-the-refer-method-and-the-session-oriented-dialog-package/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/10/remote-call-control-in-sip-using-the-refer-method-and-the-session-oriented-dialog-package/#comments</comments>
		<pubDate>Sun, 30 Oct 2005 23:49:29 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/10/remote-call-control-in-sip-using-the-refer-method-and-the-session-oriented-dialog-package/</guid>
		<description><![CDATA[&#8220;Remote Call Control in SIP using the REFER method and the session-oriented dialog package&#8221;, R. Mahy, C. Jennings, Oct 2005, draft-mahy-sip-remote-cc-02 Abstract: This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extents the REFER mechinims to allow the [...]]]></description>
			<content:encoded><![CDATA[<p>
&#8220;Remote Call Control in SIP using the REFER method and the session-oriented dialog package&#8221;, R. Mahy, C. Jennings, Oct 2005, <a href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-mahy-sip-remote-cc-02.html">draft-mahy-sip-remote-cc-02</a>
</p>
<ul>
<li>Abstract: This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extents the REFER mechinims to allow the specificate of a response that a UA should send in a dialog. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/10/remote-call-control-in-sip-using-the-refer-method-and-the-session-oriented-dialog-package/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Computational Puzzles for SPAM Reduction in SIP</title>
		<link>http://www.dial911anddie.com/weblog/2005/10/computational-puzzles-for-spam-reduction-in-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/10/computational-puzzles-for-spam-reduction-in-sip/#comments</comments>
		<pubDate>Sun, 30 Oct 2005 23:45:35 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/10/computational-puzzles-for-spam-reduction-in-sip/</guid>
		<description><![CDATA[&#8220;Computational Puzzles for SPAM Reduction in SIP&#8221;, C. Jennings, October 2005, draft-jennings-sip-hashcash-03 Abstract: One of the techniques used in SPAM prevention and various solutions for denial of service attacks is to force the SIP client requesting a service to perform a calculation that limits the rate and increases the cost of the request. This draft [...]]]></description>
			<content:encoded><![CDATA[<p>
&#8220;Computational Puzzles for SPAM Reduction in SIP&#8221;, C. Jennings, October 2005, <a href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-03.html">draft-jennings-sip-hashcash-03</a>
</p>
<p style="text-indent:20pt;">
Abstract: One of the techniques used in SPAM prevention and various solutions for denial of service attacks is to force the SIP client requesting a service to perform a calculation that limits the rate and increases the cost of the request. This draft defines a way to allow a UAS to ask the UAC to compute a computationally expensive hash based function and present the result to the UAS. Although the computation is expensive for the UAC to compute, it is cheap for the UAS to verify. The solution also allows for proxies to compute and check the puzzle on behalf of the UAC or UAS.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/10/computational-puzzles-for-spam-reduction-in-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry</title>
		<link>http://www.dial911anddie.com/weblog/2005/10/the-internet-assigned-number-authority-iana-tel-uniform-resource-identifier-uri-parameter-registry/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/10/the-internet-assigned-number-authority-iana-tel-uniform-resource-identifier-uri-parameter-registry/#comments</comments>
		<pubDate>Sun, 30 Oct 2005 23:40:16 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/10/the-internet-assigned-number-authority-iana-tel-uniform-resource-identifier-uri-parameter-registry/</guid>
		<description><![CDATA[&#8220;The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry&#8221;, C. Jennings, October 2005, draft-jennings-iptel-tel-reg-00 Abstract: This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that [...]]]></description>
			<content:encoded><![CDATA[<p>
&#8220;The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry&#8221;, C. Jennings, October 2005, <a href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-iptel-tel-reg-00.html">draft-jennings-iptel-tel-reg-00</a>
</p>
<ul>
<li>Abstract: This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/10/the-internet-assigned-number-authority-iana-tel-uniform-resource-identifier-uri-parameter-registry/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Drafts from this IETF</title>
		<link>http://www.dial911anddie.com/weblog/2005/07/drafts-from-this-ietf/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/07/drafts-from-this-ietf/#comments</comments>
		<pubDate>Tue, 19 Jul 2005 16:46:18 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/07/drafts-from-this-ietf/</guid>
		<description><![CDATA[? &#8220;NAT Behavioral Requirements for Unicast UDP&#8221;, F. Audet, C. Jennings, July 2005, draft-ietf-behave-nat-udp-03 ? Abstract: This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman">	</font></div>
<div><font face="Times-Roman">	? 	&#8220;NAT Behavioral Requirements for Unicast<br />
UDP&#8221;, F. Audet, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-udp-03.html">draft-ietf-behave-nat-udp-03</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This document defines basic terminology for describing different<br />
types of NAT behavior when handling Unicast UDP and also defines a set of<br />
requirements that would allow many applications, such as multimedia<br />
communications or on-line gaming, to work consistently. Developing NATs that<br />
meet this set of requirements will greatly increase the likelihood that these<br />
applications will function properly.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;A P2P Approach to SIP Registration and<br />
Resource Location&#8221;, D. A. Bryan, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-01.html">draft-bryan-sipping-p2p-01</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This document outlines the motivation and requirements for a<br />
Peer-to-Peer (P2P) based approach for SIP registration and resource discovery<br />
using distributed hash tables, and presents the architectural design for such a<br />
system. This design removes the need for central servers from SIP, while<br />
offering full backward compatibility with SIP, allowing reuse of existing<br />
clients, and allowing P2P enabled nodes to communicate with conventional SIP<br />
entities. A basic introduction to the concepts of P2P is presented, backward<br />
compatibility issues addressed, and the security considerations are considered.<br />
This is very early work to explore the characteristics that a P2P system might<br />
have. It is less secure in many ways than the traditional approach to SIP but<br />
has certain other interesting characteristics that may make it desirable in some<br />
situations. This work is being discussed on the sipping@ietf.org mailing<br />
list.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;The Message Session Relay Protocol&#8221;, B.<br />
Campbell, R. Mahy, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-sessions-11.txt.html">draft-ietf-simple-message-sessions-11.txt</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This document describes the Message Session Relay Protocol, a<br />
protocol for transmitting a series of related instant messages in the context of<br />
a session. Message sessions are treated like any other media stream when setup<br />
via a rendezvous or session setup protocol such as the Session Initiation<br />
Protocol.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Relay Extensions for the Message<br />
Sessions Relay Protocol (MSRP)&#8221;, C. Jennings, R. Mahy, A. B. Roach, July 2005,<br />
<a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-relays-05.txt.html">draft-ietf-simple-msrp-relays-05.txt</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: The SIMPLE Working Group uses two separate models for conveying<br />
instant messages. Pager-mode messages stand alone and are not part of a SIP<br />
(Session Initiation Protocol) session, whereas Session-mode messages are set up<br />
as part of a session using the SIP protocol. MSRP (Message Sessions Relay<br />
Protocol) is a protocol for near-real-time, peer-to-peer exchanges of binary<br />
content without intermediaries, which is designed to be signaled using a<br />
separate rendezvous protocol such as SIP. This document introduces the notion of<br />
message relay intermediaries to MSRP and describes the extensions necessary to<br />
use them.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Response Identity and Authentication in<br />
Session Initiation Protocol&#8221;, F. Cao, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-cao-sip-response-auth-00.html">draft-cao-sip-response-auth-00</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This draft describes some extensions for verifying SIP response<br />
identity and enhancing SIP response authentication. Some mechanisms are<br />
demonstrated for providing and verifying the identity of SIP responses. In order<br />
to prevent several kinds of security attacks through SIP response, SIP response<br />
authentication should be provided through a chain of trust of the SIP responses.<br />
Some extensions are proposed to enhance the per-hop authentication for handling<br />
SIP response. This draft is an early work in progress and suggests some<br />
approaches but there is still significant discussion needed. Some of the attacks<br />
discussed in this draft can be mitigated by using the sips URL.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Managing Client Initiated Connections<br />
in the Session Initiation Protocol (SIP)&#8221;, C. Jennings, R. Mahy, July 2005,<br />
<a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-00.html">draft-ietf-sip-outbound-00</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate<br />
TCP connections and send asynchronous UDP datagrams to User Agents in order to<br />
deliver requests. However, many practical considerations, such as the existence<br />
of firewalls and NATs, prevent servers from connecting to User Agents in this<br />
way. Even when a proxy server can open a TCP connection to a User Agent, most<br />
User Agents lack a certificate suitable to act as a TLS server. This<br />
specification defines behaviors for user agents, registrars and proxy servers<br />
that allow requests to be delivered on existing connections established by the<br />
User Agent. It also defines keep alive behaviors needed to keep NAT bindings<br />
open and specifies the usage of multiple connections for high availability<br />
systems.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Certificate Management Service for The<br />
Session Initiation Protocol (SIP)&#8221;, C. Jennings, J. Peterson, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sipping-certs-02.html">draft-ietf-sipping-certs-02</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This draft defines a Credential Service that allows SIP User Agents<br />
to use a SIP package to discover the certificates of other users. This mechanism<br />
allows user agents that want to contact a given Address-of-Record (AOR) to<br />
retrieve that AOR&#8217;s certificate by subscribing to the Credential Service. The<br />
Credential Service also allows users to store and retrieve their own<br />
certificates and private keys.</font></div>
<div><font face="Times-Roman">	? 	&#8220;NAT Classification Test Results&#8221;, C.<br />
Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-behave-test-results-01.html">draft-jennings-behave-test-results-01</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: IETF has several groups that are considering the impact of NATs on<br />
various protocols. Having a classification of the types of NATs that are being<br />
developed and deployed is useful in gauging the impact of various solutions.<br />
This draft records the results of classifying NATs. This draft is not complete<br />
and has only a few test results but it is worth discussing all the testing we<br />
wish to do before all the test results are collected. The test results here are<br />
very old and work is being done to update them with more current information.<br />
This work is being discussed on the ietf-behave@list.sipfoundry.org mailing<br />
list</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;vCard Extensions for Instant Messaging<br />
(IM)&#8221;, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-impp-vcard-05.html">draft-jennings-impp-vcard-05</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This document describes an extension to vCard to support Instant<br />
Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming<br />
increasingly common ways of communicating, and users want to save this contact<br />
information in their address books. This draft allows a URI that is associated<br />
with IM or PP to be specified inside of a vCard.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Using DTLS as a Transport for SIP&#8221;, C.<br />
Jennings, N. Modadugu, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-01.html">draft-jennings-sip-dtls-01</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This draft specifies how to use Datagram Transport Layer Security<br />
(DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security<br />
over a datagram protocol. This draft is being discussed on the sip@ietf.org<br />
mailing list.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Computational Puzzles for SPAM<br />
Reduction in SIP&#8221;, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-02.html">draft-jennings-sip-hashcash-02</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: One of the techniques used in SPAM prevention and various solutions<br />
for denial of service attacks is to force the SIP client requesting a service to<br />
perform a calculation that limits the rate and increases the cost of the<br />
request. This draft defines a way to allow a UAS to ask the UAC to compute a<br />
computationally expensive hash based function and present the result to the UAS.<br />
Although the computation is expensive for the UAC to compute, it is cheap for<br />
the UAS to verify. The solution also allows for proxies to compute and check the<br />
puzzle on behalf of the UAC or UAS.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Example call flows using SIP security<br />
mechanisms&#8221;, C. Jennings, K. Ono, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-sec-flows-03.html">draft-jennings-sip-sec-flows-03</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: This document shows call flows demonstrating the use of SIPS, TLS,<br />
and S/MIME in SIP. This draft provides information that helps implementers build<br />
interoperable SIP software. It is purely informational. To help facilitate<br />
interoperability testing, it includes certificates used in the example call<br />
flows and a CA certificate to create certificates for testing. This work is<br />
being discussed on the sip@ietf.org mailing list.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Conventions for Voicemail URIs in SIP&#8221;,<br />
C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-voicemail-uri-04.html">draft-jennings-sip-voicemail-uri-04</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: The SIP protocol is often used to initiate connections to voicemail<br />
or unified messaging systems. This specification describes a convention for<br />
forming SIP Service URIs that request particular services from unified messaging<br />
systems.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Instance Identifiers for SIP User<br />
Agents&#8221;, C. Jennings, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-instance-id-01.txt.html">draft-jennings-sipping-instance-id-01.txt</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: There are circumstances in SIP-based communications systems in which<br />
it is useful to have a long-term, stable identifier for a particular user agent.<br />
This specification outlines requirements and discusses existing standards that<br />
can be used to satisfy this need.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;SIP Offer/Answer with Multipart<br />
Alternative&#8221;, C. Jennings, D. Wing, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-multipart-01.html">draft-jennings-sipping-multipart-01</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: SIP needs a mechanism for general backwards compatibility for moving<br />
from SDP to SDPng or moving from non end-to-end encrypted SDP to end-to-end<br />
encrypted SDP. This document specifies how a SIP offer uses<br />
multipart/alternative, and how an answer indicates which part was<br />
selected.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Payment for Services in Session<br />
Initiation Protocol (SIP)&#8221;, C. Jennings, G. Jun, J. Fischl, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-pay-02.html">draft-jennings-sipping-pay-02</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: Communication systems require that a person receiving a call be able<br />
able to charge the caller when they are from different administrative domains.<br />
This is necessary for making fair exchanges of service between two different<br />
communicating parties and is a major strategy for reducing the viability of<br />
SPAM. This draft proposes an approach for doing this in SIP. The approach relies<br />
on a third party to act as a payment service provider and is optimized for very<br />
simple, low value transactions. It does not provide the full range of services<br />
that are desirable in typical online trading systems. This draft is being<br />
discussed on the sipping@ietf.org mailing list. There is currently work to<br />
substantially change this draft to use SAML.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Conference State Change Protocol<br />
(CSCP)&#8221;, C. Jennings, A. B. Roach, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-xcon-cscp-01.html">draft-jennings-xcon-cscp-01</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: Conference State Control Protocol (CSCP) is a means to modify the<br />
state in a conference service. It extends the Binary Floor Control Protocol and<br />
adds commands to get, set, add, and delete fields in the conference<br />
state.</font></div>
<div></div>
<div><font face="Times-Roman">	? 	&#8220;Media Conference Server Control for<br />
XCON&#8221;, C. Jennings, B. Rosen, July 2005, <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-xcon-media-control-03.html">draft-jennings-xcon-media-control-03</a></font></div>
<div><font face="Times-Roman">	</font><font face="LucidaGrande">?</font><font face="Times-Roman"><br />
Abstract: Conference servers have many controls that change how the media is<br />
combined for the various conference participants. It is necessary to describe<br />
these controls to the clients connected to a centralized conference, so that the<br />
clients can render a user interface and allow the user to manipulate them. This<br />
work is being discussed on the xcon@ietf.org mailing list. This draft has not<br />
changed since the 02 version.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/07/drafts-from-this-ietf/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>More fluff?</title>
		<link>http://www.dial911anddie.com/weblog/2005/07/more-fluff/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/07/more-fluff/#comments</comments>
		<pubDate>Fri, 08 Jul 2005 00:41:28 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/07/more-fluff/</guid>
		<description><![CDATA[I think some of the open source code written with security in mind has some of the best security around anywhere. http://searchenterprisevoice.techtarget.com/qna/0,289202,sid66_gci1103827,00.html]]></description>
			<content:encoded><![CDATA[<p>
I think some of the open source code written with security in mind has some of the best security around anywhere.<br />
<br /><a href="http://searchenterprisevoice.techtarget.com/qna/0,289202,sid66_gci1103827,00.html"><br />
<br />http://searchenterprisevoice.techtarget.com/qna/0,289202,sid66_gci1103827,00.html</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/07/more-fluff/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Session Initiation Protocol (SIP) and Spam</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/the-session-initiation-protocol-sip-and-spam/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/the-session-initiation-protocol-sip-and-spam/#comments</comments>
		<pubDate>Mon, 21 Feb 2005 19:48:02 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/the-session-initiation-protocol-sip-and-spam/</guid>
		<description><![CDATA[draft-ietf-sipping-spam-00 Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user to user communications. The Session Initiation Protocol (SIP) defines a system for user to user multimedia communications. Therefore, it is susceptible to spam, just as email [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://www.jdrosen.net/papers/draft-ietf-sipping-spam-00.txt"<br />
target="NewWindow">draft-ietf-sipping-spam-00</a> </font></div>
<p><span id="more-48"></span></p>
<div><font face="Helvetica">Spam, defined as the transmission of bulk<br />
unsolicited messages, has plagued Internet email.  Unfortunately, spam is not<br />
limited to email. It can affect any system that enables user to user<br />
communications. The Session Initiation Protocol (SIP) defines a system for user<br />
to user multimedia communications.  Therefore, it is susceptible to spam, just<br />
as email is.  In this document, we analyze the problem of spam in SIP.  We first<br />
identify the ways in which the problem is the same and the ways in which it is<br />
different from email.  We then  examine the various possible solutions that have<br />
been discussed for email and consider their applicability to SIP. </font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/the-session-initiation-protocol-sip-and-spam/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Certificate Management Service for The Session Initiation Protocol (SIP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/certificate-management-service-for-the-session-initiation-protocol-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/certificate-management-service-for-the-session-initiation-protocol-sip/#comments</comments>
		<pubDate>Mon, 21 Feb 2005 19:37:00 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/certificate-management-service-for-the-session-initiation-protocol-sip/</guid>
		<description><![CDATA[draft-ietf-sipping-certs-01 This draft defines a Credential Service that allows SIP User Agents to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR&#8217;s certificate by subscribing to the Credential Service. The Credential Service also allows users to [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sipping-certs-01.html"<br />
target="NewWindow">draft-ietf-sipping-certs-01</a> </font></div>
<p><span id="more-47"></span></p>
<div><font face="Helvetica" size="4">This draft defines a Credential Service<br />
that allows SIP User Agents to use  a SIP package to discover the certificates<br />
of other users. This mechanism  allows user agents that want to contact a given<br />
Address-of-Record (AOR) to  retrieve that AOR&#8217;s certificate by subscribing to<br />
the Credential  Service. The Credential Service also allows users to store and<br />
retrieve  their own certificates and private keys.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/certificate-management-service-for-the-session-initiation-protocol-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Payment for Services in Session Initiation Protocol (SIP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/payment-for-services-in-session-initiation-protocol-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/payment-for-services-in-session-initiation-protocol-sip/#comments</comments>
		<pubDate>Sun, 20 Feb 2005 19:51:30 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/payment-for-services-in-session-initiation-protocol-sip/</guid>
		<description><![CDATA[draft-jennings-sipping-pay-01 Communication systems require that a person receiving a call be able able to charge the caller when they are from different administrative domains. This is necessary for making fair exchanges of service between two different communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"> <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-pay-01.html"<br />
target="NewWindow">draft-jennings-sipping-pay-01</a> </font></div>
<p><span id="more-46"></span></p>
<div><font face="Helvetica" size="4">Communication systems require that<br />
a person receiving a call be able able to charge the caller when they are from<br />
different administrative domains. This is necessary for making fair exchanges of<br />
service between two different communicating parties and is a major strategy for<br />
reducing the viability of SPAM. This draft proposes an approach for doing this<br />
in SIP. The approach relies on a third party to act as a payment service<br />
provider and is optimized for very simple, low value transactions. It does not<br />
provide the full range of services that are desirable in typical online trading<br />
systems.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/payment-for-services-in-session-initiation-protocol-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Media Conference Server Control for XCON</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/media-conference-server-control-for-xcon/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/media-conference-server-control-for-xcon/#comments</comments>
		<pubDate>Sun, 20 Feb 2005 19:45:16 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/media-conference-server-control-for-xcon/</guid>
		<description><![CDATA[draft-jennings-xcon-media-control-02 Conference servers have many controls that change how the media is combined for the various conference participants. It is necessary to describe these controls to the clients connected to a centralized conference, so that the clients can render a user interface and allow the user to manipulate them.]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-xcon-media-control-02.html"<br />
target="NewWindow">draft-jennings-xcon-media-control-02</a><br />
</font></div>
<p><span id="more-45"></span></p>
<div><font face="Helvetica" size="4">Conference servers have many controls<br />
that change how the media is combined for the various conference participants.<br />
It is necessary to describe these controls to the clients connected to a<br />
centralized conference, so that the clients can render a user interface and<br />
allow the user to manipulate them.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/media-conference-server-control-for-xcon/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Message Session Relay Protocol</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/the-message-session-relay-protocol/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/the-message-session-relay-protocol/#comments</comments>
		<pubDate>Sun, 20 Feb 2005 19:42:53 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/the-message-session-relay-protocol/</guid>
		<description><![CDATA[draft-ietf-simple-message-sessions-10 This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP).]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-sessions-10.html"<br />
target="NewWindow">draft-ietf-simple-message-sessions-10</a><br />
</font></div>
<p><span id="more-44"></span></p>
<div><font face="Helvetica" size="4">This document describes the Message<br />
Session Relay Protocol (MSRP), a protocol for transmitting a series of related<br />
instant messages in the context of a session. Message sessions are treated like<br />
any other media stream when setup via a rendezvous or session setup protocol<br />
such as the Session Initiation Protocol (SIP).</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/the-message-session-relay-protocol/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Example call flows using SIP security mechanisms</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/example-call-flows-using-sip-security-mechanisms/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/example-call-flows-using-sip-security-mechanisms/#comments</comments>
		<pubDate>Sun, 20 Feb 2005 04:00:54 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/example-call-flows-using-sip-security-mechanisms/</guid>
		<description><![CDATA[draft-jennings-sip-sec-flows-02 This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementers build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing.]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-sec-flows-02.html"<br />
target="NewWindow">draft-jennings-sip-sec-flows-02</a> </font></div>
<p><span id="more-42"></span></p>
<div><font face="Helvetica" size="4">This document shows call flows<br />
demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides<br />
information that helps implementers build interoperable SIP software. It is<br />
purely informational. To help facilitate interoperability testing, it includes<br />
certificates used in the example call flows and a CA certificate to create<br />
certificates for testing.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/example-call-flows-using-sip-security-mechanisms/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Relay Extensions for the Message Sessions Relay Protocol (MSRP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/relay-extensions-for-the-message-sessions-relay-protocol-msrp/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/relay-extensions-for-the-message-sessions-relay-protocol-msrp/#comments</comments>
		<pubDate>Sat, 19 Feb 2005 19:43:48 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/relay-extensions-for-the-message-sessions-relay-protocol-msrp/</guid>
		<description><![CDATA[draft-ietf-simple-msrp-relays-03 The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-relays-03.html"<br />
target="NewWindow">draft-ietf-simple-msrp-relays-03</a> </font></div>
<p><span id="more-41"></span></p>
<div><font face="Helvetica" size="4">The SIMPLE Working Group uses two<br />
separate models for conveying instant messages. Pager-mode messages stand alone<br />
and are not part of a SIP (Session Initiation Protocol) session, whereas<br />
Session-mode messages are setup as part of a session using the SIP protocol.<br />
MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time,<br />
peer-to-peer exchange of binary content without intermediaries, which is<br />
designed to be signaled using a separate rendezvous protocol such as SIP. This<br />
document introduces the notion of message relay intermediaries to MSRP and<br />
describes the extensions necessary to use them.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/relay-extensions-for-the-message-sessions-relay-protocol-msrp/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SIP Conventions for UAs with Outbound Only Connections</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/sip-conventions-for-uas-with-outbound-only-connections/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/sip-conventions-for-uas-with-outbound-only-connections/#comments</comments>
		<pubDate>Sat, 19 Feb 2005 19:38:54 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/sip-conventions-for-uas-with-outbound-only-connections/</guid>
		<description><![CDATA[draft-jennings-sipping-outbound-01 Often with SIP a request can only be routed over an existing connection or flow, such as when there is a firewall or network address translation (NAT) device in the network path. TLS is also affected when the user agent (UA) does not have a certificate suitable for mutual TLS authentication. This draft addresses [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"> <a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-outbound-01.html"<br />
target="NewWindow">draft-jennings-sipping-outbound-01</a> </font></div>
<p><span id="more-40"></span></p>
<div><font face="Helvetica" size="4">Often with SIP a request can only be<br />
routed over an existing connection or flow, such as when there is a firewall or<br />
network address translation (NAT) device in the network path. TLS is also<br />
affected when the user agent (UA) does not have a certificate suitable for<br />
mutual TLS authentication. This draft addresses how user agents and proxies need<br />
to behave to work in these<br />
environments.</font></p>
<p><font face="Helvetica" size="4"> This work shows<br />
how existing SIP mechanisms can be used to allow the UA to register multiple<br />
times over different connections or flows and the proxies can use the<br />
instance-id in the contact header to identify that the multiple flows go to the<br />
same UA. It can then choose which flow to use to route requests to this<br />
UA.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/sip-conventions-for-uas-with-outbound-only-connections/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SIP Computational Puzzles</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/sip-computational-puzzles/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/sip-computational-puzzles/#comments</comments>
		<pubDate>Sat, 19 Feb 2005 03:59:36 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/sip-computational-puzzles/</guid>
		<description><![CDATA[draft-jennings-sip-hashcash-01 One of the techniques used in SPAM prevention and various solutions for denial of service attacks is to force the SIP client requesting a service to perform a calculation that limits the rate and increases the cost of the request. This draft defines a way to allow a UAS to ask the UAC to [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica" size="4"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-01.html"<br />
target="NewWindow">draft-jennings-sip-hashcash-01</a> </font></div>
<p><span id="more-39"></span></p>
<div><font face="Helvetica" size="4">One of the techniques used in SPAM<br />
prevention and various solutions for denial of service attacks is to force the<br />
SIP client requesting a service to perform a calculation that limits the rate<br />
and increases the cost of the request. This draft defines a way to allow a UAS<br />
to ask the UAC to compute a computationally expensive hash based function and<br />
present the result to the UAS. Although the computation is expensive for the UAC<br />
to compute, it is cheap for the UAS to verify. The solution also allows for<br />
proxies to compute and check the puzzle on behalf of the UAC or<br />
UAS.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/sip-computational-puzzles/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Guidelines for implementors using connection-oriented transports in the Session Initiation Protocol (SIP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/guidelines-for-implementors-using-connection-oriented-transports-in-the-session-initiation-protocol-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/guidelines-for-implementors-using-connection-oriented-transports-in-the-session-initiation-protocol-sip/#comments</comments>
		<pubDate>Mon, 14 Feb 2005 19:53:12 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/guidelines-for-implementors-using-connection-oriented-transports-in-the-session-initiation-protocol-sip/</guid>
		<description><![CDATA[draft-gurbani-sipping-connection-guidelines-01 The growing SIP message size and the ensuing IP fragmentation, scalability and performance efficiencies gained by multiplexing SIP sessions over fewer reliable transport connections, efficient use of security certificates etc. are engendering widespread use of connection-oriented protocols for SIP transport. A variety of SIP transport related issues are currently being discussed in the IETF [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/draft-gurbani-sipping-connection-guidelines-01.html"<br />
target="NewWindow">draft-gurbani-sipping-connection-guidelines-01</a><br />
</font></div>
<div></div>
<p><span id="more-37"></span></p>
<div><font face="Verdana" size="4">The growing SIP message size and the<br />
ensuing IP fragmentation, scalability and performance efficiencies gained by<br />
multiplexing SIP sessions over fewer reliable transport connections, efficient<br />
use of security certificates etc. are engendering widespread use of<br />
connection-oriented protocols for SIP transport. A variety of SIP transport<br />
related issues are currently being discussed in the IETF including connection<br />
reuse, persistent connections, outbound connection flows, SIP over SCTP, NAT<br />
traversal, and SIP/TCP race conditions. This document attempts to unify these<br />
techniques by describing practical guidelines for implementers and takes a broad<br />
stroke at defining SIP Connection Management. We hope to abstract the diverse<br />
connection techniques into a few generic connection characteristics, which then<br />
help define a few common connection models and use cases.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/guidelines-for-implementors-using-connection-oriented-transports-in-the-session-initiation-protocol-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NAT Classification Test Results</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/nat-classification-test-results/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/nat-classification-test-results/#comments</comments>
		<pubDate>Mon, 14 Feb 2005 03:48:57 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/nat-classification-test-results/</guid>
		<description><![CDATA[draft-jennings-behave-test-results-00 IETF has several groups that are considering the impact of NATs on various protocols. Having a classification of the types of NATs that are being developed and deployed is useful in gauging the impact of various solutions. This draft records the results of classifying NATs. This draft is not complete and has only a [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica-Bold" size="5"><b><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-behave-test-resutls-00.html"<br />
target="NewWindow">draft-jennings-behave-test-results-00</a></b></font><font face="Helvetica-Bold" size="5" color="#333333"><b><br />
</b></font></div>
<p><span id="more-36"></span></p>
<div><font face="Helvetica" size="4">IETF has several groups that are<br />
considering the impact of NATs on various protocols. Having a classification of<br />
the types of NATs that are being developed and deployed is useful in gauging the<br />
impact of various solutions. This draft records the results of classifying<br />
NATs.</font></p>
<p><font face="Helvetica" size="4"> This draft is not<br />
complete and has only a few test results but it is worth discussing all the<br />
testing we wish to do before all the test results are collected.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/nat-classification-test-results/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Conference State Change Protocol (CSCP)</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/conference-state-change-protocol-cscp/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/conference-state-change-protocol-cscp/#comments</comments>
		<pubDate>Sun, 13 Feb 2005 03:47:36 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/conference-state-change-protocol-cscp/</guid>
		<description><![CDATA[draft-jennings-xcon-cscp-00 Conference State Control Protocol (CSCP) is a means to modify the state in a conference service. It extends the Binary Floor Control Protocol and adds commands to get, set, add, and delete fields in the conference state.]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica-Bold" size="5"><b><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-xcon-cscp-00.html"<br />
target="NewWindow">draft-jennings-xcon-cscp-00</a></b></font><font face="Helvetica-Bold" size="5" color="#333333"><b><br />
</b></font></div>
<p><span id="more-35"></span></p>
<div><font face="Helvetica" size="4">Conference State Control Protocol (CSCP)<br />
is a means to modify the state in a conference service. It extends the Binary<br />
Floor Control Protocol and adds commands to get, set, add, and delete fields in<br />
the conference state.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/conference-state-change-protocol-cscp/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SIP Offer/Answer with Multipart MIME</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/sip-offeranswer-with-multipart-mime/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/sip-offeranswer-with-multipart-mime/#comments</comments>
		<pubDate>Sun, 13 Feb 2005 03:46:40 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/sip-offeranswer-with-multipart-mime/</guid>
		<description><![CDATA[draft-jennings-sipping-multipart-00 This document addresses the issues around using multipart with the SIP offer/answer framework. It specifies a way to make an offer with a multipart/alternative MIME body and for the answer to indicate which of the parts was selected for the answer. This is needed for general backwards compatibility to allow migration in situations such [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica-Bold" size="5"><b><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sipping-multipart-00.html"<br />
target="NewWindow">draft-jennings-sipping-multipart-00</a></b></font><font face="Helvetica-Bold" size="5" color="#333333"><b><br />
</b></font></div>
<p><span id="more-34"></span></p>
<div><font face="Helvetica" size="4">This document addresses the issues<br />
around using multipart with the SIP  offer/answer framework. It specifies a way<br />
to make an offer with a  multipart/alternative MIME body and for the answer to<br />
indicate which of  the parts was selected for the answer. This is needed for<br />
general  backwards compatibility to allow migration in situations such as moving<br />
from SDP to SDPng or moving from non end-to-end encrypted SDP to  encrypted<br />
SDP.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/sip-offeranswer-with-multipart-mime/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Using DTLS as a Transport for SIP</title>
		<link>http://www.dial911anddie.com/weblog/2005/02/using-dtls-as-a-transport-for-sip/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/02/using-dtls-as-a-transport-for-sip/#comments</comments>
		<pubDate>Sun, 13 Feb 2005 03:44:01 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/02/using-dtls-as-a-transport-for-sip/</guid>
		<description><![CDATA[draft-jennings-sip-dtls-00 This draft specifies how to use Datagram Transport Layer Security (DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security over a datagram protocol.]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00.html"<br />
target="NewWindow">draft-jennings-sip-dtls-00</a></font></div>
<p><span id="more-33"></span></p>
<div><font face="Helvetica" size="4">This draft specifies how to use<br />
Datagram Transport Layer Security (DTLS) as a transport for SIP. DTLS is a new<br />
protocol for providing TLS security over a datagram protocol.</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/02/using-dtls-as-a-transport-for-sip/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NAT Behavioral Requirements for Unicast UDP</title>
		<link>http://www.dial911anddie.com/weblog/2005/01/nat-behavioral-requirements-for-unicast-udp/</link>
		<comments>http://www.dial911anddie.com/weblog/2005/01/nat-behavioral-requirements-for-unicast-udp/#comments</comments>
		<pubDate>Mon, 03 Jan 2005 19:49:16 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2005/01/nat-behavioral-requirements-for-unicast-udp/</guid>
		<description><![CDATA[draft-ietf-behave-nat-udp-00 This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP, and defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Times-Roman" size="5"><a<br />
href="http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-udp-00.html"<br />
target="NewWindow">draft-ietf-behave-nat-udp-00</a> </font></div>
<p><span id="more-22"></span></p>
<div><font face="Helvetica" size="4">This document defines basic terminology<br />
for describing different types of NAT  behavior when handling Unicast UDP, and<br />
defines a set of requirements that would  allow many applications, such as<br />
multimedia communications or on-line gaming, to  work consistently. Developing<br />
NATs that meet this set of requirements will greatly  increase the likelihood<br />
that these applications will function prop</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2005/01/nat-behavioral-requirements-for-unicast-udp/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Computer Vision for Line Drawings</title>
		<link>http://www.dial911anddie.com/weblog/2004/11/computer-vision-for-line-drawings/</link>
		<comments>http://www.dial911anddie.com/weblog/2004/11/computer-vision-for-line-drawings/#comments</comments>
		<pubDate>Fri, 12 Nov 2004 20:06:28 +0000</pubDate>
		<dc:creator>fluffy</dc:creator>
				<category><![CDATA[Papers]]></category>

		<guid isPermaLink="false">http://www.dial911anddie.com/weblog/2004/11/computer-vision-for-line-drawings/</guid>
		<description><![CDATA[May 1993 MSC Thesis at the University of Calgary by Cullen Jennings Modern maps and engineering diagrams are usually constructed and stored using GIS or CAD systems. A large number of drawings, however, exists only in a paper form. This thesis examines the problem of automatically converting such drawings and maps from raster image to [...]]]></description>
			<content:encoded><![CDATA[<div><font face="Helvetica">May 1993 MSC Thesis at the University of Calgary<br />
by Cullen Jennings</font></div>
<p><span id="more-12"></span></p>
<div><font face="Helvetica">Modern maps and engineering diagrams are usually<br />
constructed and stored using GIS or CAD systems. A large number of drawings,<br />
however, exists only in a paper form. This thesis examines the problem of<br />
automatically converting such drawings and maps from raster image to high<br />
quality vector GIS or CAD forms.</font></p>
<p><font face="Helvetica">This<br />
thesis begins with a review of previous work in the area and then proposes a new<br />
method based on findings about how human vision works and domain specific<br />
knowledge. Another system based on the classical work in this area is presented,<br />
to which the new system is compared. This comparison shows that the method<br />
proposed here obtains substantially better results than classical methods. The<br />
time a human operator could expect to spend correcting the errors created by<br />
this system would be less than one tenth of the time required to correct the<br />
errors created by a classical vectorization<br />
system.</font></p>
<p><font face="Helvetica"><a<br />
href="http://www.dial911anddie.com/papers/msc_thesis.pdf"<br />
target="NewWindow">http://www.dial911anddie.com/papers/msc_thesis.pdf</a><br />
</font></div>
]]></content:encoded>
			<wfw:commentRss>http://www.dial911anddie.com/weblog/2004/11/computer-vision-for-line-drawings/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

