-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IETF/IANA registration of header fields #120
Comments
@dret thank you for offering your help. I already discussed with W3C and they seem to have a process in place for this. |
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.
|
We need to decide on #119 first |
I guess this was is dependent on #197 at least. |
@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? |
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:erik.wilde@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |
|
@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. |
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.
|
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 should i raise a separate issue about the definitions being more self-contained and explanatory? |
the latest version still is a WD but still has no IANA considerations section. it really should have one. |
since the spec has now changed identity, so has its representation in web concepts: http://webconcepts.info/specs/W3C/TR/trace-context |
I sent a request to ietf-message-headers for provisional registration. |
The thread starts at Per https://tools.ietf.org/html/bcp90#section-4.3 , I'll follow up in 2/3 weeks with IANA, unless they are comments. |
Sent email to IANA to request publication. |
IANA sent the request on to the IESG-designated expert for review. |
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. |
Permanent status requested: |
we don't seem to have added an IANA consideration section btw. Should be done as an appendix I guess. @SergeyKanzhelev , wdyt? |
Let's start that conversation and also talk about CORS safelisting |
Opened a new issue for CORS since it is a separate concern #405 |
(@plehegar to make a PR and see if the header is permanent) |
@plehegar PTAL as we now are in recommendation state. |
@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? |
Requested the permanent status again: |
Now using the new registration system: protocol-registries/http-fields#35 |
The headers are now permanent. |
This issue can be closed as far as I know. We're done. |
Thanks @plehegar for the updates! Closing the issue per the above. |
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.
The text was updated successfully, but these errors were encountered: