Subject: [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA CPM 1.0

From: Cristina Badulescu <[email-masked]>
Date: Mon, 16 Jul 2012 14:15:16 -0400

Dear Adam,

I'm acting as OMA CPM Convenor, picking up this thread from my predecesor. Pls find my answers inline below.
Regards,
Cristina

From: Rohnert, Hans (NSN - DE/Munich)
Sent: Tuesday, March 20, 2012 1:22 PM
To: 'ext Adam Roach'
Subject: RE: [RAI] Expert Review of 6 new SIP header fields defined by OMA

Dear Adam,
Thank you for reviewing the OMA CPM headers.
I act as Convenor for OMA CPM and will reply to this. It will just take a few more days.
Thanks,
Hans

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, March 19, 2012 10:27 PM
To: RAI Area
Cc: RAI Area Directors
Subject: [RAI] Expert Review of 6 new SIP header fields defined by OMA

I have been asked by the RAI area directors to review of the SIP header fields proposed by the following OMA document:

http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

I have been designated the formal expert reviewer for this request from OMA. Although this is not the formal review (which will be sent in response to a request from IANA), the contents of my review will be identical to or substantially similar to the following if the current proposal is sent to IANA. OMA is encouraged to make adjustments as suggested below before proceeding.

----------------------------------------------------------------------

The OMA proposal "CPM Conversation Functions" describes six new SIP header fields. These header fields are intended to facilitate their SIP- and MSRP-based instant messaging architecture. I will address each proposed header field individually, using the criteria described in section 4 RFC 5727.

In particular, I am analyzing for a lack of overlap with existing (either complete or in-progress) work in RAI; the absence of significant changes in SIP client behavior; and proper treatment of security-related issues.

My first comment, which is global, is that this document nearly universally uses the term "header" where "header field" is intended. While this is largely editorial, RFC3261 does have a clear definition for the term "header," and its use in this fashion is nonsensical. This does not preclude registration of the header fields.

[Cristina] CPM 1.0 is now in it's final approval process in OMA, so we will incorporate the IETF terminology correction in CPM 2.0.

----------------------------------------
Conversation-ID

Conclusion: Apparently unsuitable for registration (significant client behavior change), can be fixed with clearer semantics describing client behavior when header field is absent.
[Cristina] Conversation-ID is mandatory in CPM, so if the header field is not present then it's a typical protocol error case.

This proposed header field does not appear to directly conflict with existing or ongoing work in the RAI area. However, its presence is likely superfluous, as the SIP Call-ID of the initial message in the conversation could trivially be used for this purpose: it has the same information properties as the proposed Conversation-ID.

[Cristina] OMA CPM has the concept of "Conversation" which groups together for example chat sessions, file transfers, standalone messages, subsequent disposition notifications e.g. 'delivered' /'display' for missed messages that are delivered/read later. The Conversation content (messages, file tranfers, notifications, etc) is identified and stored all together, by the Conversation-ID which ties them all together. Call-ID  was not used since these IDs are expected to simply be copied over at B2BUA's so they will remain the same on an end to end basis (passing through SBCs).

After carefully reviewing both OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C and OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious concerns about whether this header field qualifies as "purely informational" and as "NOT significantly chang[ing] the behavior of SIP entites that support it." In particular, both documents contain normative language indicating behavior such as the following:
"[T]he CPM Participating Function... SHALL extract and locally store the following headers of the request: From header; To header; Date header, if it exists; Conversation Identity and Contribution Identity and if there is, Contribution Identity being replied to."

This text, for example, leaves the behavior undefined when a Conversation Identity header field is not present in the SIP message. Many implementations will consequently fail to process the request when no Conversation-ID header field is sent, which is the most radical behavior change possible.
[Cristina] Conversation-ID is mandatory in CPM 2.0. So if the header field is not present in the SIP message received by the CPM participating function, then it'll be a failure at protocol level and the CPM session will not be initiated. Hence CPM Participating Function will not get to record a closed CPM session, which is the execution point quoted above (i.e. to extract the headers for storing/recording purposes).

Call-Id was not used since the values of these headers should be created and used in a way unrelated to Call-Id. These ID's are expected to simply be copied over at B2BUA's so they will remain the same on an end to end basis (passing through SBCs). We wanted to avoid any cases where SBCs could alter the new headers in any way (e.g. even a blind replacement of the ['@' word]" part).

Also, the same Conversation-ID of the previous chat INVITE would have to be used in CPM scenarios where a closed chat session is revived later on by any one of the original participating UAs (i.e. re-initiating it).  As this later UA could be in a different domain, carrying the original ['@' word]" part does not serve any purpose (but can be confusing).

To be acceptable for registration under RFC 5727 guidelines, the behavior described in this document (and related documents that discuss conversation behavior) need to be revised to clarify that the absence of this header field cannot result in substantial changes in client behavior, such as failure to process the message.

I will observe that the use of the initial Call-ID of the conversation to identify the entire conversation (as suggested above) completely eliminates these concerns, as RFC3261 mandates the presence of Call-ID in every SIP message.

Since the header field is not presently suitable for registration, I will not perform a security analysis for Conversation-ID.

----------------------------------------
Contribution-ID

Conclusion: Apparently unsuitable for registration (significant client behavior change), can be fixed with clearer semantics describing client behavior when header field is absent.

This proposed header field does not appear to directly conflict with existing or ongoing work in the RAI area. However, its presence is likely superfluous, as the SIP Call-ID of the message could trivially be used for this purpose: it has the same information properties as the proposed Contribution-ID.

I have concerns congruent with those for Conversation-ID, in that behavior in the absence of the Contribution-ID is not well defined, and therefore will likely lead to interoperability failures (which constitute significant changes in client behavior). For example:
"[T]he CPM Participating Function... SHALL, in case of a Pager Mode CPM Standalone Message, store the following information: ... Contribution-ID; InReplyTo-Contribution-ID (if present)."
This comment may be addressed in the same way as for Conversation-ID.
[Cristina] Similar answer as for Conversation-ID answer applies to the Contribution-ID for Call-ID reuse and mandatory nature for all CPM SIP methods.

I will again observe that the use of Call-ID for this function eliminates all interoperability concerns.

Since the header field is not presently suitable for registration, I will not perform a security analysis for Conversation-ID.

----------------------------------------
InReplyTo-Contribution-ID

Conclusion: Suitable for registration, once security is addressed

This proposed header field does not appear to directly conflict with existing or ongoing work in the RAI area, and client behavior in its absence appears to be well defined (communications proceed as expected).

Note that the use of Call-ID for identification of contributions would allow the use of the already-defined SIP "In-Reply-To." Doing so eliminates the need for the definition and registration of a new header field.
[Cristina] This header field has an equivalent syntax to the Contribution-ID, used to correlate messages & disposition notifications within one specific Conversation.

This header field needs to include a discussion of security: if new users are included into an ongoing conversation, the presence of this header field can be used to deduce that they did not receive previously sent messages on the topic. The very existence of these messages may constitute sensitive information that the sender did not intend to reveal. In particular, senders should have the ability to suppress this header field to avoid leaking such information.

----------------------------------------
Session-Replaces

Conclusion: Unsuitable for registration (overlap with RAI work)

This proposed header field directly conflicts with the "Replaces" header field defined by RFC 3891, which constitutes existing work within the IETF RAI area. It is not suitable for registration.

I do not believe that the described mechanism can be altered to overcome this conflict. OMA should instead employ the mechanism defined by RFC 3891.
[Cristina] The main problem encountered with "Replaces" was that SBGs along the way (or B2BUA) alter the Call-ID value contained in this header field. This beats the purpose in the service logic in CPM, as we absolutely needed to identify the Contribution-ID of the original session being replaced. So the Session-Replaces contains the original Contribution-ID value (not Call-ID).

----------------------------------------
Message-Expires

Conclusion: Suitable for registration, once security is addressed

This header field avoids overlap with existing RAI work by careful scoping its use to the INVITE method. Client behavior in its absence appears to be well defined, and does not constitute a significant change in SIP client behavior.

This header field needs better discussion of its security properties. In particular, implementors need to ensure user expectations around what happens when a message expires are properly dealt with. For example: if a user sends a message which he expects to expire in one hour, there is no guarantee that the recipient will be unable to retrieve the message after that time. Further, the recipient device may not preclude the storage of received messages well past their expiration.

[Cristina] it was left as an implementor's choice how to deal with this case, hence not intended for the standard specification.

----------------------------------------
Message-UID

Conclusion: Suitable for registration

This header field does not appear to overlap with any existing RAI work. Client behavior in its absence appears to be well defined, and does not constitute a significant change in SIP client behavior.

The presence and use of this header field does not appear to introduce any security issues.

/a

---

From: Michael Hammer <[email-masked]>
Date: Mon, 16 Jul 2012 19:59:38 +0000

Might I ask how this work overlaps or aligns with the efforts of the
recently created INSIPID and STRAW WGs?

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cristina Badulescu
Sent: Monday, July 16, 2012 2:15 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA
CPM 1.0

Dear Adam,

I'm acting as OMA CPM Convenor, picking up this thread from my predecesor.
Pls find my answers inline below. 

Regards,
Cristina

Dear Adam,

I act as Convenor for OMA CPM and will reply to this. It will just take a
few more days.

Thanks,

Hans

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Adam Roach
Sent: Monday, March 19, 2012 10:27 PM
To: RAI Area
Cc: RAI Area Directors
Subject: [RAI] Expert Review of 6 new SIP header fields defined by OMA

I have been asked by the RAI area directors to review of the SIP header
fields proposed by the following OMA document:

http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20
101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

I have been designated the formal expert reviewer for this request from OMA.
Although this is not the formal review (which will be sent in response to a
request from IANA), the contents of my review will be identical to or
substantially similar to the following if the current proposal is sent to
IANA. OMA is encouraged to make adjustments as suggested below before
proceeding.

The OMA proposal "CPM Conversation Functions" describes six new SIP header
fields. These header fields are intended to facilitate their SIP- and
MSRP-based instant messaging architecture. I will address each proposed
header field individually, using the criteria described in section 4 RFC
5727.

In particular, I am analyzing for a lack of overlap with existing (either
complete or in-progress) work in RAI; the absence of significant changes in
SIP client behavior; and proper treatment of security-related issues.

My first comment, which is global, is that this document nearly universally
uses the term "header" where "header field" is intended. While this is
largely editorial, RFC3261 does have a clear definition for the term
"header," and its use in this fashion is nonsensical. This does not preclude
registration of the header fields.

[Cristina] CPM 1.0 is now in it's final approval process in OMA, so we will
incorporate the IETF terminology correction in CPM 2.0.

Conclusion: Apparently unsuitable for registration (significant client
behavior change), can be fixed with clearer semantics describing client
behavior when header field is absent. 

[Cristina] Conversation-ID is mandatory in CPM, so if the header field is
not present then it's a typical protocol error case.

This proposed header field does not appear to directly conflict with
existing or ongoing work in the RAI area. However, its presence is likely
superfluous, as the SIP Call-ID of the initial message in the conversation
could trivially be used for this purpose: it has the same information
properties as the proposed Conversation-ID.

[Cristina] OMA CPM has the concept of "Conversation" which groups together
for example chat sessions, file transfers, standalone messages, subsequent
disposition notifications e.g. 'delivered' /'display' for missed messages
that are delivered/read later. The Conversation content (messages, file
tranfers, notifications, etc) is identified and stored all together, by the
Conversation-ID which ties them all together. Call-ID  was not used since
these IDs are expected to simply be copied over at B2BUA's so they will
remain the same on an end to end basis (passing through SBCs).

After carefully reviewing both OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C and
OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious concerns about
whether this header field qualifies as "purely informational" and as "NOT
significantly chang[ing] the behavior of SIP entites that support it." In
particular, both documents contain normative language indicating behavior
such as the following:

"[T]he CPM Participating Function... SHALL extract and locally store the
following headers of the request: From header; To header; Date header, if it
exists; Conversation Identity and Contribution Identity and if there is,
Contribution Identity being replied to."

This text, for example, leaves the behavior undefined when a Conversation
Identity header field is not present in the SIP message. Many
implementations will consequently fail to process the request when no
Conversation-ID header field is sent, which is the most radical behavior
change possible.

[Cristina] Conversation-ID is mandatory in CPM 2.0. So if the header field
is not present in the SIP message received by the CPM participating
function, then it'll be a failure at protocol level and the CPM session will
not be initiated. Hence CPM Participating Function will not get to record a
closed CPM session, which is the execution point quoted above (i.e. to
extract the headers for storing/recording purposes).

Call-Id was not used since the values of these headers should be created and
used in a way unrelated to Call-Id. These ID's are expected to simply be
copied over at B2BUA's so they will remain the same on an end to end basis
(passing through SBCs). We wanted to avoid any cases where SBCs could alter
the new headers in any way (e.g. even a blind replacement of the ['@' word]"
part). 

Also, the same Conversation-ID of the previous chat INVITE would have to be
used in CPM scenarios where a closed chat session is revived later on by any
one of the original participating UAs (i.e. re-initiating it).  As this
later UA could be in a different domain, carrying the original ['@' word]"
part does not serve any purpose (but can be confusing).

To be acceptable for registration under RFC 5727 guidelines, the behavior
described in this document (and related documents that discuss conversation
behavior) need to be revised to clarify that the absence of this header
field cannot result in substantial changes in client behavior, such as
failure to process the message.

I will observe that the use of the initial Call-ID of the conversation to
identify the entire conversation (as suggested above) completely eliminates
these concerns, as RFC3261 mandates the presence of Call-ID in every SIP
message.

Since the header field is not presently suitable for registration, I will
not perform a security analysis for Conversation-ID.

Conclusion: Apparently unsuitable for registration (significant client
behavior change), can be fixed with clearer semantics describing client
behavior when header field is absent.

This proposed header field does not appear to directly conflict with
existing or ongoing work in the RAI area. However, its presence is likely
superfluous, as the SIP Call-ID of the message could trivially be used for
this purpose: it has the same information properties as the proposed
Contribution-ID.

I have concerns congruent with those for Conversation-ID, in that behavior
in the absence of the Contribution-ID is not well defined, and therefore
will likely lead to interoperability failures (which constitute significant
changes in client behavior). For example:

"[T]he CPM Participating Function... SHALL, in case of a Pager Mode CPM
Standalone Message, store the following information: ... Contribution-ID;
InReplyTo-Contribution-ID (if present)."

[Cristina] Similar answer as for Conversation-ID answer applies to the
Contribution-ID for Call-ID reuse and mandatory nature for all CPM SIP
methods.  

I will again observe that the use of Call-ID for this function eliminates
all interoperability concerns.

Since the header field is not presently suitable for registration, I will
not perform a security analysis for Conversation-ID.

This proposed header field does not appear to directly conflict with
existing or ongoing work in the RAI area, and client behavior in its absence
appears to be well defined (communications proceed as expected).

Note that the use of Call-ID for identification of contributions would allow
the use of the already-defined SIP "In-Reply-To." Doing so eliminates the
need for the definition and registration of a new header field.

[Cristina] This header field has an equivalent syntax to the
Contribution-ID, used to correlate messages & disposition notifications
within one specific Conversation.

This header field needs to include a discussion of security: if new users
are included into an ongoing conversation, the presence of this header field
can be used to deduce that they did not receive previously sent messages on
the topic. The very existence of these messages may constitute sensitive
information that the sender did not intend to reveal. In particular, senders
should have the ability to suppress this header field to avoid leaking such
information.

This proposed header field directly conflicts with the "Replaces" header
field defined by RFC 3891, which constitutes existing work within the IETF
RAI area. It is not suitable for registration.

I do not believe that the described mechanism can be altered to overcome
this conflict. OMA should instead employ the mechanism defined by RFC 3891.

[Cristina] The main problem encountered with "Replaces" was that SBGs along
the way (or B2BUA) alter the Call-ID value contained in this header field.
This beats the purpose in the service logic in CPM, as we absolutely needed
to identify the Contribution-ID of the original session being replaced. So
the Session-Replaces contains the original Contribution-ID value (not
Call-ID).

This header field avoids overlap with existing RAI work by careful scoping
its use to the INVITE method. Client behavior in its absence appears to be
well defined, and does not constitute a significant change in SIP client
behavior.

This header field needs better discussion of its security properties. In
particular, implementors need to ensure user expectations around what
happens when a message expires are properly dealt with. For example: if a
user sends a message which he expects to expire in one hour, there is no
guarantee that the recipient will be unable to retrieve the message after
that time. Further, the recipient device may not preclude the storage of
received messages well past their expiration.

[Cristina] it was left as an implementor's choice how to deal with this
case, hence not intended for the standard specification. 

This header field does not appear to overlap with any existing RAI work.
Client behavior in its absence appears to be well defined, and does not
constitute a significant change in SIP client behavior.

The presence and use of this header field does not appear to introduce any
security issues.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Jul 2012 16:52:38 -0500

Cristina:

Thank you for your clarifying comments. It is now clear that RFC 5727 
expert review processes are unlikely to apply to the CPM header fields 
at all. If your replies are accurate, then all of the CPM 1.0 header 
fields (with the possible exception of Message-UID) must be processed 
through the normal IETF Standards Track process, which requires the 
mechanism to be developed in an IETF working group. If OMA's official 
position is that communication fails in the absence of these header 
fields, then I suggest that you quickly bring a proposed set of 
requirements to the SIMPLE working group so that the IETF work can begin 
in earnest.

On the other hand, if you would prefer to register header fields under 
RFC 5727 section 4 procedures -- without the need to publish them via 
the IETF Standards Track process -- then you must make them conform to 
the criteria in RFC 5727 section 4. In my original message, I indicated 
how to do this for every proposed header field (save Session-Replaces, 
which I discuss below). Re-asserting as immutable facts the very 
properties that violate RFC 5727 section 4 criteria is not sufficient to 
bring them out of violation; actual changes are required.

I have specific responses inline, below.

On 7/16/12 1:15 PM, Cristina Badulescu wrote:
> behavior change), can be fixed with clearer semantics describing 
> client behavior when header field is absent.
>
> [Cristina] Conversation-ID is mandatory in CPM, so if the header field 
> is not present then it's a typical protocol error case.
>
> [Cristina]Conversation-ID is mandatory in CPM 2.0. So if the header 
> field is not present in the SIP message received by the CPM 
> participating function, then it'll be a failure at protocol level and 
> the CPM session will not be initiated.

If the presence, absence, or value of the header field can cause the 
communications to fail, then it is not subject to registration under RFC 
5727 section 4 procedures (numbered criteria 1, in particular). You must 
instead bring the mechanism to the IETF for refinement and eventual 
publication as a standards-track RFC.

To be clear: you claim that absence of the header field causes the 
communication to fail. I can imagine no more radical behavioral change 
than the conversion of success into failure.

Based on your answer above, Conversation-ID must not be registered under 
RFC 5727 section 4 procedures.

> Contribution-ID for Call-ID reuse and mandatory nature for all CPM SIP 

Based on this answer, Contribution-ID also must not be registered under 
RFC 5727 section 4 procedures. See my response above.

> This proposed header field directly conflicts with the "Replaces" 
> header field defined by RFC 3891, which constitutes existing work 
> within the IETF RAI area. It is not suitable for registration.
>
> I do not believe that the described mechanism can be altered to 
> overcome this conflict. OMA should instead employ the mechanism 
> defined by RFC 3891.
>
> [Cristina] The main problem encountered with "Replaces" was that SBGs 
> along the way (or B2BUA) alter the Call-ID value contained in this 
> header field. This beats the purpose in the service logic in CPM, as 
> we absolutely needed to identify the Contribution-ID of the original 
> session being replaced. So the Session-Replaces contains the original 
> Contribution-ID value (not Call-ID).
>

If the SBCs are altering the Call-IDs, then it is incumbent on those 
SBCs to make corresponding adjustments to the "Replaces" header field. 
Re-inventing the SIP protocol in a parallel set of header fields as a 
vain attempt to stay ahead of SBCs' ability to disrupt services through 
data alteration engages in a cat-and-mouse game that cannot be won. Any 
rationale that can be applied to claim that such SBCs will leave 
Contribution-IDs unmolested can be applied equally to Call-IDs.

The proposed header field remains in competition with an existing 
standards-track mechanisms, in violation of the RFC 5727 admonishment 
that experts are to "review documents for overlap with existing 
chartered work in the RAI Area." It cannot be registered as long as it 
remains in competition with RFC 3891.

To suggest a concrete path forward: I will first re-iterate that this 
kind of operation must be performed using the mechanism defined in RFC 
3891. If SBC survivability remains an issue, I would suggest that you 
bring work to the IETF that extends RFC 3891 to optionally use the 
end-to-end identifiers presently undergoing specification in the INSIPID 
working group. I would begin by discussing such a need on the DISPATCH 
working group mailing list: https://www.ietf.org/mailman/listinfo/dispatch

In my opinion, it would be easier for OMA operators to clarify to the 
vendors selling them SBCs that a criteria for selection of such SBCs 
includes Replaces header field Call-ID fix-up for Call-ID changes 
perpetrated by the SBCs.

> This header field avoids overlap with existing RAI work by careful 
> scoping its use to the INVITE method. Client behavior in its absence 
> appears to be well defined, and does not constitute a significant 
> change in SIP client behavior.
>
> This header field needs better discussion of its security properties. 
> In particular, implementors need to ensure user expectations around 
> what happens when a message expires are properly dealt with. For 
> example: if a user sends a message which he expects to expire in one 
> hour, there is no guarantee that the recipient will be unable to 
> retrieve the message after that time. Further, the recipient device 
> may not preclude the storage of received messages well past their 
> expiration.
>
>
> [Cristina] it was left as an implementor's choice how to deal with 
> this case, hence not intended for the standard specification.
>

I'm not suggesting that you add any specification. I'm asking that you 
add warning that these specific security issues exist and guidance about 
how they might be handled. Without security guidance, the header field 
does not satisfy the second numbered criteria listed in section 4 of RFC 
5727. Unless such considerations are added, then the field cannot be 
registered.

/a

---

From: Cristina Badulescu <[email-masked]>
Date: Thu, 19 Jul 2012 10:11:47 -0400

dear Adam,

Thank you for the comprehensive analysis and feedback, I understand the RFC5727 (esp. sect. 4) better at this point.
I will take the IETF RAI conclusion back into OMA for consideration and assessment of the next steps.

Best regards,
/Cristina

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: July-16-12 5:53 PM
To: Cristina Badulescu
Cc: [email-masked]; [email-masked]
Subject: Re: FW: [RAI] Expert Review of 6 new SIP header fields defined by OMA CPM 1.0

Cristina:

Thank you for your clarifying comments. It is now clear that RFC 5727 expert review processes are unlikely to apply to the CPM header fields at all. If your replies are accurate, then all of the CPM 1.0 header fields (with the possible exception of Message-UID) must be processed through the normal IETF Standards Track process, which requires the mechanism to be developed in an IETF working group. If OMA's official position is that communication fails in the absence of these header fields, then I suggest that you quickly bring a proposed set of requirements to the SIMPLE working group so that the IETF work can begin in earnest.

On the other hand, if you would prefer to register header fields under RFC 5727 section 4 procedures -- without the need to publish them via the IETF Standards Track process -- then you must make them conform to the criteria in RFC 5727 section 4. In my original message, I indicated how to do this for every proposed header field (save Session-Replaces, which I discuss below). Re-asserting as immutable facts the very properties that violate RFC 5727 section 4 criteria is not sufficient to bring them out of violation; actual changes are required.

Conclusion: Apparently unsuitable for registration (significant client behavior change), can be fixed with clearer semantics describing client behavior when header field is absent.
[Cristina] Conversation-ID is mandatory in CPM, so if the header field is not present then it's a typical protocol error case.
[Cristina] Conversation-ID is mandatory in CPM 2.0. So if the header field is not present in the SIP message received by the CPM participating function, then it'll be a failure at protocol level and the CPM session will not be initiated.

If the presence, absence, or value of the header field can cause the communications to fail, then it is not subject to registration under RFC 5727 section 4 procedures (numbered criteria 1, in particular). You must instead bring the mechanism to the IETF for refinement and eventual publication as a standards-track RFC.

To be clear: you claim that absence of the header field causes the communication to fail. I can imagine no more radical behavioral change than the conversion of success into failure.

Based on your answer above, Conversation-ID must not be registered under RFC 5727 section 4 procedures.

Based on this answer, Contribution-ID also must not be registered under RFC 5727 section 4 procedures. See my response above.

If the SBCs are altering the Call-IDs, then it is incumbent on those SBCs to make corresponding adjustments to the "Replaces" header field. Re-inventing the SIP protocol in a parallel set of header fields as a vain attempt to stay ahead of SBCs' ability to disrupt services through data alteration engages in a cat-and-mouse game that cannot be won. Any rationale that can be applied to claim that such SBCs will leave Contribution-IDs unmolested can be applied equally to Call-IDs.

The proposed header field remains in competition with an existing standards-track mechanisms, in violation of the RFC 5727 admonishment that experts are to "review documents for overlap with existing chartered work in the RAI Area." It cannot be registered as long as it remains in competition with RFC 3891.

To suggest a concrete path forward: I will first re-iterate that this kind of operation must be performed using the mechanism defined in RFC 3891. If SBC survivability remains an issue, I would suggest that you bring work to the IETF that extends RFC 3891 to optionally use the end-to-end identifiers presently undergoing specification in the INSIPID working group. I would begin by discussing such a need on the DISPATCH working group mailing list: https://www.ietf.org/mailman/listinfo/dispatch

In my opinion, it would be easier for OMA operators to clarify to the vendors selling them SBCs that a criteria for selection of such SBCs includes Replaces header field Call-ID fix-up for Call-ID changes perpetrated by the SBCs.

I'm not suggesting that you add any specification. I'm asking that you add warning that these specific security issues exist and guidance about how they might be handled. Without security guidance, the header field does not satisfy the second numbered criteria listed in section 4 of RFC 5727. Unless such considerations are added, then the field cannot be registered.

/a