IETF/IANA registration of header fields

[dret]

as soon as possible, you want to make sure that you have the right text in the spec that registers the spec with IETF, to get the defined header fields into the IANA header field registry. if you need help with that, let me know.

[AloisReitbauer]

@dret thank you for offering your help. I already discussed with W3C and they seem to have a process in place for this.

[dret]

very good! just get the section done, and seek review as early as possible.

…

On Apr 30, 2018, at 10:48, Alois Reitbauer ***@***.***> wrote: @dret thank you for offering your help. I already discussed with W3C and they seem to have a process in place for this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[AloisReitbauer]

We need to decide on #119 first

[dret]

On 2018-05-02 10:52, Alois Reitbauer wrote: We need to decide on #119 <#119> first

clearly. but the registration section could be written already, with the header field name popped in as soon as it is determined. that just helps to make it easy for people to see what concepts the spec is defining.

[plehegar]

I guess this was is dependent on #197 at least.

[SergeyKanzhelev]

@AloisReitbauer do you think that CR milestone depends on this work? I'd suggest to keep it in PR and do actual registration with IETF later. Objections?

[dret]

On 2018-11-05 23:18, Sergey Kanzhelev wrote: @AloisReitbauer <https://github.com/AloisReitbauer> do you think that CR milestone depends on this work? I'd suggest to keep it in PR and do actual registration with IETF later. Objections?

it doesn't matter much whether it's in the main branch or not. there is no auto-registration magic happening. even when it's in the spec text, at some point somebody needs to send an email to IANA and trigger the actual registration (it would be good to add this to a to-do list - if there is such a thing - that gets used when the spec moves to some stable status such as CR/PR/REC). it's simply good practice to make it explicit that this spec is requesting registrations. cheers, dret.

…

-- erik wilde | mailto:[email protected] | | http://dret.net/netdret | | http://twitter.com/dret |

[SergeyKanzhelev]

@dret absolutely! I just trying to understand whether we block calling a spec CR on this or not. I'd suggest not to block on registration. But I'm not sure what was @AloisReitbauer intent here to change the milestone.

[dret]

On 2018-11-06 00:02, Sergey Kanzhelev wrote: @dret <https://github.com/dret> absolutely! I just trying to understand whether we block calling a spec CR on this or not. I'd suggest not to block on registration. But I'm not sure what was @AloisReitbauer <https://github.com/AloisReitbauer> intent here to change the milestone.

fine with not blocking, but this really should become good practice for @w3c specs. many w3c specs do not bother properly registering the concepts they are defining, which is suboptimal. i know it is not up to this specific spec or group to change this, but it would be nice to see this getting established as good practice in the w3c.

[dret]

i added the spec here: http://webconcepts.info/specs/W3C/TR/distributed-tracing

it seems like the sections defining the header fields also could use a bit better intros, making sure that people searching for the definition find a useful one right at the start. for now, i have lifted some text from the tracestate section, and the traceparent section does not have any intro text for now, so i used a snippet from someplace else.

should i raise a separate issue about the definitions being more self-contained and explanatory?

[dret]

the latest version still is a WD but still has no IANA considerations section. it really should have one.

[dret]

since the spec has now changed identity, so has its representation in web concepts: http://webconcepts.info/specs/W3C/TR/trace-context

[plehegar]

I sent a request to ietf-message-headers for provisional registration.

[plehegar]

The thread starts at
https://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00210.html

Per https://tools.ietf.org/html/bcp90#section-4.3 , I'll follow up in 2/3 weeks with IANA, unless they are comments.

[plehegar]

Sent email to IANA to request publication.

[plehegar]

IANA sent the request on to the IESG-designated expert for review.

[plehegar]

we are now listed in https://www.iana.org/assignments/message-headers .

We'll need to move to permanent status once we're at the end of CR.

[plehegar]

Permanent status requested:
https://mailarchive.ietf.org/arch/msg/ietf-message-headers/AUPU45d0Pr30TEjx-yo4hvCwYQw

[plehegar]

we don't seem to have added an IANA consideration section btw. Should be done as an appendix I guess. @SergeyKanzhelev , wdyt?

[danielkhan]

Let's start that conversation and also talk about CORS safelisting

[dyladan]

Opened a new issue for CORS since it is a separate concern #405

[plehegar]

(@plehegar to make a PR and see if the header is permanent)

[danielkhan]

@plehegar PTAL as we now are in recommendation state.

[kalyanaj]

@plehegar We discussed this issue in the WG meeting today, wanted to understand if the above requests were completed, if not will you be able to kindly help with the required follow-ups?

[plehegar]

Requested the permanent status again:
https://mailarchive.ietf.org/arch/msg/ietf-message-headers/0hmZgQ6ZdHzNzb-rj4C9LlQUGg8/

[plehegar]

Now using the new registration system: protocol-registries/http-fields#35

[plehegar]

The headers are now permanent.

[plehegar]

This issue can be closed as far as I know. We're done.

[kalyanaj]

Thanks @plehegar for the updates! Closing the issue per the above.