Merged in [9803] from lars@netapp.com:
Convert a few more URLs from http to https. - Legacy-Id: 9819 Note: SVN reference [9803] has been migrated to Git commit 73d876f9127ccd224edc06c49f4f99258445885c
This commit is contained in:
Henrik Levkowetz
parent
a004a8ffdf
commit
25f2ee5067
|
|
@ -3006,7 +3006,7 @@
|
|||
"slug": "rfcqueue",
|
||||
"type": "draft-iesg",
|
||||
"order": 31,
|
||||
"desc": "The document is in the RFC editor Queue (as confirmed by http://www.rfc-editor.org/queue.html)."
|
||||
"desc": "The document is in the RFC editor Queue (as confirmed by https://www.rfc-editor.org/queue.html)."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 17
|
||||
|
|
@ -3478,7 +3478,7 @@
|
|||
"slug": "c-adopt",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 1,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.1\" target=\"_blank\">4.2.1. Call for Adoption by WG Issued</a>\n\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.\n\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.\n\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.\n\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.\n\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 href=\"https://tools.ietf.org/html/rfc6174#section-4.2.1\" target=\"_blank\">4.2.1. Call for Adoption by WG Issued</a>\n\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.\n\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.\n\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.\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 35
|
||||
|
|
@ -3493,7 +3493,7 @@
|
|||
"slug": "adopt-wg",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 2,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.2\" target=\"_blank\">4.2.2. Adopted by a WG</a>\n\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.\n\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.\n\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'.\n\n The filename of a WG document is supposed to be formatted as 'draft- ietf-wgname-topic-nn'.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.2\" target=\"_blank\">4.2.2. Adopted by a WG</a>\n\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.\n\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.\n\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'.\n\n The filename of a WG document is supposed to be formatted as 'draft- ietf-wgname-topic-nn'.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 36
|
||||
|
|
@ -3506,7 +3506,7 @@
|
|||
"slug": "info",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 3,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.3\" target=\"_blank\">4.2.3. Adopted for WG Info Only</a>\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.3\" target=\"_blank\">4.2.3. Adopted for WG Info Only</a>\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 37
|
||||
|
|
@ -3524,7 +3524,7 @@
|
|||
"slug": "wg-doc",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 4,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.4\" target=\"_blank\">4.2.4. WG Document</a>\n\n The \"WG Document\" state describes an I-D that has been adopted by an IETF WG and is being actively developed.\n\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.\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.4\" target=\"_blank\">4.2.4. WG Document</a>\n\n The \"WG Document\" state describes an I-D that has been adopted by an IETF WG and is being actively developed.\n\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.\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 38
|
||||
|
|
@ -3539,7 +3539,7 @@
|
|||
"slug": "parked",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 5,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.5\" target=\"_blank\">4.2.5. Parked WG Document</a>\n\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.\n\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.\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.5\" target=\"_blank\">4.2.5. Parked WG Document</a>\n\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.\n\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.\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 39
|
||||
|
|
@ -3554,7 +3554,7 @@
|
|||
"slug": "dead",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 6,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.6\" target=\"_blank\">4.2.6. Dead WG Document</a>\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.6\" target=\"_blank\">4.2.6. Dead WG Document</a>\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 40
|
||||
|
|
@ -3571,7 +3571,7 @@
|
|||
"slug": "wg-lc",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 7,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.7\" target=\"_blank\">4.2.7. In WG Last Call</a>\n\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.\n\n Note that conducting a WGLC is an optional part of the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418].\n\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.\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.7\" target=\"_blank\">4.2.7. In WG Last Call</a>\n\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.\n\n Note that conducting a WGLC is an optional part of the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418].\n\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.\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 41
|
||||
|
|
@ -3587,7 +3587,7 @@
|
|||
"slug": "chair-w",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 8,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.8\" target=\"_blank\">4.2.8. Waiting for WG Chair Go-Ahead</a>\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.8\" target=\"_blank\">4.2.8. Waiting for WG Chair Go-Ahead</a>\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 42
|
||||
|
|
@ -3602,7 +3602,7 @@
|
|||
"slug": "writeupw",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 9,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.9\" target=\"_blank\">4.2.9. WG Consensus: Waiting for Writeup</a>\n\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]\n\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.\n\n The name of this state includes the words \"Waiting for Writeup\" because a good document shepherd writeup takes time to prepare."
|
||||
"desc": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.9\" target=\"_blank\">4.2.9. WG Consensus: Waiting for Writeup</a>\n\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]\n\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.\n\n The name of this state includes the words \"Waiting for Writeup\" because a good document shepherd writeup takes time to prepare."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 43
|
||||
|
|
@ -3617,7 +3617,7 @@
|
|||
"slug": "sub-pub",
|
||||
"type": "draft-stream-ietf",
|
||||
"order": 10,
|
||||
"desc": "<a href=\"http://tools.ietf.org/html/rfc6174#section-4.2.10\" target=\"_blank\">4.2.10. Submitted to IESG for Publication</a>\n\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.\n\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": "<a href=\"https://tools.ietf.org/html/rfc6174#section-4.2.10\" target=\"_blank\">4.2.10. Submitted to IESG for Publication</a>\n\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.\n\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."
|
||||
},
|
||||
"model": "doc.state",
|
||||
"pk": 44
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ email messages to the Responsible Area Director. (It should be in a
|
|||
separate email because this questionnaire is publicly available.)
|
||||
|
||||
(11) Identify any ID nits the Document Shepherd has found in this
|
||||
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
||||
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
||||
Checklist). Boilerplate checks are not enough; this check needs to be
|
||||
thorough.
|
||||
|
||||
|
|
@ -214,7 +214,7 @@ email messages to the Responsible Area Director. (It should be in a
|
|||
separate email because this questionnaire is publicly available.)
|
||||
|
||||
(11) Identify any ID nits the Document Shepherd has found in this
|
||||
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
||||
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
||||
Checklist). Boilerplate checks are not enough; this check needs to be
|
||||
thorough.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
{% for item in filtered_assignments.all.distinct %}{% if item.timeslot.type.slug == "break" %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","Break","{{ schedule.meeting.break_area}}","","","","{{ item.timeslot.name }}","b{{ item.timeslot.pk }}","",""
|
||||
{% endif %}{% if item.timeslot.type.slug == "reg" %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","{{ item.timeslot.type.name }}","{{ schedule.meeting.reg_area }}","","","","{{ item.timeslot.name }}","r{{item.timeslot.pk}}","",""
|
||||
{% endif %}{% if item.timeslot.type.slug == "other" %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","None","{{ item.timeslot.location.name }}","","{{ item.session.group.acronym }}","{% if item.session.group.parent %}{{item.session.group.parent.acronym|upper}}{% endif %}","{{ item.session.name }}","{{item.session.pk}}","",""
|
||||
{% endif %}{% if item.timeslot.type.slug == "plenary" %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","{{ item.session.name }}","{{ item.timeslot.location.name }}","","{{ item.session.group.acronym }}","","{{ item.session.name }}","{{item.session.pk}}","{% if item.session.agenda %}http://www.ietf.org/proceedings/{{ schedule.meeting.number }}/agenda/{{ item.session.agenda.external_url }}{% endif %}","{% if item.session.slides %}{% for slide in item.session.slides %}http://www.ietf.org/proceedings/{{ schedule.meeting.number }}/slides/{{ slide.external_url }}{% if not forloop.last %}|{% endif %}{% endfor %}{% endif %}"
|
||||
{% endif %}{% if item.timeslot.type.slug == "session" and item.session.group %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","{{ item.timeslot.name }}","{{ item.timeslot.location.name }}","{{ item.session.group.parent.acronym|upper }}","{{ item.session.group.acronym }}","{{ item.session.lame_description }}","{{ item.session.group.name }}","{{ item.session.pk}}","{% if item.session.agenda %}http://www.ietf.org/proceedings/{{ schedule.meeting.number }}/agenda/{{ item.session.agenda.external_url }}{% endif %}","{% if item.session.slides %}{% for slide in item.session.slides %}http://www.ietf.org/proceedings/{{ schedule.meeting.number }}/slides/{{ slide.external_url }}{% if not forloop.last %}|{% endif %}{% endfor %}{% endif %}"
|
||||
{% endif %}{% if item.timeslot.type.slug == "plenary" %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","{{ item.session.name }}","{{ item.timeslot.location.name }}","","{{ item.session.group.acronym }}","","{{ item.session.name }}","{{item.session.pk}}","{% if item.session.agenda %}https://www.ietf.org/proceedings/{{ schedule.meeting.number }}/agenda/{{ item.session.agenda.external_url }}{% endif %}","{% if item.session.slides %}{% for slide in item.session.slides %}https://www.ietf.org/proceedings/{{ schedule.meeting.number }}/slides/{{ slide.external_url }}{% if not forloop.last %}|{% endif %}{% endfor %}{% endif %}"
|
||||
{% endif %}{% if item.timeslot.type.slug == "session" and item.session.group %}"{{ item.timeslot.time|date:"Y-m-d" }}","{{ item.timeslot.time_desc|slice:":4" }}","{{ item.timeslot.time_desc|slice:"5:9" }}","{{ item.timeslot.name }}","{{ item.timeslot.location.name }}","{{ item.session.group.parent.acronym|upper }}","{{ item.session.group.acronym }}","{{ item.session.lame_description }}","{{ item.session.group.name }}","{{ item.session.pk}}","{% if item.session.agenda %}https://www.ietf.org/proceedings/{{ schedule.meeting.number }}/agenda/{{ item.session.agenda.external_url }}{% endif %}","{% if item.session.slides %}{% for slide in item.session.slides %}https://www.ietf.org/proceedings/{{ schedule.meeting.number }}/slides/{{ slide.external_url }}{% if not forloop.last %}|{% endif %}{% endfor %}{% endif %}"
|
||||
{% endif %}{% endfor %}{% endautoescape %}
|
||||
|
|
|
|||
|
Can't render this file because it contains an unexpected character in line 1 and column 63.
|
|
|
@ -43,7 +43,7 @@
|
|||
During more than a year, from July 2013 to late 2014, <i>Lars Eggert</i> worked intensively
|
||||
on a major facelift to the datatracker, porting the GUI to Bootstrap. The work
|
||||
took
|
||||
<a href="http://trac.tools.ietf.org/tools/ietfdb/log/personal/lars?rev=8652&stop_rev=5871&limit=500">
|
||||
<a href="https://trac.tools.ietf.org/tools/ietfdb/log/personal/lars?rev=8652&stop_rev=5871&limit=500">
|
||||
287 separate commits
|
||||
</a>, and comprised changes to 1016 different files.
|
||||
|
||||
|
|
@ -66,10 +66,10 @@
|
|||
<p>
|
||||
|
||||
Additional
|
||||
<a href="http://trac.tools.ietf.org/tools/ietfdb/log/branch/iola?rev=9116&stop_rev=8520&limit=200">
|
||||
<a href="https://trac.tools.ietf.org/tools/ietfdb/log/branch/iola?rev=9116&stop_rev=8520&limit=200">
|
||||
page conversion work
|
||||
</a> has been done by <i>Ole Laursen</i>, with
|
||||
<a href="http://trac.tools.ietf.org/tools/ietfdb/log/personal/henrik/facelift-r9116">
|
||||
<a href="https://trac.tools.ietf.org/tools/ietfdb/log/personal/henrik/facelift-r9116">
|
||||
final style tweaks, bug-fixes and adaptations
|
||||
</a>
|
||||
by <i>Henrik Levkowetz</i>, giving it a distinct
|
||||
|
|
|
|||
Loading…
Reference in a new issue