Subject: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications

From: <[email-masked]>
Date: Tue, 24 May 2011 19:22:35 +0200

Hi,

I am not proposing a new working group but trying to find the good place
to solve the following problem.

Problem Statment
----------------

Decisions made by one application about how to handle a session often
depend on which other types of applications are involved in this
session. Hence, in the context of SIP, when several remote applications
are involved in the processing of one session, there is a need for a
mechanism enabling one application to explicitly identify itself when
issuing or re-targeting a request or response. This will enable
applications receiving this information to take appropriate decisions on
how to further process the session.

   1.  Need to convey the identity of the application having "acted" on
the call, in order to allow a downstream application to avoid
undesirable service interactions (e.g. by deciding whether to execute a
particular feature depending on the call history).
   2.  Need to convey the identity of the application having caused a
specific number translation and allow the transfer target to easily find
out the original number that this application had received, even in case
multiple successive number translations occured.
   3.  Need to convey the identity of the application having released
the call towards an upstream application that can take specific
decisions.

The draft is available at
http://tools.ietf.org/html/draft-mohali-dispatch-reason-for-applications
-00

Charter proposal
----------------
The Reason header field [RFC3326] provides a mechanism to signal the
reason why a SIP request or response was issued or why an initial
request was retargeted.
I-D draft-mohali-dispatch-reason-for-applications proposes to extend
RFC3326 registering a new protocol value "Application" for the Reason
Header field and a for registering application types (cause values). The
extension process is similar to RFC4411 that also extend the Reason
header.
This protocol value can be used anywhere the presence of a Reason Header
field is allowed.
For each new registered value, it has to be defined the following:
- Cause value:  this is an identifier number corresponding to the cause
value of the protocol-cause parameter in the Reason header field.
- Reason text:  this is a unique string identifying the application
name. The reason text is intended to give a short textual description of
the application.
- Description:  this is a description of the application and the
conditions under which this reason-value is used. 
 
The work consist in extending RFC3326 (Reason header) for applications
needs.

Goals and Milestones
--------------------

July 2011 Update to draft-mohali-dispatch-reason-for-applications
addressing concerns raised in the mailing list

July 2011 Present update to
draft-mohali-dispatch-reason-for-applications at IETF 81

Nov 2011 Present update to draft-mohali-dispatch-reason-for-applications
at IETF 82

Mar 2012 Submit draft-mohali-dispatch-reason-for-applications to IESG as
Proposed Standard RFC

Best Regards,
Marianne