Draft: draft-johnston-sipping-cc-uui-06
Reviewer: Vijay K. Gurbani <vkg@xxxxxxxxxxxxxxxxxx>
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/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
