Subject: [stir] quoted ppt parameter value redux

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Oct 2019 17:27:08 +0000

RFC8224 section 4.1 gives the following guidance about the syntax for PASSporT Types:

      Fourth, if a PASSporT extension is in use, then the optional JSON
      key "ppt" MUST be present and have a value equivalent to the
      quoted value of the "ppt" parameter of the Identity header field.

Does that imply that the values of the "ppt" parameter in the Identity header field are quoted? If so, that seems to create a conflict with the ABNF for the Identity header field, which gives "token" as the type for "ppt" parameter values.  Back in IETF 101, as we were pushing along the first PASSporT types as extensions to STIR, "div" and "rph", we had a discussion about whether the values of the "ppt" parameter of the Identity header should be quoted or unquoted. As we said at the time, it isn't really important whether ppt parameter values are quoted or not from a design perspective, but It is important that we all just agree on it one way or another. The outcome of that discussion was reflected in the minutes as:

   ISSUE: Should ppt values be quoted or not?
   OUTCOME: Quoting is mandatory.

Based on that outcome, we baked quoted ppts into the resulting docs (see RFC8443 4.1 for an example with ppt="rph" rather than ppt=rph). However, as STIR implementation ramps up, we are hearing a number of reports of AS's using unquoted ppt parameter values, and it sounds like many VS implementations are resigned to accepting both - but that some implementations are only accepting unquoted.

We have the opportunity to errata RFC8224 to set this matter straight, but it seems the implementation community still doesn't agree on what should count as straight. Unquoted saves two octets, but let's be honest, saving two octets of a STIR Identity header field value, especially one with a PASSporT extension, is not going to let anyone fall back to UDP. Quoted conforms with what's in RFCs we've already shipped, and ones in the pipeline. I hate to re-open a discussion we had already, but it does seem to be necessary. If we’re going to errata this, should the fix conform to the IETF 101 consensus call ("quoting is mandatory") or not?

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Thu, 3 Oct 2019 16:19:57 -0400

Yes, i think we should stick with that decision, if other parameters are quoted, it only makes sense ppt should be as well.

Let’s do an errata on this.

-Chris

> On Oct 3, 2019, at 1:27 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Subir Das <[email-masked]>
Date: Thu, 3 Oct 2019 17:08:44 -0400

I also agree that we should stick to that decision.

-Subir

On Thu, Oct 3, 2019 at 4:20 PM Chris Wendt <[email-masked]>
wrote:

> Yes, i think we should stick with that decision, if other parameters are
> quoted, it only makes sense ppt should be as well.
>
> > Does that imply that the values of the "ppt" parameter in the Identity
> header field are quoted? If so, that seems to create a conflict with the
> ABNF for the Identity header field, which gives "token" as the type for
> "ppt" parameter values.  Back in IETF 101, as we were pushing along the
> first PASSporT types as extensions to STIR, "div" and "rph", we had a
> discussion about whether the values of the "ppt" parameter of the Identity
> header should be quoted or unquoted. As we said at the time, it isn't
> really important whether ppt parameter values are quoted or not from a
> design perspective, but It is important that we all just agree on it one
> way or another. The outcome of that discussion was reflected in the minutes
> as:
> >
> > Based on that outcome, we baked quoted ppts into the resulting docs (see
> RFC8443 4.1 for an example with ppt="rph" rather than ppt=rph). However, as
> STIR implementation ramps up, we are hearing a number of reports of AS's
> using unquoted ppt parameter values, and it sounds like many VS
> implementations are resigned to accepting both - but that some
> implementations are only accepting unquoted.
> >
> > We have the opportunity to errata RFC8224 to set this matter straight,
> but it seems the implementation community still doesn't agree on what
> should count as straight. Unquoted saves two octets, but let's be honest,
> saving two octets of a STIR Identity header field value, especially one
> with a PASSporT extension, is not going to let anyone fall back to UDP.
> Quoted conforms with what's in RFCs we've already shipped, and ones in the
> pipeline. I hate to re-open a discussion we had already, but it does seem
> to be necessary. If we’re going to errata this, should the fix conform to
> the IETF 101 consensus call ("quoting is mandatory") or not?
> >
> > Jon Peterson
> > Neustar, Inc.
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Oct 2019 16:39:37 -0400

I suggest some “backward compatibility awareness” in this decision:

i- Current RFC8224 Identity header syntax allows both quoted/unquoted values for ppt as it is defined as a “token”.
ii- Current RFC8224 4.1 seems to imply that Identity header ppt value is expected to be unquoted as it asks to quote the ppt parameter value when construction the ppt JSON key.

Now, we want to enforce the opposite. This may cause issues with existing equipment which is implemented according to i-/ii-. Some would be lenient, some would expect unquoted and some maybe would expect quoted. I suggest that errata provides clarification that:

 *   Both forms are valid
 *   Quoting of ppt JSON key should happen only if the ppt parameter value is not quoted

It would be better to enforce a single format from day one but alas… For now, I think enforcing leniency is the least worst of possible options.

Thanks,
Tolga

From: stir <[email-masked]> On Behalf Of Subir Das
Sent: Thursday, October 3, 2019 5:09 PM
To: Chris Wendt <[email-masked]>
Cc: Peterson, Jon <[email-masked]>; [email-masked]
Subject: Re: [stir] quoted ppt parameter value redux

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

-Subir

On Thu, Oct 3, 2019 at 4:20 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
Yes, i think we should stick with that decision, if other parameters are quoted, it only makes sense ppt should be as well.

-Chris

> On Oct 3, 2019, at 1:27 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------