RE: [Sipping] Some comments for draft-jennings-sipping-pay-06

[<[e-mail]>]

 
I am resending this to you as I found the original
as corrupted after you forwarded it to the archive:
http://www1.ietf.org/mail-archive/web/sipping/current/msg14332.html

Could you please post it again so that it would appear
as complete within the archive ?


Hi,

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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP