[dispatch] Comments: draft-mohali-dispatch-cause-for-service-number-02.txt

[Mary Barnes <[e-mail]>]

In anticipation of doing the shepherd write-up, I have carefully reviewed
this document and it still needs some work before we can progress it.

Per the email discussion with Paul, I think we need to make sure this
document is particularly clear that the new value defined for the “cause”
URI parameter is only added to the Request-URI per RFC 4458.   The presence
of the “cause” URI parameter in the Request-URI is totally transparent to
the History-Info header field processing when the Request-URI is captured
in the hi-targeted-to-uri header field parameter.

For the functionality that is intended to be achieved with a new value for
the “cause” URI parameter, the retargeting entity needs to add the
History-Info header field, otherwise the Request-URI that contains the
desired information is lost, but that is generic functionality for any
application that needs to make decisions based on the original/retargeted
URIs.    Basically, this proposal is taking advantage of the functionality
defined in RFC 4458 for the new “cause” value and there is a dependency on
the History-Info header field to capture that information.  But, it’s the
end application that processes the History-Info header field that knows
what to do with that “cause” value.   There could still be some cases that
might work without History-Info if you weren’t doing multiple retargets.

My suggested changes below are intended to focus the document on the new
protocol impacts, leaving out mention of History-Info until a latter
section where the use of the new “cause” value is described.

Note, I’ve also identified some other editorial changes that I think can be
done without losing important aspects of the proposal and then I have
identified some  nits at the end:

1) Abstract:

I don’t think you really even need to mention History-Info in the
abstract.  Really, what you are doing is enabling a service in much the
same manner as RFC 4458 enabled voicemail for some scenarios.   So, I
suggest that you reword the abstract something like the following:

OLD:

   [RFC4458] defines a "cause" URI parameter as having predefined values

   for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting

   Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI.

   In particular, it may appear in the Request-URI and in the History-

   Info header field defined in [RFC7044] in some specific retargeted

   requests defined in this document.

   This specification creates a new predefined value for cases when the

   retargeting is caused by a specific service action leading to a

   called service access number translation.

   This document updates [RFC4458].

NEW:

   [RFC4458] defines a "cause" URI parameter as having predefined values

   for Redirecting reasons based on a mapping from ITU-T Q.732.2-5

   Redirecting Reasons. The "cause" URI parameter can be used in a SIP or

   SIPs URI. In particular, it may appear in the Request-URI in a SIP

   Request.  This specification creates a new predefined value for the

   "cause" URI parameter for cases when the retargeting is due to a
specific

   service action leading to a called service access number translation.

   This document updates [RFC4458].

2) Introduction:

a) I suggest to move the first 2 paragraphs to a new section that describes
handling of Request-URIs that contain a “cause” value indicating Service
Number Translation.

b) 3rd paragraph.  I suggest to reword this paragraph:

OLD:

   The "cause" URI parameter may be used in the

   Request-URI and in the History-info header field to indicate the

   service that the UserAgent Server (UAS) receiving the message should

   perform.

NEW:

   The "cause" URI parameter may be used in the

   Request-URI to indicate the

   service that the User Agent Server (UAS) receiving the message should
perform.

c) 4th paragraph: Remove the “Concurrently,” and start with “A mechanism…”

d) 5th paragraph. Remove since you haven’t brought History-Info into this
discussion yet.  You can add this clarifying point later to the section
that describes the handling of Request-URIs that contain the new cause
value.

3) Section 4 - Example.   Along the lines of the proposal to describe the
processing for the new “cause” URI parameter, I think it would help to have
a textual description for each of the steps in the message flow.


Proposed new section on how the new “cause” URI parameter value is
handled/processed:

===================================================================

It might be best to describe when that specific value for the “cause” is
used by the proxy/intermediary and then separately describe the behavior of
the UAS upon receipt of hi-targeted-to-uris that contain that “cause”
value.    I would suggest to add this section as a sub-section of section 3
or as a new section between sections 3 & 4 (note, you could follow the
model in section 2 of RFC 4458)

In terms of when the “cause” is added to the Request URI by the
proxy/intermediary, it’s important that it’s clear that the determination
of the new target is independent of processing done when the History-Info
header field is added - we worked very hard to make that quite clear (or as
clear as possible given SIP) in terms of not deviating from the processing
as described in RFC 3261.   This section would be where you add the warning
about not confusing the new “cause” value with the “cause” in the Reason
header field that is part of the History-Info header field.

In this new section, I think you ought to describe any interactions between
the new value for the “cause” URI parameters and the History-Info header
field parameters as was done in RFC 4458 (section 3).  You could preface
this discussion with the two paragraphs you had in the intro with
background on RFC 4244. In this section, I would expect to see things like
the following addressed/clarified:   does the UAS only look for the “cause”
URI parameter if there is an “mp” or “rc” tag or does it look for the
“cause” URI parameter and then look for “mp” and “rc” to know whether the
UAS needs to perform that specific service.  It also needs to be clear, of
course, that the end functionality you desire may not be achievable without
the History-Info header subsequently being added to the message and NOT
being removed along the way.   Although, I would think your application
ought to work as expected if that “cause” URI parameter value is in the
Request-URI.   Per RFC 7044, you ought to describe what will happen if a
History-Info header field with a Request-URI containing that value for the
“cause” URI parameter is removed.

Minor editorial changes:

===================

1) Introduction - 6th paragraph: I would suggest deleting that 2nd sentence
as I think many would debate whether that intention was actually realized
by that specification.   Then, you likely should add that reference at the
end of the first sentence.

2) I’m not sure that section 2 (Problem statement) adds much more than
what’s in the Introduction (which in the end is really more of an
Introduction and Overview).  So, you could just move the 2nd paragraph in
this section to the end of section 1 and state declaratively, something
like the following (using “at least” implies that it might cover other
things which begs the question what else might it cover unless you
actually  have something in mind) :

   The mechanism covers the IN services that can be

   identified in the ISUP signaling in the "called IN number" and

   "original called IN number" optional parameters defined in

   [ITU-T_Q.763] and used in ISUP/INAP interworking as described in

   [ITU-T_Q.1600].

Editorial nits:

==========

1) Introduction, 3rd paragraph:

- “services form” -> “services from”

- Expand the acronym TDM

2) Section 3 - Solution:

- 1st sentence remove the word “alternative”

- 2nd paragraph, 1st sentence: “reminded” -> “summarized”

>
>