Subject: [Sip] WGLC: draft-ietf-sip-consent-framework-00

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 26 Sep 2006 00:35:51 +0200

(As WG chair)

Because the document

A Framework for Consent-Based Communications in the Session Initiation
Protocol (SIP)

At

http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-00.
txt

Defines new response codes, and header fields, it has been transferred
to the SIP WG from SIPPING.

This mail is to announce Working Group Last Call for this document 
                         -----------------------
for which we request comments to be made by 

	17th October 2006
	-----------------

For each comment, please indicate clearly:
-	the nature of the comment (editorial, minor technical,
technical, spec is totally broken...), 
-	the position in the document (section and paragraph numbers
please (it helps if you also quote the sentence or paragraph you are
addressing),
-	the comment itself,
-	any proposed resolution.

This WGLC is coordinated with two related documents that remain in the
SIPPING group

draft-ietf-sipping-pending-additions-00.txt
draft-ietf-sipping-consent-format-00.txt

Regards

Keith

Keith Drage
[email-masked]
tel: +44 1793 776249

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 27 Sep 2006 13:06:13 +0200

Major technical comment on section 5.8: the proposed Trigger-Consent 
mechanism looks like one big hack to me. It does not comply with 
RFC3515, and appears to be an inappropriate use of REFER. Suggestion: 
use SUBSCRIBE / NOTIFY

Technical comment on Trigger-Consent: the ABNF in section 5.11 allows 
multiple instances of this header. Is this desired? If so, a note on 
what should be done when multiple instances are present is needed. If 
not, the ABNF should be adapted ( I suspect the latter is the 
appropriate choice )

Minor technical comment on Figure 5 and the example in 5.11: the 
escaping of the Refer-To URI is invalid, '<' and '>' should be 
%-encoded too (but: see first comment, suggest to remove this Refer-To 
header entirely)

Regards,

Jeroen