ietf.bcp14

Состояние сохранности

• официальные байты2 редакций

  Закреплены байты официальной публикации.

Глубина формализации §33.1

EXECUTABLE 10

на фрагмент ссылается выводящий узел — из него что-то выводится

ANCHORED 0

адресуем семантическим узлом, но вывода нет

SOURCE_ONLY 5

текст закреплён и адресуем, ссылок нет

Уровни вычислены из CLIR, авторской разметки они не имеют (§33.1, errata E-0013): разметка руками означала бы, что ошибка автора молча меняет отчёт о полноте. Это не доля акта: доля документа, покрытая фрагментами, измеряется против байтов закреплённой публикации (§27.3) и здесь не считается.

Состав

Источники

• Key words for use in RFCs to Indicate Requirement Levels · RFC 2119, BCP 14 · редакций: 1
• Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words · RFC 8174, BCP 14 · редакций: 1

Экспорт §24

• AllCapitals — the key word appears in all capitals and so carries its defined meaning (RFC 8174)
• Author — the author of an IETF document, who chooses which imperatives to use
• Casing — whether a key word appears in all capitals or not
• Document — an IETF document in which the key words may be used
• Implementation — an implementation of the specification
• Keyword — a BCP 14 key word
• Lowercase — the key word is not capitalized and so has its normal English meaning (RFC 8174)
• May — MAY — the item is truly optional (RFC 2119, Section 5)
• Must — MUST — an absolute requirement of the specification (RFC 2119, Section 1)
• MustNot — MUST NOT — an absolute prohibition of the specification (RFC 2119, Section 2)
• NotRecommended — NOT RECOMMENDED — synonym of SHOULD NOT; added to the inclusion phrase by RFC 8174
• Optional — OPTIONAL — synonym of MAY (RFC 2119, Section 5)
• Recommended — RECOMMENDED — synonym of SHOULD (RFC 2119, Section 3)
• Required — REQUIRED — synonym of MUST (RFC 2119, Section 1)
• Requirement — an item, a definition or a particular behavior to which a key word is attached
• Shall — SHALL — synonym of MUST (RFC 2119, Section 1)
• ShallNot — SHALL NOT — synonym of MUST NOT (RFC 2119, Section 2)
• Should — SHOULD — valid reasons may exist to ignore the item (RFC 2119, Section 3)
• ShouldNot — SHOULD NOT — valid reasons may exist when the behavior is acceptable (RFC 2119, Section 4)
• absolute_prohibition — the definition is an absolute prohibition of the specification
• absolute_requirement — the definition is an absolute requirement of the specification
• abstains_from — the implementation abstains from the behaviour which the requirement prohibits
• actually_required_for_interoperation — the requirement is actually required for interoperation
• adopted_bcp14 — the document incorporates the BCP 14 phrase and so adopts these definitions
• authored_by — the document is authored by the person
• behaviour_conforms — the observed behaviour of the implementation conforms to the requirement
• behaviour_deviates — the observed behaviour of the implementation deviates from the requirement
• claims_conformance — the implementation claims conformance to the document
• discouraged_item — the behavior is discouraged: valid reasons may exist when it is acceptable or even useful
• discouragement_binding — the discouragement binds this implementation
• implications_understood_and_weighed — the full implications have been understood and carefully weighed before choosing a different course
• includes_option — the implementation includes the optional item
• keyword_used — the key word carries its BCP 14 meaning for this requirement
• keyword_written — the key word is written next to the requirement in the given casing
• limits_potentially_harmful_behavior — the requirement limits behavior which has potential for causing harm
• omits_option — the implementation does not include the optional item
• recommendation_binding — the recommendation binds this implementation
• recommended_item — the item is recommended: valid reasons may exist to ignore it
• requirement_satisfied — the implementation satisfies the requirement
• stated_in — the requirement is stated in the document
• subject_to — the implementation is bound by the requirement
• truly_optional — the item is truly optional
• uses_imperative — the author has used a BCP 14 imperative for this requirement
• valid_reason_for_discouraged_behaviour — there exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful
• valid_reason_to_ignore — there exist valid reasons in particular circumstances to ignore this particular item

Испытать

Этот пакет в рабочий стол не вложен, и кнопки «испытать» у него нет: она открывала бы пустоту. Вложенные выбраны под механику, которую показывают, а не по важности акта — исполнить любой другой пакет можно, открыв его каталог в рабочем столе с диска.

• faraid.shares — Фараид — наследственный расчёт исламского права
• kz.corpus.pinningexample — Положение о порядке учёта обращений
• kz.corpus.restdaytransfer — О переносе дня отдыха в 2023 году
• kz.corpus.socialassistance — Адресная социальная помощь (учебный срез)
• kz.corpus.tuystyq — Туыстық жүйе — казахская система родства

Сослаться

Адрес нормы неизменен: contentHash посчитан по каноническим байтам §208, и любая правка пакета даёт другой хэш. Ссылка ниже указывает не на «последнюю версию», а на конкретные байты — то, чего требует цитирование и чего не даёт номер версии.

Key words for use in RFCs to Indicate Requirement Levels · RFC2119 · ietf.bcp14@0.1.0 · sha256:908bc6665c19d788078db551bca3439adf4dec945b14b5cd20d219602afa13e0