ci: merge main to release

docker-compose.yml

@@ -116,7 +116,7 @@ services:
             - "minio-data:/data"
 
     blobdb:
-        image: postgres:16
+        image: postgres:17
         restart: unless-stopped
         environment:
             POSTGRES_DB: blob

ietf/meeting/views.py

@@ -329,7 +329,7 @@ def materials_document(request, document, num=None, ext=None):
     old_proceedings_format = meeting.number.isdigit() and int(meeting.number) <= 96
     if settings.MEETING_MATERIALS_SERVE_LOCALLY or old_proceedings_format:
         bytes = filename.read_bytes()
-        mtype, chset = get_mime_type(bytes)
+        mtype, chset = get_mime_type(bytes)  # chset does not consider entire file!
         content_type = "%s; charset=%s" % (mtype, chset)
 
         if filename.suffix == ".md" and mtype == "text/plain":
@@ -339,15 +339,24 @@ def materials_document(request, document, num=None, ext=None):
                     content_type = content_type.replace("plain", "markdown", 1)
                     break
                 elif atype[0] == "text/html":
+                    # Render markdown, allowing that charset may be inaccurate.
+                    try:
+                        md_src = bytes.decode(
+                            "utf-8" if chset in ["ascii", "us-ascii"] else chset
+                        )
+                    except UnicodeDecodeError:
+                        # latin-1, aka iso8859-1, accepts all 8-bit code points
+                        md_src = bytes.decode("latin-1")
+                    content = markdown.markdown(md_src)  # a string
                     bytes = render_to_string(
                         "minimal.html",
                         {
-                            "content": markdown.markdown(bytes.decode(encoding=chset)),
+                            "content": content,
                             "title": filename.name,
                             "static_ietf_org": settings.STATIC_IETF_ORG,
                         },
-                    )
-                    content_type = content_type.replace("plain", "html", 1)
+                    ).encode("utf-8")
+                    content_type = "text/html; charset=utf-8"
                     break
                 elif atype[0] == "text/plain":
                     break
@@ -442,6 +451,7 @@ def _default_content_type(blob_name: str):
     else:
         # found the blob - return it
         assert isinstance(blob, BlobFile)
+        log(f"Materials blob: directly returning {bucket}:{name}")
         return FileResponse(
             blob,
             filename=name,
@@ -464,17 +474,20 @@ def _default_content_type(blob_name: str):
         if doc.type_id != bucket:
             raise Document.DoesNotExist
     except Document.DoesNotExist:
+        log(f"Materials blob: no doc for {bucket}:{name}")
         return HttpResponseNotFound(
             f"Document corresponding to {bucket}:{name} not found."
         )
     else:
         # create all missing blobs for the doc while we're at it
+        log(f"Materials blob: storing blobs for {doc.name}-{doc.rev}")
         store_blobs_for_one_material_doc(doc)
 
     # If we can make the blob at all, it now exists, so return it or a 404
     try:
         blob = storage.open(name, "rb")
     except FileNotFoundError:
+        log(f"Materials blob: no blob for {bucket}:{name}")
         return HttpResponseNotFound(f"Object {bucket}:{name} not found.")
     else:
         # found the blob - return it

ietf/name/fixtures/names.json

@@ -650,7 +650,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.1\" target=\"_blank\">4.2.1. Call for Adoption by WG Issued</a>\r\n\r\n The \"Call for Adoption by WG Issued\" state should be used to indicate when an I-D is being considered for adoption by an IETF WG. An I-D that is in this state is actively being considered for adoption and has not yet achieved consensus, preference, or selection in the WG.\r\n\r\n This state may be used to describe an I-D that someone has asked a WG to consider for adoption, if the WG Chair has agreed with the request. This state may also be used to identify an I-D that a WG Chair asked an author to write specifically for consideration as a candidate WG item [WGDTSPEC], and/or an I-D that is listed as a 'candidate draft' in the WG's charter.\r\n\r\n Under normal conditions, it should not be possible for an I-D to be in the \"Call for Adoption by WG Issued\" state in more than one working group at the same time. This said, it is not uncommon for authors to \"shop\" their I-Ds to more than one WG at a time, with the hope of getting their documents adopted somewhere.\r\n\r\n After this state is implemented in the Datatracker, an I-D that is in the \"Call for Adoption by WG Issued\" state will not be able to be \"shopped\" to any other WG without the consent of the WG Chairs and the responsible ADs impacted by the shopping.\r\n\r\n Note that Figure 1 includes an arc leading from this state to outside of the WG state machine. This illustrates that some I-Ds that are considered do not get adopted as WG drafts. An I-D that is not adopted as a WG draft will transition out of the WG state machine and revert back to having no stream-specific state; however, the status change history log of the I-D will record that the I-D was previously in the \"Call for Adoption by WG Issued\" state.",
+      "desc": "A call for adoption of the individual submission document has been issued by the Working Group (WG) chairs.  This call is still running but the WG has not yet reached consensus for adoption.",
       "name": "Call For Adoption By WG Issued",
       "next_states": [
         36,
@@ -666,7 +666,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.2\" target=\"_blank\">4.2.2. Adopted by a WG</a>\r\n\r\n The \"Adopted by a WG\" state describes an individual submission I-D that an IETF WG has agreed to adopt as one of its WG drafts.\r\n\r\n WG Chairs who use this state will be able to clearly indicate when their WGs adopt individual submission I-Ds. This will facilitate the Datatracker's ability to correctly capture \"Replaces\" information for WG drafts and correct \"Replaced by\" information for individual submission I-Ds that have been replaced by WG drafts.\r\n\r\n This state is needed because the Datatracker uses the filename of an I-D as a key to search its database for status information about the I-D, and because the filename of a WG I-D is supposed to be different from the filename of an individual submission I-D. The filename of an individual submission I-D will typically be formatted as 'draft-author-wgname-topic-nn'.\r\n\r\n The filename of a WG document is supposed to be formatted as 'draft- ietf-wgname-topic-nn'.\r\n\r\n An individual I-D that is adopted by a WG may take weeks or months to be resubmitted by the author as a new (version-00) WG draft. If the \"Adopted by a WG\" state is not used, the Datatracker has no way to determine that an I-D has been adopted until a new version of the I-D is submitted to the WG by the author and until the I-D is approved for posting by a WG Chair.",
+      "desc": "The individual submission document has been adopted by the Working Group (WG), but a WG document replacing this document with the typical naming convention of 'draft- ietf-wgname-topic-nn' has not yet been submitted.",
       "name": "Adopted by a WG",
       "next_states": [
         38
@@ -681,7 +681,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.3\" target=\"_blank\">4.2.3. Adopted for WG Info Only</a>\r\n\r\n The \"Adopted for WG Info Only\" state describes a document that contains useful information for the WG that adopted it, but the document is not intended to be published as an RFC. The WG will not actively develop the contents of the I-D or progress it for publication as an RFC. The only purpose of the I-D is to provide information for internal use by the WG.",
+      "desc": "The document is adopted by the Working Group (WG) for its internal use.  The WG has decided that it will not pursue publication of it as an RFC.",
       "name": "Adopted for WG Info Only",
       "next_states": [],
       "order": 3,
@@ -694,7 +694,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.4\" target=\"_blank\">4.2.4. WG Document</a>\r\n\r\n The \"WG Document\" state describes an I-D that has been adopted by an IETF WG and is being actively developed.\r\n\r\n A WG Chair may transition an I-D into the \"WG Document\" state at any time as long as the I-D is not being considered or developed in any other WG.\r\n\r\n Alternatively, WG Chairs may rely upon new functionality to be added to the Datatracker to automatically move version-00 drafts into the \"WG Document\" state as described in Section 4.1.\r\n\r\n Under normal conditions, it should not be possible for an I-D to be in the \"WG Document\" state in more than one WG at a time. This said, I-Ds may be transferred from one WG to another with the consent of the WG Chairs and the responsible ADs.",
+      "desc": "The document has been adopted by the Working Group (WG) and is under development.  A document can only be adopted by one WG at a time.  However, a document may be transferred between WGs.",
       "name": "WG Document",
       "next_states": [
         39,
@@ -712,7 +712,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.5\" target=\"_blank\">4.2.5. Parked WG Document</a>\r\n\r\n A \"Parked WG Document\" is an I-D that has lost its author or editor, is waiting for another document to be written or for a review to be completed, or cannot be progressed by the working group for some other reason.\r\n\r\n Some of the annotation tags described in Section 4.3 may be used in conjunction with this state to indicate why an I-D has been parked, and/or what may need to happen for the I-D to be un-parked.\r\n\r\n Parking a WG draft will not prevent it from expiring; however, this state can be used to indicate why the I-D has stopped progressing in the WG.\r\n\r\n A \"Parked WG Document\" that is not expired may be transferred from one WG to another with the consent of the WG Chairs and the responsible ADs.",
+      "desc": "The Working Group (WG) document is in a temporary state where it will not be actively developed.  The reason for the pause is explained via a datatracker comments section.",
       "name": "Parked WG Document",
       "next_states": [
         38
@@ -727,7 +727,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.6\" target=\"_blank\">4.2.6. Dead WG Document</a>\r\n\r\n A \"Dead WG Document\" is an I-D that has been abandoned. Note that 'Dead' is not always a final state for a WG I-D. If consensus is subsequently achieved, a \"Dead WG Document\" may be resurrected. A \"Dead WG Document\" that is not resurrected will eventually expire.\r\n\r\n Note that an I-D that is declared to be \"Dead\" in one WG and that is not expired may be transferred to a non-dead state in another WG with the consent of the WG Chairs and the responsible ADs.",
+      "desc": "The Working Group (WG) document has been abandoned by the WG.  No further development is planned in this WG.  A decision to resume work on this document and move it out of this state is possible.",
       "name": "Dead WG Document",
       "next_states": [
         38
@@ -742,7 +742,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.7\" target=\"_blank\">4.2.7. In WG Last Call</a>\r\n\r\n A document \"In WG Last Call\" is an I-D for which a WG Last Call (WGLC) has been issued and is in progress.\r\n\r\n Note that conducting a WGLC is an optional part of the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418].\r\n\r\n If a WG Chair decides to conduct a WGLC on an I-D, the \"In WG Last Call\" state can be used to track the progress of the WGLC. The Chair may configure the Datatracker to send a WGLC message to one or more mailing lists when the Chair moves the I-D into this state. The WG Chair may also be able to select a different set of mailing lists for a different document undergoing a WGLC; some documents may deserve coordination with other WGs.\r\n\r\n A WG I-D in this state should remain \"In WG Last Call\" until the WG Chair moves it to another state. The WG Chair may configure the Datatracker to send an e-mail after a specified period of time to remind or 'nudge' the Chair to conclude the WGLC and to determine the next state for the document.\r\n\r\n It is possible for one WGLC to lead into another WGLC for the same document. For example, an I-D that completed a WGLC as an \"Informational\" document may need another WGLC if a decision is taken to convert the I-D into a Standards Track document.",
+      "desc": "The Working Group (WG) document is currently subject to an active WG Last Call (WGLC) review per Section 7.4 of RFC2418.",
       "name": "In WG Last Call",
       "next_states": [
         38,
@@ -759,7 +759,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.8\" target=\"_blank\">4.2.8. Waiting for WG Chair Go-Ahead</a>\r\n\r\n A WG Chair may wish to place an I-D that receives a lot of comments during a WGLC into the \"Waiting for WG Chair Go-Ahead\" state. This state describes an I-D that has undergone a WGLC; however, the Chair is not yet ready to call consensus on the document.\r\n\r\n If comments from the WGLC need to be responded to, or a revision to the I-D is needed, the Chair may place an I-D into this state until all of the WGLC comments are adequately addressed and the (possibly revised) document is in the I-D repository.",
+      "desc": "The Working Group (WG) document has completed Working Group Last Call (WGLC), but the WG chair(s) are not yet ready to call consensus on the document. The reasons for this may include comments from the WGLC need to be responded to, or a revision to the document is needed",
       "name": "Waiting for WG Chair Go-Ahead",
       "next_states": [
         41,
@@ -775,7 +775,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.9\" target=\"_blank\">4.2.9. WG Consensus: Waiting for Writeup</a>\r\n\r\n A document in the \"WG Consensus: Waiting for Writeup\" state has essentially completed its development within the working group, and is nearly ready to be sent to the IESG for publication. The last thing to be done is the preparation of a protocol writeup by a Document Shepherd. The IESG requires that a document shepherd writeup be completed before publication of the I-D is requested. The IETF document shepherding process and the role of a WG Document Shepherd is described in RFC 4858 [RFC4858]\r\n\r\n A WG Chair may call consensus on an I-D without a formal WGLC and transition an I-D that was in the \"WG Document\" state directly into this state.\r\n\r\n The name of this state includes the words \"Waiting for Writeup\" because a good document shepherd writeup takes time to prepare.",
+      "desc": "The Working Group (WG) document has consensus to proceed to publication.  However, the document is waiting for a document shepherd write-up per RFC4858.",
       "name": "WG Consensus: Waiting for Write-Up",
       "next_states": [
         44
@@ -790,7 +790,7 @@
   },
   {
     "fields": {
-      "desc": "<a href=\"https://www.rfc-editor.org/rfc/rfc6174.html#section-4.2.10\" target=\"_blank\">4.2.10. Submitted to IESG for Publication</a>\r\n\r\n This state describes a WG document that has been submitted to the IESG for publication and that has not been sent back to the working group for revision.\r\n\r\n An I-D in this state may be under review by the IESG, it may have been approved and be in the RFC Editor's queue, or it may have been published as an RFC. Other possibilities exist too. The document may be \"Dead\" (in the IESG state machine) or in a \"Do Not Publish\" state.",
+      "desc": "The Working Group (WG) document has left the WG and been submitted to the Internet Engineering Steering Group (IESG) for evaluation and publication.  See the “IESG State” or “RFC Editor State” for further details on the state of the document.",
       "name": "Submitted to IESG for Publication",
       "next_states": [
         38
@@ -2020,7 +2020,7 @@
   },
   {
     "fields": {
-      "desc": "The document has been marked as a candidate for WG adoption by the WG Chair.  This state can be used before a call for adoption is issued (and the document is put in the \"Call For Adoption By WG Issued\" state), to indicate that the document is in the queue for a call for adoption, even if none has been issued yet.",
+      "desc": "The individual submission document has been marked by the Working Group (WG) chairs as a candidate for adoption by the WG, but no adoption call has been started.",
       "name": "Candidate for WG Adoption",
       "next_states": [
         35
@@ -2152,7 +2152,7 @@
   },
   {
     "fields": {
-      "desc": "In some areas, it can be desirable to wait for multiple interoperable implementations before progressing a draft to be an RFC, and in some WGs this is required.  This state should be entered after WG Last Call has completed.",
+      "desc": "The progression of this Working Group (WG) document towards publication is paused as it awaits implementation. The process governing the approach to implementations is WG-specific.",
       "name": "Waiting for Implementation",
       "next_states": [],
       "order": 8,
@@ -2165,7 +2165,7 @@
   },
   {
     "fields": {
-      "desc": "Held by WG, see document history for details.",
+      "desc": "Held by Working Group (WG) chairs for administrative reasons.  See document history for details.",
       "name": "Held by WG",
       "next_states": [],
       "order": 9,
@@ -4473,6 +4473,7 @@
       ],
       "session_purposes": [
         "coding",
+        "open_meeting",
         "presentation",
         "social",
         "tutorial"
@@ -5535,7 +5536,6 @@
       ],
       "desc": "Recipients for a message when a new incoming liaison statement is posted",
       "to": [
-        "liaison_from_contact",
         "liaison_to_contacts"
       ]
     },