Re: [stir] quoted ppt parameter value redux

I also agree that we should stick to that decision.

-Subir

On Thu, Oct 3, 2019 at 4:20 PM Chris Wendt <chris-ietf@chriswendt.net>
wrote:

> 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 <jon.peterson@team.neustar>
> wrote:
> >
> >
> > 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.
> >
> > _______________________________________________
> > stir mailing list
> > stir@ietf.org
> > https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>