Re: [Sipping] Some comments for draft-jennings-sipping-pay-06
<Erkki.Koivusalo@nokia.com> Mon, 06 August 2007 07:27 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHx05-00047N-P4; Mon, 06 Aug 2007 03:27:37 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1IHx03-00047F-OO for sipping-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 03:27:35 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHx03-000477-DA for sipping@ietf.org; Mon, 06 Aug 2007 03:27:35 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHx02-0007eT-2C for sipping@ietf.org; Mon, 06 Aug 2007 03:27:35 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l767R4XY020612 for <sipping@ietf.org>; Mon, 6 Aug 2007 10:27:31 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 10:26:33 +0300
Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 10:26:33 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sipping] Some comments for draft-jennings-sipping-pay-06
Date: Mon, 06 Aug 2007 10:26:33 +0300
Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03F03AA9@esebe103.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: [Sipping] Some comments for draft-jennings-sipping-pay-06
Thread-Index: AcfTnlrZjbRR/1uBTT2Lm6DxmU/MNwAqwbxwAOxgY2A=
From: Erkki.Koivusalo@nokia.com
To: sipping@ietf.org
X-OriginalArrivalTime: 06 Aug 2007 07:26:33.0535 (UTC) FILETIME=[1D84BCF0:01C7D7FB]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
Hi, I am resending this as the original email was for some reason corrupted on its way to archives: http://www1.ietf.org/mail-archive/web/sipping/current/msg14332.html I made a review of draft-jennings-sipping-pay-06 and have a few comments to it. Most of all I find that the structure and terminology within this document would need major improvements. 1. Definition of the new response codes - For some reasons the definitions for the two new SIP response codes 402 and 424 have been distributed to different parts of the document like this: 402 is introduced in sections - 5.2. 424 (Bad SAML Information) Response Code - 13.2. 402 Response 424 is introduced in sections - 7.1. Update response code 402 - 13.6. IANA Registration for Response Code 4XX I find this as inconsistent and do not understand such a split. Section 5 is for updated SAML SAML profile while section 7 is for SIP extensions. Is this OK ? In section 14 the contents of the sections 13.2 and 13.6 should be made consistent and merged. - Just noted that draft-ietf-sip-location-conveyance-08 uses the same 424 response code for a different purpose (Bad Location Information). 2. Usage of the terms Offer and Payment Request - I find the usage of the term Offer confusing as it can be mixed up with the SDP offer in the offer-answer model. This confusion is most disturbing in section 1 Introduction as it appears before the section 2 Terminology. One option would be to instead use the term "Payment Offer" throughout the document instead of the term "Offer" to make it unambiguous. - I would however prefer to change the terminology as follows: * Substitute "Payment Offer" and "Offer" with "Payment Request" * Substitute "Request for Payment" with "Payment Order" To me it would sound as more locical as the Merchant is actually requesting the Customer to pay and the Customer consequently is placing a payment order to the Payment Provider. 3. Option tags - Section 5.1 introduces two option tags but I wonder if the option tag is the correct term for those ? They are at least not SIP option tags in RFC 3261 sense as they are not expected to appear in Supported, Require or Proxy-Require header. - Section 5.1 introduces an option tag "unable-SAML" and later on refers to it as "Unknown-SAML" option tag. The latter is used also in section 13. Worse more I find the rationale for such a tag totally uncomprehensible. Please either remove this tag or clarify the text and give some clear examples for the briefly mentioned use cases: "The Unknown-SAML option tag in a SAML header indicates a UA understands the concept of SAML conveyance, but does not have the desired SAML assertion to provide. This can save error messages from being generated looking for an answer the UA does not have to give. It can also allow a processing entity the immediate knowledge it needs to act as if the UA will not learn SAML on its own, and perhaps call on another process to address the needs for that message." 4. Customer proxy acting on behalf of the Customer - Section 6.4.2 introduces a case where the proxy will contact the Payment Provider on behalf of the Customer. The related text lacks an explanation how the proxy can decide whether to accept to pay and if yes, how much to pay. I believe that for this scenario there should be some discussion how the proxy could get the Customer's credentials and the policy with which to do the decisions. 5. Payment Provider Behavior - Returning any error is described in step 1 after the Provider has checked the customer-id and credentials. I suggest moving this description between steps 4 and 5 where the Provider has performed all the relevant checks. 6. Other - Definitions for the purpose and semantics of the different XML attributes like merchantBits, merchantId etc. should be given somewhere. Now it takes some trouble to find out (as an educated guess) that e.g. merchantId identifies an account for the Merchant. - I suggest collecting all the normative text for the UAS (Merchant) into section 6.2: - Contents of section 8.5 Verifying the Receipt should probably be merged into section 6.2. UAS Behavior (Merchant) - Contents of section 6.6 Merchant Fetching Public Key should also be moved into section 6.2 - Section 6.4 Transition Scenarios should be pulled out of section 6. Section 6 is expected to contain the normative text for various elements while 6.4 is providing examples for some transition scenarios. If some of the UAS behavior will be done by a proxy in some transition scenario then the section describing the scenario should just make references to the text within section 6.2 UAS behavior. Regards, Erkki Koivusalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- RE: [Sipping] Some comments for draft-jennings-si… Erkki.Koivusalo
- Re: [Sipping] Some comments for draft-jennings-si… Erkki.Koivusalo