Subject: [Sipping] consent framework

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 4 Feb 2006 11:48:01 +0100

Three questions / suggestions for http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-framework-03.txt:

1. Is it really needed to introduce a new request method ("CONSENT") for this? In particular Figure 4 is very similar to a presence scenario (EPA publishing state, triggering a notification) so why not use PUBLISH instead?

2. Instead of putting the URI to send the permission document to in a "Permission-Upload" header, why not add it to the body of the document instead? Then it could be protected using S/MIME (without the need for sips mentioned in section 5.2). The permission server (Figure 4) has no need to know this URI, nor do any proxies on the path. Furthermore, I imagine it would be nice if the framework would allow for other, non-SIP mechanisms to transport the permission response document. One possibility could be an HTML form in the body of the CONSENT (PUBLISH) request. The URI to send the reply to would then conveniently be placed in the 'action' parameter of the HTML <form> tag

3. Could it be useful to somehow combine the SUBSCRIBE for wait-permission and the REFER to trigger a CONSENT request into 1 request / mechanism? In figure 5, I could imagine something like:

(1) INVITE (wouldn't this need a "Supported: consent" header?)

(2) 470 Consent Needed
Consent-Needed: sip:[email-masked]
Contact: sip:456@Relay?method=SUBSCRIBE&Event=wait-permission

(3) ACK

(4) SUBSCRIBE sip:456@Relay
Event: wait-permission
Required: consent
Consent-Needed: sip:[email-masked] -> This would (by convention) trigger a CONSENT (PUBLISH) request

Regards,

Jeroen

_______________________________________________
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