Re: [dispatch] Two week review: Progressing draft-mohali-dispatch-originating-cdiv-parameter as AD sponsored

[[e-mail] (Dale R. Worley)]

Review of draft-mohali-dispatch-originating-cdiv-parameter-02

Since 3GPP has a need for this work, and since it is compatible with
general SIP usage, I support progressing this document once the
following technical issues are resolved.

Dale
----------------------------------------------------------------------
These comments are based on my understanding of how the P-Served-User
header is used.  If my understanding is incorrect, it would probably
be useful to revise the text to clarifying the misunderstanding.

Technical:

- There has been discussion on the Dispatch mailing list of the
possibility of multiple P-Served-User headers in one request.  But it
appears to me that semantically there should never be more then one
P-Served-User header field value because the "orig", "orig-cdiv", and
"term" session cases are mutually exclusive for a particular session
at a particular time.  Indeed, since an AS uses P-Served-User to
determine the session case, having more than one in a request makes
the AS unable to determine the correct behavior.

I believe this is why RFC 5502 does not authorize repeating
P-Served-User, and why its ABNF does not allow a comma-separated list
of values.  However, RFC 5502 does not forbid repeating P-Served-User,
either.  I think it would be useful to either file an erratum to RFC
5502 specifying that P-Served-User cannot be repeated, or insert a
clause in this draft updating RFC 5502 in that manner.

- It seems that once the originating S-CSCF is done performing the
originating services, it must remove the P-Served-User header from the
INVITE before sending the INVITE to the transit/terminating proxy,
even if that proxy is within the same trust domain.  Otherwise, the
next proxy will have to obey the P-Served-User header:

    RFC 5502 section 7.2

   A proxy that supports the header MUST, upon receiving from a trusted
   node the P-Served-User header in initial requests for a dialog or in
   standalone requests, take the value of the P-Served-User header to
   represent the served user in operations that require such
   information.

However, this behavior is not specified in RFC 5502 section 7.2, which
only described removing P-Served-User when the request crosses a Trust
Domain boundary.

How does my expectation compare to the behavior of 3GPP systems?  Do
RFC 5502 sections 7.1 and 7.2 completely describe how 3GPP adds and
removes P-Served-User headers?

- It seems natural to me for "orig-cdiv" to be an alternative value of
the "sescase" parameter.  I.e., to change RFC 5502 to

    sessioncase-param        = "sescase" EQUAL ( "orig" / "orig-cdiv" / "term" )

"orig", "term", and "orig-cdiv" are mutually exclusive states of a
session, and that fact is naturally expressed by alternative values of
a single parameter.  (Of course, this change requires numerous small
edits in the document.)

- This example is given in section 4.2:

   P-Served-User: <sip:[e-mail]>; orig-cdiv; regstate=reg

However, the description in section 2 of the proxy behavior that
creates a P-Served-User header with "orig-cdiv" is:

   In that case, the S-CSCF updates
   the P-Served-User header field content by removing both "sescase" and
   "regstate" header field parameters and inserting the "orig-cdiv"
   header field parameter.

which can never create a P-Served-User header with both "orig-cdiv"
and "regstate".  The example should be updated to what can occur in
correct processing.

- The ABNF in RFC 5502 is incorrect:

   sessioncase-param        = "sescase" EQUAL "orig" / "term"
   registration-state-param = "regstate" EQUAL "unreg" / "reg"

As written, it means:

   sessioncase-param        = ( "sescase" EQUAL "orig" ) / "term"
   registration-state-param = ( "regstate" EQUAL "unreg" ) / "reg"

(because concatenation binds tighter than alternation) whereas what is
intended is:

   sessioncase-param        = "sescase" EQUAL ( "orig" / "term" )
   registration-state-param = "regstate" EQUAL ( "unreg" / "reg" )

I have filed this as erratum 4827 to 5502 (since 5502 as written did
not specify what was intended).  Perhaps this draft should normatively
update 5502 to fix this.

- In section 2, "Proxy behavior and parameter handling", is:

   In that case, the S-CSCF updates
   the P-Served-User header field content by removing both "sescase" and
   "regstate" header field parameters and inserting the "orig-cdiv"
   header field parameter.

However, it seems to me that the URI (PServedUser-value) will also
have to be changed.  Before diversion, during terminating processing,
the header is

    P-Served-User: sip:terminating-user;sescase=term

After diversion, during Originating CDIV processing, the header has to
be

    P-Served-User: sip:originating-user;orig-cdiv

Editorial:

- The use of the "vspace" element in
draft-mohali-dispatch-originating-cdiv-parameter-02.xml is unusual.
In places, '<vspace blankLines="1"/>' is used to generate what appears
to be a paragraph break, but (from the point of view of XML2RFC) is
not.

In other places, '<vspace/>' is used to break the line but not insert
a blank line, although the locations where that is done appear to me
to be good places for paragraph breaks.  That usage is uncommon in the
formatting of RFCs.

It seems to me that in both cases, replacing the vspace with a
paragraph break (in practice, changing it to "</t><t>" or "</t>{line
break}</t>") would use XML2RFC in a way more consonant with common
usage.

- In regard to keywords, "5502" is listed in the XML, but it seems
that the format "RFC5502" is the more common format.  You might want
to add the keyword "served user", as that seems to be the standard
3GPP term for the user identity on whose behalf services are being
executed.  (Or is that unnecessary because "served user" appears in
the Abstract?)  It would also help if the parameter itself, orig-cdiv,
appeared as a keyword.

- The long title, "P-Served-User Header Field Parameter for
Originating CDIV session case in [SIP]", is correct but hard to read.
One alternative is "A P-Served-User Header Field Parameter for
the Originating CDIV session case in [SIP]", or "The orig-cdiv
parameter of the P-Served-User Header Field for the Originating CDIV
session case in [SIP]".

Similarly, the start of the Abstract is hard to read:  'This
specification defines a new Session Initiation Protocol (SIP)
P-Served-User header field parameter, "orig-cdiv-param", which defines
the session case ...'  I think it would be easier to read as 'This
specification defines the "orig-cdiv" parameter of the P-Served-User
header field in the Session Initiation Protocol (SIP), which defines
the session case...'.

- The short title, "orig-cdiv session case" is difficult to understand
without the draft as context.  Perhaps "P-Served-User parameter
orig-cdiv".

- The phrase "orig-cdiv-param" and variants of it are used in various
places to describe the "orig-cdiv" parameter of the P-Served-User
header field.  It would be clearer and more correct to use the words
'"orig-cdiv" parameter', as "orig-cdiv-param" is only used as a
nonterminal in the ABNF.

- In section 1.2, "Use Case", is:

   Indeed, the originating user
   remains the same and the diverting user's originating services do not
   have to be triggered as if it was an originating call.  For instance,
   the originating user identity should not be hidden because the
   diverting user has a privacy service for his/her own identity.  In
   the same manner, some specific services may be triggered when
   performing a call diversion that would not be for a normal
   originating call.

Reading this text, I am not sure if IMS always processes diversions in
a one particular way, and that way is triggered by "orig-cdiv", or if
there are alternative ways that IMS allows.  (The words "Indeed
... remains ..." implies that a diverted call is always treated as
orig-cdiv, but the words "do not have to be triggered", "because the
diverting user has a privacy service", "may be triggered" suggest that
there are alternative processing choices.)

I suspect that there are two allowed alternatives:  (1) treat the
session as an originating call by the diverting user ("P-Served-User:
sip:diverting-user;sescase=orig"), or (2) treat the call as a
call-diversion origination by the originating user ("P-Served-User:
sip:originating-user;orig-cdiv").

In either case, the text should make it clearer what possibilities are
allowed in IMS.

- Section 5, "IANA Considerations", is:

   This specification defines a new P-Served-User header field parameter
   called orig-cdiv-param in the "Header Field Parameters and Parameter
   Values" sub-registry as per the registry created by [RFC3968].

   The syntax is defined in Section 4.

   The required information is:

                    Header Name            References
                    --------------      ------------------
                    P-Served-User       [RFC5502][RFCXXXX]

The shown "required information" does not match the structure of the
"Header Field Parameters and Parameter Values" registry, which is:

    Header Field    Parameter Name    Predefined Values    Reference 
    ------------    --------------    -----------------    ---------
    Accept          q                 No                   [RFC3261]
    Accept-Encoding q                 No                   [RFC3261]
    ...

However, the original error is in RFC 5502, which did not specify that
entries for P-Served-User be put into that registry.  (P-Served-User
is in the registry "Header Fields", however.)

It is not clear to me what the correct way to fix this is, but
ultimately, the "Header Field Parameters and Parameter Values"
registry must contain these three rows that it does not now contain:

    Header Field    Parameter Name    Predefined Values    Reference 
    ------------    --------------    -----------------    ---------
    P-Served-User   sescase           Yes                  [RFC5502]
    P-Served-User   regstate          Yes                  [RFC5502]
    P-Served-User   orig-cdiv         No                   [RFC5502]

Either this draft could provide all of these registrations, or an
erratum for RFC 5502 could provide the first two, and the last one is
provided by this draft.  In any case, the listed "required
information" in this draft needs to be revised.

Nits:

Abstract

   This document updates RFC5502 in order to add the originating after
   CDIV session case.

I think this could be clarified by adding double-quotes here:

   This document updates RFC5502 in order to add the "originating after
   CDIV" session case.

1.1.  General

   This document extends the P-Served-
   User header field to include the session case for a forwarded leg
   when a call diversion service (CDIV) has been invoked.

Does this processing apply to all call diversions or only some of
them?  If it applies in only some cases, I think the sentence needs to
be extended as "has been invoked and [certain conditions]."

   The generic-param of the P-Served-User is extended by the "orig-cdiv-
   param" created as a new parameter for this Originating_CDIV session
   case.

This isn't quite correct and isn't really how you want to phrase it.
Perhaps:

   The generic-param of the P-Served-User is extended by defining a
   parameter "orig-cdiv" for the Originating_CDIV session case.

But "Originating_CDIV" is used nowhere else in the draft, though
"Originating CDIV" (without the underscore) is used in the title.  Is
this the best term to use, and what is the standard punctuation to
use?

   header field parameter usage, Section 2 specifies the proxy behavior
   for the new header field parameter handling, and Section 3 discusses

I think this reads better if "handling" is moved: "... the proxy
behavior for handling the new header field parameter, ..."

   Section 4 describes the Syntax, 

s/Syntax/syntax/

   header field parameter with the IANA

s/the IANA/IANA/

1.2.  Use Case

   To be able to determine which responsibilities the S-CSCF and the
   Application Server haves to perform and on which user's behalf, it is
   necessary to know in which situation is the session and who is the
   current served user.[RFC5502] defines the originating and terminating
   session cases.

This could be made clearer, and also, it could define "session case":

   To be able to determine which responsibilities the S-CSCF and the
   Application Server have to perform and on which user's behalf, it is
   necessary to know the "session case", which is the current
   situation of the session, and the current "served user", which is
   the user on whose behalf originating or terminating services are
   being performed.[RFC5502]

2.  Proxy behavior and parameter handling

   The orig-cdiv-param header filed parameter can be used inside a trust

s/filed/field/

   In that case, the S-CSCF updates
   the P-Served-User header field content by removing both "sescase" and
   "regstate" header field parameters and inserting the "orig-cdiv"
   header field parameter.

I think it would be clearer if this sentence specified what value is
placed (or remains) in the PServedUser-value.  However, there is a
technical issue above regarding what that value should be.

   Then the procedure would continue forwarding the INVITE request over
   to an AS

The use of the subjunctive "would" does not match the rest of the
section.  Better would be "Then the procedure continues by forwarding
...".

   When the AS receives the INVITE request, it determines that the
   session case is for "orig-cdiv" session case and will perform the
   originating services to be executed after retargeting for the served
   user.

It would probably be clearer to add "... the served user, which is the
originating user, not the diverting user."

3.  Applicability

   The use of the P-Served-User header field extensions is only
   applicable inside a Trust Domain for served user.

I think the phrase "Trust Domain for served user" is intended to be
"Trust Domain for P-Served-User".  Both phrases are used in RFC 5502,
but the first one appears to be incorrect:  If one proxy trusts
another proxy, it trusts it for all values of P-Served-User, it does
not trust different sets of proxies for different served users -- as
is explained the next sentence of the section.

6.  Security Considerations

   As the orig-cdiv-param P-Served-User header field parameter can be

This would be easier to read as "As the orig-cdiv-param parameter of
P-Served-User can be ...".

[END]