Draft: draft-johnston-sipping-cc-uui-06
Reviewer:  Vijay K. Gurbani <vkg@alcatel-lucent.com> 
Review Date: Dec. 22, 2008 
Review Deadline:  Dec. 22, 2008
Status: New

Summary: This draft is on the right track but has open issues, described in the review.

This draft describes a mechanism to transport ITU-T Q.931 User-to-User Information Elements (UU IE) data in SIP requests that establish and tear down a dialog.

Substantive issues:

1) S3, REQ-5: I am not sure I understand the motivation behind
  the indented text ("Passing a pointer or link to the UUI
  information will not meet the real-time processing
  considerations.")  To me, this indented text represents a
  new requirement:

    REQ-X: The mechanism should not require processing entities
    dereference a URL to retrieve the UUI information.

        Passing a pointer or link to the UUI information
        will not meet the real-time processing
        considerations.

2) I am not sure what is the value of Figure 5 if this call
  flow is not to be recommended.  Providing it in the main
  text body provides the impression that despite warnings,
  it may be okay to do this under certain circumstances.  I
  would suggest that you move this Figure to an Appendix,
  where it is away from the main text but still serves as a
  reminder of what not to do (a forward pointer to the Appendix
  can be provided somewhere in the main text.)

3) S5.3: I am not sure I follow the reasoning here.  Why will
  a URI parameter not survive retargeting by a proxy?  Let's
  assume that an AoR registers a Contact with this parameter.  Now,
  when a proxy does a location lookup on that AoR and retrieves
  the Contact URI, it is obligated to put all unknown URI parameters
  in the message's request URI, right (c.f., Section 19.1.5,
  RFC3261)?

  So, a retargeting as a result of location lookup should be
  okay, no?

4) S5.4, page 11: "The resulting INVITE F5 would contain the
  User-to-User header field of the previous example." -- which
  "previous example" is being referred to here?  Can you please
  insert the section or figure number of that example instead?

  In the same vein, a few lines down: "This would result in the
  INVITE F4 containing the User-to-User header field of the first
  example." -- "first example" as in the example in S4.1?  Please
  expand on which specific example you had in mind.

5) S5.4: So, in the end, are you saying that it is okay to include
  the new header as a Contact URI parameter or a Refer-To URI
  parameter because the processing entity will always end up
  creating a new header and inserting it appropriately (this
  touches upon my issue 3 above.)

  Maybe you need to break this section into two: in one (sub)
  section, you enunciate why existing headers like Call-Info
  cannot transport this new header and in the next (sub) section,
  you provide suggest the new header.

6) I do not know if we (as a WG) are still worried about the
  length of header fields as we once used to be, but if so,
  then in Appendix A, consider using the mnemonic "UUI"
  instead of "User-to-User" when defining the ABNF.

7) S8: If you wanted end-to-end integrity without using TLS, I
  believe you could include the UUI header in the list of
  signed headers carried by Identity.  This, of course, means
  that once inserted the UUI header does not change, but I
  believe that is indeed the case here.

Nits/typos/suggestions:

1) Abstract:
      OLD:
      This extension will also be used for native SIP endpoints
      implementing similar services and interworking with ISDN
      services.  This document discusses requirements and
      approaches and recommends a new header field be standardized.

      NEW:
      This document discusses requirements and approaches and
      recommends a new header field be standardized.  This
      extension will also be used for native SIP endpoints
      implementing similar services and interworking with
      ISDN services.

    Note that I simply changed the order of the sentences to make
    the text flow better.  In the OLD version, the advantages of
    an "extension" are made apparent even before there is any
    discussion that this document proposes an "extension".

2) S1: s/not able or desirable/neither feasible nor desirable/

3) S3: s/for this that the/this, in the same manner as/

4) S5.1: s/2976].,/2976]/

5) The title of S5.1 pre-disposes the exclusion of INFO as
  a suggested mechanism.  Maybe an objective title will be
  "The INFO method approach" and therein you could argue why
  INFO is not a good choice.

6) S5.4: s/which does not REQ-5/which does not meet REQ-5/