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

[<[e-mail]>]

Hi,

I've submitted a new version (-03) for the P-Served-User header extension defining the originating-cdiv session case hereafter:
URL:            https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-03.txt
Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-originating-cdiv-parameter-03

I've tried to take on board all the comments I received from Dale and others. This version contains a huge number of improvements.

If you have more comments on this version, please don't hesitate.

Best regards,
Marianne

> -----Message d'origine-----
> De : dispatch [mailto:[e-mail]] De la part de Dale R. Worley
> Envoyé : mercredi 12 octobre 2016 00:00
> À : [e-mail]
> Objet : Re: [dispatch] Two week review: Progressing draft-mohali-dispatch-
> originating-cdiv-parameter as AD sponsored
> 
> 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]
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch

_________________________________________________________________________________________________________________________

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.