[stir] quoted ppt parameter value redux

["Peterson, Jon" <[e-mail]>]

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.