[dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-03.txt

[<[e-mail]>]

Hi Mary and all,

Many thanks for your detailed and constructive review of the draft.
In this new version I included your suggestions and changed the structure of the sections.
Additional possible use cases and information on how the new value has to be used are describe to provide better guidelines for implementors.
The call flow has been enhanced with some additional explanations.

You can find the new version -03 of the draft here:

URL:            https://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service-number-03.txt

Status:         https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number/

Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-number-03

Diff:           https://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-service-number-03



Best regards,
Marianne Mohali

De : Mary Barnes [mailto:[e-mail]]
Envoyé : vendredi 22 mai 2015 01:50
À : MOHALI Marianne IMT/OLN
Cc : [e-mail]; Ben Campbell
Objet : Comments: draft-mohali-dispatch-cause-for-service-number-02.txt

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”



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.