Subject: [Sipping] I-D ACTION:draft-ietf-sipping-consent-framework-03.txt

From: [email-masked]
Date: Mon, 24 Oct 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: A Framework for Consent-Based Communications 
                          in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-sipping-consent-framework-03.txt
	Pages		: 20
	Date		: 2005-10-24
	
The Session Initiation Protocol (SIP) supports communications across
   many media types, including real-time audio, video, text, instant
   messaging, and presence.  In its current form, it allows session
   invitations, instant messages, and other requests to be delivered
   from one party to another without requiring explicit consent of the
   recipient.  Without such consent, it is possible for SIP to be used
   for malicious purposes, including spam and denial-of-service attacks.
   This document identifies a framework for consent-based communications
   in SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-framework-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-consent-framework-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-consent-framework-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2005 17:51:51 -0400

IMO this new version is much clearer than the prior version.
But I still have some questions about this one:

The use of REFER with norefersub is justified because the user is 
supposedly not interested in the result of the CONSENT transaction. It 
is true that if all goes well the wait-permission will be sufficient. 
But what if something goes wrong, and no PUBLISH will be forthcoming? 
(An example would be if the CONSENT cannot be delivered.) How would A 
discover this? Will something be sent to wait-permission subscribers in 
this case?

Permission revocation requires using the same URI as before to upload a 
new permission document. In the case of authentication by return 
routability, this requires the random-looking URIs to remain valid 
forever. And it seems that each must be bound to a specific 
recipient-uri. That seems like a bit of a pain for the server. (It can 
be done statelessly using crypto, but that increases the cost to the 
server of a CONSENT request.) Seems like there needs to be an escape 
hatch so these don't have to be valid forever. Perhaps an expires 
parameter on the Permission-Upload header could serve this purpose. 
After this time permission revocation would have to proceed as if the 
uri had been forgotten.

Registrations distinguish between two cases:
- when the entity registering is the one that will be receiving
   the traffic
- all other cases (incorrectly called third party registrations,
   which in fact are something else.)

I can't tell from the text if authorization is required for all 
registrations, or just those where the registering entity is *not* the 
one receiving the traffic.

Requiring this in the common case where the registering entity will be 
receiving the traffic seems at best impractical. But requiring it only 
in the exceptional cases requires being able to tell which is which. Do 
you know a way to do this?

This isn't a problem when combined with draft-ietf-sip-outbound-00.txt, 
where the contact is bound to a connection. But otherwise I can't see 
any solution that doesn't significantly increase the expense of normal 
registrations. :-(

	Paul