Give us something to hang onto #267

Open
mnot opened this Issue Nov 16, 2016 · 11 comments

Projects

None yet

2 participants

@mnot
Contributor
mnot commented Nov 16, 2016

In working on RFC5988bis, I'm referring to this spec, and finding it's difficult to talk about the concepts, because so much has been pared back.

In particular:

  • There isn't any prose reference to the "*" form of the attribute name; it only occurs in examples. One would assume that this is the normative way to invoke this encoding, but it isn't specified.
  • A distinct name for the encoding would help; right now, the best I can do is "the encoding specified in RFC5987bis".
  • The examples of how to use this in header specifications needs to be deeper.
@reschke
Contributor
reschke commented Nov 16, 2016

Any name suggestions?

@mnot
Contributor
mnot commented Nov 16, 2016

Hmm. "i18nPE" (Internationalisation Parameter Encoding)?

@reschke
Contributor
reschke commented Nov 16, 2016

"nape"? (non-ASCII P. E.)

@mnot
Contributor
mnot commented Nov 17, 2016

Nape is an English word, a bit odd to use as a name. IPE?

@reschke
Contributor
reschke commented Nov 17, 2016

sgtm

I should use that everywhere then, including the title, right?

@mnot
Contributor
mnot commented Nov 17, 2016

Think so.

@reschke
Contributor
reschke commented Nov 17, 2016

On the other hand, given the fact that just a few weeks ago you wanted to deprecate the encoding, you are now asking for a way to make it easier to reference? Maybe "the encoding defined in RFC xxxx" or "RFC xxxx encoding" really is good enough.

@reschke
Contributor
reschke commented Nov 17, 2016 edited

There isn't any prose reference to the "*" form of the attribute name; it only occurs in examples. One would assume that this is the normative way to invoke this encoding, but it isn't specified.

Actually, this spec can't (or doesn't want to) make a normative requirement for this. The syntax of the parameter names is supposed to be under the control of the specification using them.

That said, I can try to make this clearer in the prose.

Note that it already says:

Note: This specification does not automatically assign a new interpretation to parameter names ending in an asterisk. As pointed out above, it's up to the specification for the non-extended parameter to "opt in" to the syntax defined here. That being said, some existing implementations are known to automatically switch to the use of this notation when a parameter name ends with an asterisk, thus using parameter names ending in an asterisk for something else is likely to cause interoperability problems.

@mnot
Contributor
mnot commented Nov 18, 2016

Transitional Retrograde Internationalised Parameter Encoding?

@mnot
Contributor
mnot commented Nov 18, 2016

Re OTOH -- you convinced me very effectively.

@reschke
Contributor
reschke commented Jan 7, 2017

The examples of how to use this in header specifications needs to be deeper.

The whole of Section 4 is about that. What exactly are you missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment