Коап обязательные работы: КоАП РФ Статья 3.13. Обязательные работы / КонсультантПлюс

Содержание

КоАП РФ Статья 32.13. Исполнение постановления о назначении обязательных работ

(введена Федеральным законом от 08.06.2012 N 65-ФЗ)

1. Постановление судьи о назначении обязательных работ исполняется судебным приставом-исполнителем в порядке, установленном федеральным законодательством.

2. Виды обязательных работ и перечень организаций, в которых лица, которым назначено административное наказание в виде обязательных работ, отбывают обязательные работы, определяются органами местного самоуправления по согласованию с территориальными органами федерального органа исполнительной власти, уполномоченного на осуществление функций по принудительному исполнению исполнительных документов и обеспечению установленного порядка деятельности судов. Виды обязательных работ, для выполнения которых требуются специальные навыки или познания, не могут определяться в отношении лиц, не обладающих такими навыками или познаниями.

3. Лицо, которому назначено административное наказание в виде обязательных работ, привлекается к отбыванию обязательных работ не позднее десяти дней со дня возбуждения судебным приставом-исполнителем исполнительного производства.

4. Судебные приставы-исполнители ведут учет лиц, которым назначено административное наказание в виде обязательных работ, разъясняют таким лицам порядок и условия отбывания обязательных работ, согласовывают с органами местного самоуправления перечень организаций, в которых лица, которым назначено административное наказание в виде обязательных работ, отбывают обязательные работы, контролируют поведение таких лиц, ведут суммарный учет отработанного ими времени.

5. Лица, которым назначено административное наказание в виде обязательных работ, обязаны соблюдать правила внутреннего распорядка организаций, в которых такие лица отбывают обязательные работы, добросовестно работать на определяемых для них объектах в течение установленного судом срока обязательных работ, ставить в известность судебного пристава-исполнителя об изменении места жительства, а также являться по его вызову.

6. Предоставление лицу, которому назначено административное наказание в виде обязательных работ, ежегодного оплачиваемого отпуска по основному месту работы не приостанавливает исполнение административного наказания в виде обязательных работ.

7. Лицо, которому назначено административное наказание в виде обязательных работ, вправе обратиться в суд с ходатайством об освобождении от дальнейшего отбывания обязательных работ в случае признания его инвалидом I или II группы, наступления беременности либо тяжелой болезни, препятствующей отбыванию обязательных работ. Об удовлетворении данного ходатайства судья выносит постановление о прекращении исполнения постановления о назначении административного наказания в виде обязательных работ.

8. Обязательные работы выполняются лицом, которому назначено административное наказание в виде обязательных работ, на безвозмездной основе.

9. Срок обязательных работ исчисляется в часах, в течение которых лицо, которому назначено административное наказание в виде обязательных работ, отбывало обязательные работы.

10. Время обязательных работ в выходные дни и дни, когда лицо, которому назначено административное наказание в виде обязательных работ, не занято на основной работе, службе или учебе, не может превышать четырех часов; в рабочие дни — двух часов после окончания работы, службы или учебы. На основании письменного заявления лица, которому назначено административное наказание в виде обязательных работ, максимальное время обязательных работ в выходные дни и дни, когда лицо, которому назначено административное наказание в виде обязательных работ, не занято на основной работе, службе или учебе, судебный пристав-исполнитель вправе увеличить до восьми часов; в рабочие дни — до четырех часов после окончания работы, службы или учебы. Время обязательных работ в течение недели, как правило, не может быть менее двенадцати часов. При наличии уважительных причин судебный пристав-исполнитель вправе разрешить лицу, которому назначено административное наказание в виде обязательных работ, отработать в течение недели меньшее количество часов.

(часть 10 в ред. Федерального закона от 01.05.2016 N 135-ФЗ)

(см. текст в предыдущей редакции)

11. На администрацию организации, в которой лицо, которому назначено административное наказание в виде обязательных работ, отбывает обязательные работы, возлагаются контроль за выполнением этим лицом определенных для него работ, уведомление судебного пристава-исполнителя о количестве отработанных часов или об уклонении лица, которому назначено административное наказание в виде обязательных работ, от отбывания обязательных работ.

12. В случае уклонения лица, которому назначено административное наказание в виде обязательных работ, от отбывания обязательных работ, выразившегося в неоднократном отказе от выполнения работ, и (или) неоднократном невыходе такого лица на обязательные работы без уважительных причин, и (или) неоднократном нарушении трудовой дисциплины, подтвержденных документами организации, в которой лицо, которому назначено административное наказание в виде обязательных работ, отбывает обязательные работы, судебный пристав-исполнитель составляет протокол об административном правонарушении, предусмотренном частью 4 статьи 20.25 настоящего Кодекса.

Открыть полный текст документа

Ст. 3.13 КОАП РФ. Обязательные работы

1. Обязательные работы заключаются в выполнении физическим лицом, совершившим административное правонарушение, в свободное от основной работы, службы или учебы время бесплатных общественно полезных работ. Обязательные работы назначаются судьей.

2. Обязательные работы устанавливаются на срок от двадцати до двухсот часов и отбываются не более четырех часов в день. Максимальное время обязательных работ может быть увеличено до восьми часов в день в порядке, предусмотренном частью 10 статьи 32.13 настоящего Кодекса.

3. Обязательные работы не применяются к беременным женщинам, женщинам, имеющим детей в возрасте до трех лет, инвалидам I и II групп, военнослужащим, гражданам, призванным на военные сборы, а также к имеющим специальные звания сотрудникам Следственного комитета Российской Федерации, органов внутренних дел, войск национальной гвардии Российской Федерации, органов и учреждений уголовно-исполнительной системы, органов принудительного исполнения Российской Федерации, Государственной противопожарной службы и таможенных органов.

См. все связанные документы >>>

Комментируемая ст. 3.13 КоАП РФ конкретизирует порядок применения административного наказания в виде обязательных работ.

Обязательные работы заключаются в выполнении физическим лицом, совершившим административное правонарушение, в свободное от основной работы, службы или учебы время бесплатных общественно полезных работ. Обязательные работы назначаются судьей (ч. 1 ст. 3.13 КоАП РФ).

Согласно ч. 3 ст. 3.13 КоАП РФ обязательные работы не применяются к:

а) беременным женщинам;

б) женщинам, имеющим детей в возрасте до 3 лет;

в) инвалидам I и II групп;

г) военнослужащим;

д) гражданам;

е) призванным на военные сборы;

ж) а также к имеющим специальные звания сотрудникам Следственного комитета Российской Федерации, органов внутренних дел, войск национальной гвардии Российской Федерации, органов и учреждений уголовно-исполнительной системы, Государственной противопожарной службы и таможенных органов.

Согласно ст. 109.2 Федерального закона от 02.10.2007 N 229-ФЗ «Об исполнительном производстве» (далее — Закон N 229-ФЗ) исполнение судебным приставом-исполнителем исполнительного документа об отбывании обязательных работ заключается в направлении должника в организацию, включенную в перечень организаций, в которых лица, которым назначено административное наказание в виде обязательных работ, отбывают обязательные работы, и осуществлении контроля за выполнением должником таких работ.

Согласно ст. 32.13 КоАП РФ виды обязательных работ и перечень организаций, в которых лица, которым назначено административное наказание в виде обязательных работ, отбывают обязательные работы, определяются органами местного самоуправления по согласованию с территориальными органами федерального органа исполнительной власти, уполномоченного на осуществление функций по принудительному исполнению исполнительных документов и обеспечению установленного порядка деятельности судов.

Виды обязательных работ, для выполнения которых требуются специальные навыки или познания, не могут определяться в отношении лиц, не обладающих такими навыками или познаниями.

Обязательные работы устанавливаются на срок от 20 до 200 часов и отбываются не более 4 часов в день. Максимальное время обязательных работ может быть увеличено до 8 часов в день в порядке, предусмотренном ч. 10 ст. 32.13 КоАП РФ (ч. 2 ст. 3.13 КоАП РФ).

При этом срок обязательных работ исчисляется в часах, в течение которых должник, которому назначено административное наказание в виде обязательных работ, отбывает такие работы.

Время обязательных работ не может превышать:

а) 4 часов в выходные дни и в дни, когда лицо, которому назначено административное наказание в виде обязательных работ, не занято на основной работе, службе или учебе;

б) 2 часов в рабочие дни после окончания работы, службы или учебы, а с согласия лица, которому назначено административное наказание в виде обязательных работ, — 4 часов.

Время обязательных работ в течение недели, как правило, не может быть менее 12 часов.

При наличии уважительных причин судебный пристав-исполнитель вправе разрешить лицу, которому назначено административное наказание в виде обязательных работ, отработать в течение недели меньшее количество часов (письмо ФССП России от 25.06.2013 N 12/01-17171-АП).

Предоставление лицу, которому назначено административное наказание в виде обязательных работ, ежегодного оплачиваемого отпуска по основному месту работы не приостанавливает исполнение административного наказания в виде обязательных работ.

Лицо, которому назначено административное наказание в виде обязательных работ, вправе обратиться в суд с ходатайством об освобождении от дальнейшего отбывания обязательных работ в случае признания его инвалидом I или II группы, наступления беременности либо тяжелой болезни, препятствующей отбыванию обязательных работ. Об удовлетворении данного ходатайства судья выносит постановление о прекращении исполнения постановления о назначении административного наказания в виде обязательных работ.

На администрацию организации, в которой лицо, которому назначено административное наказание в виде обязательных работ, отбывает обязательные работы, возлагаются контроль за выполнением этим лицом определенных для него работ, уведомление судебного пристава-исполнителя о количестве отработанных часов или об уклонении лица, которому назначено административное наказание в виде обязательных работ, от отбывания обязательных работ.

последние изменения и поправки, судебная практика

СТ 3.13 КоАП РФ

Комментарий к Ст. 3.13 Кодекса об Административных Правонарушениях РФ

1. Обязательные работы являются новым видом административного наказания, который был включен в комментируемый закон в 2012 году, и могут устанавливаться только КоАП РФ.

2. Обязательные работы не являются тождественными содержавшемуся в КоАП РСФСР административному взысканию в виде исправительных работ, которые применялись на срок до двух месяцев с отбыванием их по месту постоянной работы лица, совершившего административное правонарушение, и с удержанием до 20% его заработка в доход государства.

3. Данный вид административного наказания может устанавливаться и применяться только к физическим лицам в качестве основного административного наказания, т.е. обязательные работы применяются только к специальному субъекту — гражданину.

4. Суть данного административного наказания, назначаемого судьей, состоит в том, что обязательные работы заключаются в выполнении физическим лицом, совершившим административное правонарушение, бесплатных общественно полезных работ; отбываются в свободное от основной работы, службы или учебы время.

5. В соответствии с ч. 2 ст. 3.13 КоАП РФ обязательные работы устанавливаются на срок от 20 до 200 часов и отбываются не более четырех часов в день.

Бесплатная юридическая консультация по телефонам:

6. Часть 3 ст. 3.13 КоАП РФ содержит исчерпывающий, т.е. не подлежащий расширительному толкованию, перечень лиц, к которым административное наказание в виде обязательных работ не применяется. К ним отнесены: беременные женщины, женщины, имеющие детей в возрасте до трех лет, инвалиды I и II групп, военнослужащие, граждане, призванные на военные сборы, а также имеющие специальные звания сотрудники органов внутренних дел, органов и учреждений уголовно-исполнительной системы, Государственной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ и таможенных органов.

7. Область применения административного наказания в виде обязательных работ ограничивается возможностью его назначения к физическим лицам, совершившим административные правонарушения, предусмотренные ч. 2 ст. 5.26 КоАП РФ «Нарушение законодательства о свободе совести, свободе вероисповедания и о религиозных объединениях», ч. 2 ст. 12.7 КоАП РФ «Управление транспортным средством водителем, не имеющим права управления транспортным средством», ч. ч. 1 — 6 ст. 20.2 КоАП РФ «Нарушение установленного порядка организации либо проведения собрания, митинга, демонстрации, шествия или пикетирования», ст. 20.2.2 КоАП РФ «Организация массового одновременного пребывания и (или) передвижения граждан в общественных местах, повлекших нарушение общественного порядка»; ст. 20.18 КоАП РФ «Блокирование транспортных коммуникаций», ч. ч. 1 и 2 ст. 20.25 КоАП РФ «Уклонение от исполнения административного наказания», ч. 1 ст. 20.31 КоАП РФ «Нарушение правил поведения зрителей при проведении официальных спортивных соревнований».

8. При назначении обязательных работ лицам, совершившим административные правонарушения, предусмотренные ст. ст. 20.2, 20.2.2, 20.18 КоАП РФ, судьям надлежит руководствоваться Постановлением Конституционного Суда РФ от 14.02.2013 N 4-П «По делу о проверке конституционности Федерального закона «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях и Федеральный закон «О собраниях, митингах, демонстрациях, шествиях и пикетированиях» в связи с запросом группы депутатов Государственной Думы и жалобой гражданина Э.В. Савенко», в котором содержится следующее решение.

Признать взаимосвязанные положения п. п. 4, 7, 8, 9 и 10 ст. 1 Федерального закона от 08.06.2012 N 65-ФЗ «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях и Федеральный закон «О собраниях, митингах, демонстрациях, шествиях и пикетированиях», предусматривающие обязательные работы в качестве вида административного наказания за нарушения, связанные с организацией либо проведением собраний, митингов, демонстраций, шествий и пикетирования или организацией массового одновременного пребывания и (или) передвижения граждан в общественных местах, повлекших нарушение общественного порядка:

— в той мере, в какой они не связаны с вторжением в имущественные права граждан, не предполагают лишение правонарушителя свободы и не являются недопустимым способом принуждения к труду, соответствующими Конституции РФ;

— в той мере, в какой в системе действующего правового регулирования назначение данного вида административного наказания допускается не только в случае причинения вреда здоровью граждан, имуществу физических или юридических лиц либо при наступлении иных подобных последствий, но и при одном лишь формальном нарушении установленного порядка организации или проведения публичных мероприятий, не соответствующими Конституции РФ, ее ч. 1 ст. 1, ч. 1 ст. 19, ст. 31, ч. 2 ст. 37 и ч. 3 ст. 55.

Федеральному законодателю надлежит — исходя из требований Конституции РФ и с учетом правовых позиций Конституционного Суда РФ, выраженных в том числе в настоящем Постановлении, — внести необходимые изменения в правовое регулирование административного наказания в виде обязательных работ.

Впредь до внесения в правовое регулирование надлежащих изменений обязательные работы могут применяться в качестве административного наказания за предусмотренные ст. ст. 20.2, 20.2.2 и 20.18 КоАП РФ административные правонарушения, только если они повлекли причинение вреда здоровью граждан, имуществу физических или юридических лиц либо наступление иных подобных последствий.

Новый КоАП предполагает освободить женщин, воспитывающих детей, от общественных работ — Общество

МОСКВА, 28 апреля. /ТАСС/. Проект нового КоАП предполагает избавить женщин, воспитывающих детей, от административного наказания в виде обязательных работ. Об этом говорится в документе по итогам общественного обсуждения проекта будущего КоАП, который изучил корреспондент ТАСС.

«Проектом КоАП предлагается расширить перечень лиц, которым не может быть назначено административное наказание в виде обязательных работ, путем отнесения к ним женщин, имеющих детей в возрасте до 14 лет, детей-инвалидов; одиноких родителей (или лиц их заменяющих), имеющих ребенка в возрасте до 14 лет; а также лиц, осуществляющих уход за инвалидом I и II групп, в том числе за ребенком-инвалидом», — приводится в документе пояснение Минюста.

Направление таких лиц на общественные работы за административное правонарушение может препятствовать исполнению обязанности родителя по воспитанию ребенка либо обеспечению должного ухода за инвалидом, говорится в пояснении Минюста. Но это не означает прощение за административное правонарушение — у обязательных работ есть альтернативные виды наказания в статьях КоАП, (например, штраф), «вследствие чего невозможность назначения соответствующему лицу данного вида административного наказания не будет влечь его освобождение от административной ответственности», пояснили в Минюсте.

По действующему КоАП обязательные работы не применяются к беременным женщинам, женщинам, имеющим детей в возрасте до трех лет, инвалидам I и II групп, а также военнослужащим и сотрудникам правоохранительных органов.

Вывод воспитывающих детей и ухаживающих за инвалидами из-под возможного наказания в виде обязательных работ в Минюсте пояснили также принципом гуманизма, который прописан в новой редакции КоАП — включенная в проект КоАП статья 1.15 «Принцип гуманизма» определяет, что «административное наказание не должно быть избыточным».

Согласно данным ФССП, которая исполняет это административное наказание, за весь 2019 год оно исполнялось в отношении 567 тыс. человек, на начало апреля этого года оно действовало в отношении 300 тыс. человек. В проекте КоАП предполагается также сократить максимальный срок обязательных работ с 200 до 60 часов.

Сенатор предлагает освободить подростков от обязательных работ за правонарушения | Российское агентство правовой и судебной информации

МОСКВА, 13 мар — РАПСИ. Сенатор Владимир Лукин внес на рассмотрение Госдумы поправку в Кодекс РФ об административных правонарушениях, в которой предлагается установить, что в отношении несовершеннолетних граждан не должны применяться обязательные работы как вид административного наказания. Текст документа опубликован в электронной базе данных нижней палаты парламента.

Изменения подготовлены в часть 3 статьи 3.13 кодекса (обязательные работы). В настоящее время обязательные работы, в частности, не применяются к беременным женщинам, женщинам, имеющим детей в возрасте до трех лет, инвалидам I и II групп, военнослужащим, гражданам, призванным на военные сборы.

Сенатор напомнил, что гражданин подлежит административной ответственности с момента достижения им возраста шестнадцати лет (статья 2.3.КоАП РФ). Вместе с тем в соответствии с законодательством лицо до достижения им возраста 18 лет (совершеннолетия) признается ребенком. Федеральным законодательством о защите прав несовершеннолетних предусмотрена целая система мер и правовых гарантий, направленных на обеспечение прав интересов несовершеннолетних граждан.

В соответствии со статьей 2.3 КоАП РФ несовершеннолетние граждане являются специальными субъектами административной ответственности. В связи с этим дела об административных правонарушениях в отношении них рассматриваются комиссиями по делам несовершеннолетних и защите их прав. Несовершеннолетние могут быть освобождены от административной ответственности с применением к нему меры воздействия, предусмотренной федеральным законодательством о защите прав несовершеннолетних. Включение несовершеннолетних граждан в перечень лиц, к которым не применяются обязательные работы, в больше мере, как считает сенатор, отвечало бы общепризнанным принципам и нормам международного права о недопустимости принудительного труда детей.

В отношении несовершеннолетних обязательные работы применяются в основном за совершение таких правонарушений как побои (статья 6.1.1 КоАП РФ от 60 до 120 часов), мелкое хищение (статья 7.27 КоАП РФ до 120 часов), а также в редких случаях за нарушение правил поведения зрителей при проведении официальных спортивных соревнований (статья 20.31 КоАП РФ до 160 часов). Кроме того, применение данной меры наказания к несовершеннолетним возможно за нарушение законодательства о свободе совести, свободе вероисповедания и о религиозных объединениях (статья 5.26 КоАП РФ до 120 часов), возбуждение ненависти либо вражды, а равно унижение человеческого достоинства (статья 20.3.1 КоАП РФ до 100 часов).

При этом, кодекс не предусматривает каких-либо особенностей исполнения наказаний в виде обязательных работ в отношении несовершеннолетних (статья 32.13). Несовершеннолетние привлекаются к обязательным работам на ряду со взрослыми гражданами. Для примера, в Уголовном кодексе РФ, как отмечает Лукин, проводится разграничение: в зависимости от возраста несовершеннолетнего устанавливается продолжительность обязательных работ и порядок их выполнения.

«Отмена обязательных работ в отношении несовершеннолетних граждан в полной мере будет соответствовать общим принципам назначения административных наказаний, учитывать личность виновного и наличие обстоятельства смягчающего административную ответственность (пункт 9 части 1 статьи 4.2 КоАП РФ совершение административного правонарушения несовершеннолетним)»,— говорится в пояснительной записке к документу.

Госдума разрешила восьмичасовые обязательные работы

Нижняя палата парламента в ходе пленарного заседания 24 февраля в первом чтении приняла законопроект, позволяющий увеличить максимальное количество возможных часов обязательных работ в два раза – до 8.

Законопроект был внесен в Госдуму Правительством РФ в декабре 2015 года. Соответствующие поправки предлагается добавить в некоторые статьи действующего Кодекса РФ об административных правонарушениях, а также в ст. 109.2 ФЗ № 229 «Об исполнительном производстве».

Согласно действующим в данный момент нормам, прописанным в ч. 2 с. 3.13 и ч.10 ст. 32.13 КоАП РФ, такая мера административного наказания, как обязательные работы, отбывается не более четырех часов в день. При этом в рабочие дни правонарушитель уделяет обязательным работам только 2 часа. Как сообщают авторы законопроекта в пояснительной записке, «ограничение времени обязательных работ четырьмя часами в день существенно затягивает сроки исполнения соответствующих постановлений судов». При этом, по словам законотворцев, на практике лица, которым назначено административное наказание в виде обязательных работ, обращаются с просьбой отбывать наказание полный восьмичасовой рабочий день.

Таким образом, проект закона предлагает увеличить максимальное время обязательных работ до 8 в выходные дни и дни, когда лицо, которому назначено административное наказание в виде обязательных работ, не занято на основной работе, службе или учебе. Такое увеличение станет возможным только при наличии письменного заявления лица, которому назначено административное наказание. При этом максимальное время обязательных работ в будние дни остается неизменным – оно может быть увеличено лишь до 4 часов только по письменному заявлению правонарушителя (нормы действующей редакции КоАП).

По словам авторов законопроекта, «внесение в законодательство РФ указанных изменений позволит сократить сроки исполнения постановлений судов о назначении административного наказания в виде обязательных работ».

С текстом законопроекта № 958229-6 «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях и статью 109-2 Федерального закона «Об исполнительном производстве» (в части совершенствования исполнения исполнительных документов об отбывании обязательных работ)» можно ознакомиться здесь.

В России предложили сократить максимальный срок обязательных работ

https://ria.ru/20200529/1572196614.html

В России предложили сократить максимальный срок обязательных работ

В России предложили сократить максимальный срок обязательных работ — РИА Новости, 29.05.2020

В России предложили сократить максимальный срок обязательных работ

Предельный срок назначения обязательных работ в проекте нового Кодекса об административных правонарушениях (КоАП) сокращается до 60 часов взамен 200, сообщается РИА Новости, 29.05.2020

2020-05-29T18:47

общество

министерство юстиции рф (минюст россии)

кодекс об административных правонарушениях (коап)

/html/head/meta[@name=’og:title’]/@content

/html/head/meta[@name=’og:description’]/@content

https://cdn24.img.ria.ru/images/155513/91/1555139185_0:316:3077:2047_1920x0_80_0_0_d84917b817edd37f8fced9a41923d0f4.jpg

МОСКВА, 29 мая — РИА Новости. Предельный срок назначения обязательных работ в проекте нового Кодекса об административных правонарушениях (КоАП) сокращается до 60 часов взамен 200, сообщается на сайте Минюста РФ.»В проекте нового КоАП предусмотрено сокращение предельных сроков административного наказания в виде обязательных работ — с 200 до 60 часов», — говорится в сообщении.Кроме того, расширен перечень лиц, которым предлагается не назначать административный арест и обязательные работы. Среди них родители или опекуны, воспитывающие детей до 14 лет, детей-инвалидов; лица, ухаживающие за инвалидом I и II групп или за ребенком-инвалидом; а также дети-инвалиды.Административный арест не будет применяться к лицам, имеющим заболевание, которое есть в перечне препятствующих отбыванию административного ареста.

https://ria.ru/20200529/1572196446.html

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

2020

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

Новости

ru-RU

https://ria.ru/docs/about/copyright.html

https://xn--c1acbl2abdlkab1og.xn--p1ai/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

https://cdn25.img.ria.ru/images/155513/91/1555139185_348:0:3077:2047_1920x0_80_0_0_0442f848f7d2618546eed809a1699905.jpg

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

общество, министерство юстиции рф (минюст россии), кодекс об административных правонарушениях (коап)

МОСКВА, 29 мая — РИА Новости. Предельный срок назначения обязательных работ в проекте нового Кодекса об административных правонарушениях (КоАП) сокращается до 60 часов взамен 200, сообщается на сайте Минюста РФ.

«В проекте нового КоАП предусмотрено сокращение предельных сроков административного наказания в виде обязательных работ — с 200 до 60 часов», — говорится в сообщении.

Кроме того, расширен перечень лиц, которым предлагается не назначать административный арест и обязательные работы. Среди них родители или опекуны, воспитывающие детей до 14 лет, детей-инвалидов; лица, ухаживающие за инвалидом I и II групп или за ребенком-инвалидом; а также дети-инвалиды.

Административный арест не будет применяться к лицам, имеющим заболевание, которое есть в перечне препятствующих отбыванию административного ареста.

29 мая 2020, 18:42

Минюст убрал увеличенные штрафы из проекта нового КоАП

Когда я буду готов подать заявление на мое пребывание в должности?

Простой ответ: когда будете готовы! Как правило, этого не происходит до года обязательной проверки, который приходится на 6-й год вашего испытательного срока. В настоящее время ваш прогресс в продвижении к должности должен быть официально оценен начальником вашего подразделения и председателем. В редких случаях продвижение по службе может быть предложено до года обязательного обзора, но ускоренное продвижение по службе обычно зарезервировано для действительно исключительных кандидатов. Рассмотрены конкретные критерии для продвижения по службе с продолжением работы по специальности «фундаментальная наука» и «врач-ученый».Они перечислены ниже. Однако на практике вам следует поговорить об этом с начальником вашего подразделения. В качестве резерва Комитет DOM по назначениям и продвижению по службе (COAP), который собирается ежемесячно, будет рассматривать ваше повторное назначение на 3-м, 5-м годах, а затем ежегодно. COAP будет следить за прогрессом преподавателей в это время, и если они решат, что вы готовы к продвижению по службе, они сообщат об этом напрямую начальнику вашего подразделения. И, наконец, поскольку процесс занимает около 12 месяцев, а исключения могут быть сделаны в отдельных случаях и с одобрения вашего начальника отдела и председателя, рекомендуется подавать свой рекламный пакет по крайней мере за год до окончания срока вашего пребывания в должности.

Общие критерии продвижения по службе : Основными критериями продвижения по службе являются академические успехи. В зависимости от трека, качества и влияния научного вклада (например, частота цитирования ISI и качество журналов), членство в почетных организациях (например, ASCI и AAP), значительный вклад в профессиональные организации (учебные секции, редакционные советы, руководящие роли в академических обществах) и т. д.), качество клинической практики, лидерство в образовательных программах и вклад в них, высокое качество преподавания и гранты — основные элементы, лежащие в основе рекомендаций COAP.Письма от всех рецензентов, оценивающих академический вклад, внимательно рассматриваются. COAP признает высоко индивидуализированный характер академической карьеры и стремится выявить уникальный вклад каждого преподавателя, который он проверяет.

Области, требующие особого рассмотрения для продвижения по программе «Базовый курс» или «Врач-ученый» : Кандидаты должны иметь национальную репутацию за выдающуюся независимую работу в своей области стипендии. Серия превосходных рецензируемых статей в уважаемых журналах (что частично оценивается по количеству цитирований и качеству опубликованных журналов) должна рассказывать связную историю об их исследованиях.Успешный кандидат будет иметь несколько независимых исследовательских грантов, обычно от Национального института здравоохранения, других федеральных учреждений или национально признанных фондов. Членство в избранных исследовательских обществах, вклад в профессиональные организации и общества, приглашенные презентации на национальных собраниях и приглашенные лекции указывают на важность исследований человека и его / ее репутацию в стране. Кандидат должен отличаться в обучении студентов-медиков и аспирантов, а также домашних служащих.Ожидается, что от тех, кто занимается лечением пациентов, будут отличные клиницисты.

В подтверждение этих достижений ваша заявка должна предоставить доказательства следующего:

1) Заручившись поддержкой заочного исследования в качестве главного исследователя (в частности, продемонстрировав способность поддерживать независимое финансирование для поддержки вашей исследовательской программы)

2) Публикации: оригинальные исследования высокого качества с дополнительным учетом обзоров, книг, глав или клинических наблюдений.В качестве общего руководства более 30 публикаций с не менее чем 4-5 старшими (или соответствующими) авторами. Это требование зависит от области исследования, поэтому я предлагаю вам поговорить об этом с начальником вашего отдела.

3) Избрание в почетные академические общества (ASCI / AAP) или получение других национальных наград; признание в планировании или участии в национальных и / или международных встречах; обслуживание на национальном уровне экспертных групп. После публикаций и финансирования исследований это, вероятно, следующее по важности соображение при продвижении по службе, о чем следует думать по мере вашего прохождения испытательного срока.

4) Свидетельства независимого мышления и признанных достижений

Платформа пользовательских сервисов — стандартизированное управление и контроль Интернета вещей

Сопоставление конечных точек USP с URI CoAP
Сопоставление записей USP с сообщениями CoAP
1. Обработка успешного запроса CoAP
2. Обработка сбоев запроса CoAP
Шифрование сообщений MTP

Протокол ограниченного приложения (CoAP) MTP передает записи USP между конечными точками USP, используя протокол CoAP, как определено в RFC 7252.Сообщения, которые передаются между клиентами и серверами CoAP, используют взаимодействие обмена сообщениями типа запрос / ответ на основе архитектурных принципов RESTful. На следующем рисунке изображена передача записей USP между конечными точками USP.

Рисунок COAP.1 — Пример: запрос / ответ USP через CoAP MTP

В этом примере запрос USP кодируется в записи USP и инкапсулируется в сообщение запроса CoAP. Когда конечная точка USP получает сообщение запроса CoAP, конечная точка USP немедленно отправляет ответное сообщение CoAP (без записи USP), чтобы указать получение сообщения.Ответ USP, закодированный в записи USP, инкапсулируется в новое сообщение запроса CoAP. Когда конечная точка USP получает ответ USP, она отправляет ответное сообщение CoAP, которое указывает на получение сообщения. Следовательно, все конечные точки, поддерживающие CoAP, будут реализовывать как клиент, так и сервер CoAP.

Как отмечено в определении запроса USP, эта запись USP либо запрашивает у агента выполнение определенного действия (создание, обновление, удаление, действие и т. Д.), Запрашивает информацию об агенте или одном или нескольких элементах службы, либо действует как означает доставку уведомлений от агента контроллеру.Уведомления вызовут появление ответа USP только в том случае, если это указано в запросе на уведомление. Однако ответ CoAP будет отправляться всегда.

Сопоставление конечных точек USP с URI CoAP

Раздел 6 RFC 7252 обсуждает схемы URI для идентификации ресурсов CoAP и предоставляет средства определения местоположения ресурса. Эти ресурсы организованы иерархически и управляются сервером CoAP, который прослушивает запросы CoAP на заданном порту. Конечные точки USP — это один из типов ресурсов CoAP, который идентифицируется и обнаруживается.

R-COAP.0 — Поскольку конечная точка USP является ресурсом, управляемым сервером CoAP, сервер CoAP также ДОЛЖЕН быть идентифицирован, как определено в разделе 6 RFC 7252.

R-COAP.1 — Конечная точка USP ДОЛЖНА быть представлена как ресурс CoAP со следующими атрибутами ресурсов:

Идентификатор на сервере CoAP (uri-path)
Тип ресурса (RT): « bbf.usp.endpoint »
Интерфейс (если): « bbf.usp.c » для контроллера USP или « bbf.usp.a ”для агента USP

Идентификатор на сервере CoAP используется для доставки сообщений конечной точке USP. Когда этот идентификатор используется для доставки сообщений в конечную точку USP, этот идентификатор представляет собой uri-path, который представляет конечную точку USP.

R-COAP.2 — Сообщение запроса CoAP ДОЛЖНО включать параметр Uri-Query, который предоставляет URI сервера CoAP конечной точки, которая является источником запроса CoAP, в формате ? Reply-to = .URI coap и coaps определены в разделах 6.1 и 6.2 RFC 7252. URI НЕ ДОЛЖЕН включать никаких дополнительных запросов в конце.

R-COAP-2a — Когда конечная точка USP получает сообщение запроса CoAP, она ДОЛЖНА использовать опцию Uri-Query ответа, включенную в запрос CoAP, в качестве URI CoAP для ответа USP (если ответ требуется входящий запрос USP).

R-COAP.3 — При создании записей DNS-SD (см. Использование DNS) конечная точка ДОЛЖНА установить атрибут «path» записи TXT DNS-SD, равный значению идентификатора сервера CoAP (uri-path).

Сопоставление записей USP с сообщениями CoAP

R-COAP.4 — Чтобы записи USP передавались между контроллером USP и агентом с использованием CoAP, запись USP ДОЛЖНА быть инкапсулирована в сообщение CoAP, как определено в RFC 7252.

R-COAP.5 — Записи USP, превышающие размер сообщения CoAP, ДОЛЖНЫ быть блочно инкапсулированы в соответствии с RFC 7959.

Записи USP передаются с использованием ресурса CoAP, который представляет получающую конечную точку USP, с использованием метода CoAP POST, как определено в RFC 7252.

R-COAP.6 — Формат содержимого CoAP для записей USP ДОЛЖЕН быть приложением / октетным потоком (ID = 42) для кодирования protobuf.

Обработка успешного запроса CoAP

R-COAP.7 — После успешного приема сообщения CoAP с помощью POST сервер CoAP ДОЛЖЕН ответить кодом ответа 2,04 (изменено) .

Обработка сбоев запроса CoAP

Иногда запросы CoAP не могут быть выполнены из-за проблем в основном транспорте (например,g., тайм-аут) или код ответа сбоя, полученный от сервера CoAP из-за проблем в запросе CoAP, отправленном клиентом CoAP (4.xx), или проблем с реализацией сервера CoAP (5.xx).

R-COAP.8 — Клиенты и серверы CoAP ДОЛЖНЫ реализовывать требуемые коды ответов CoAP, определенные в разделе 5.9 RFC 7252.

R-COAP.9 — Когда клиент CoAP получает индикацию отказа (например, тайм-аут) от нижележащего транспортного уровня, клиент CoAP ДОЛЖЕН указать тайм-аут для конечной точки USP.

R-COAP.10 — Когда клиент CoAP получает код ответа 4.xx или 5.xx, клиент CoAP ДОЛЖЕН указать конечной точке USP отказ CoAP.

Когда клиент CoAP отправляет запрос CoAP, клиент CoAP может предоставить неверную или отсутствующую информацию в запросе CoAP. Например, клиент CoAP может отправить запрос CoAP с:

Неверный метод CoAP: сервер CoAP отвечает 4,05
Неверные параметры формата содержимого: сервер CoAP отвечает 4.15
Неверная или непонятная полезная нагрузка: сервер CoAP отвечает 4,00

R-COAP.11 — Когда сервер CoAP получает запрос CoAP с недопустимым методом CoAP, сервер CoAP ДОЛЖЕН ответить кодом ответа 4.05 .

R-COAP.12 — Когда сервер CoAP получает запрос CoAP с недопустимой опцией формата содержимого CoAP, сервер CoAP ДОЛЖЕН ответить кодом ответа 4.15 .

R-COAP.13 — Когда сервер CoAP получает запрос CoAP, а принимающая конечная точка USP не может интерпретировать или декодировать запись USP для обработки, сервер CoAP ДОЛЖЕН ответить кодом ответа 4,00 .

Шифрование сообщений MTP

CoAP Шифрование сообщений MTP обеспечивается с использованием DTLS, как описано в разделе 9 RFC 7252.

В разделе 9 RFC 7252 сообщения CoAP защищены одним из трех режимов:

NoSec: DTLS отключен
PreSharedKey: DTLS включен, и конечная точка MTP использует общие ключи, которые используются для проверки подлинности конечных точек CoAP, участвующих в обмене сообщениями
RawPublicKey: DTLS включен, и конечная точка MTP имеет асимметричную пару ключей без сертификата.Конечная точка MTP имеет идентификатор, рассчитанный на основе открытого ключа и списка других конечных точек MTP, с которыми она может связываться
: DTLS включен, и конечная точка MTP имеет асимметричную пару ключей с сертификатом X.509.

R-COAP.14 — Клиенты и серверы CoAP ДОЛЖНЫ реализовывать режимы безопасности CoAP NoSec и Certificate, как определено в RFC 7252.

В то время как раздел 9 RFC 7252 предоставляет руководство по защите CoAP, дальнейшие рекомендации, связанные с реализациями DTLS для Интернета вещей, представлены в RFC 7925.

R-COAP.15 — Клиенты и серверы CoAP ДОЛЖНЫ реализовывать обязательные операторы RFC 7925, за исключением того, что:

Раздел 4.4.1 Сертификаты контроллера USP могут содержать доменные имена с подстановочными знаками в соответствии с рекомендациями RFC 6125.
Раздел 4.4.2 Идентификаторы сертификатов клиента не используют идентификатор EUI-64, а вместо этого используют идентификатор, определенный для сертификатов клиентов в этом рабочем тексте.
Раздел 4.4.5. URL-адреса сертификатов клиента не требуется.

Поскольку конечные точки USP играют роль как клиента, так и сервера CoAP; когда MTP защищен с использованием режима сертификата безопасности CoAP, конечная точка USP предоставляет сертификат X.509 партнеру MTP.

R-COAP.16 — Когда режим сертификата CoAP используется для защиты MTP, конечная точка USP ДОЛЖНА предоставить партнеру MTP сертификат X.509.

Обратите внимание, что сеансы DTLS, установленные для клиента CoAP конечной точки и сервера CoAP, различны. Следовательно, CoAP может быть зашифрован в одном направлении, а не в другом.Если это произойдет, требования и потоки в Аутентификации и Авторизации будут диктовать использование безопасного обмена сообщениями.

Студент или стажер в кооперативе

Право на участие

Некоторые учебные программы включают опыт работы в учебный план. Вы можете подать заявление о разрешении на работу в кооперативе или стажере, если:

у вас есть действующее разрешение на учебу
работа требуется для завершения вашей учебной программы в Канаде
у вас есть письмо из вашей школы, подтверждающее, что все учащиеся вашей программы должны пройти стажировку для получения степени, а
ваша совместная работа или стажировка составляет 50% или меньше вашей учебной программы

COVID-19 и кооперативное размещение

Во время вспышки COVID-19 многие иностранные студенты учатся онлайн из-за границы.Если ваше учебное заведение и работодатель согласны, вы можете либо

принять канадское рабочее место и начать работать удаленно из своей страны
работа в компании в вашей стране

Если вы работаете удаленно из-за пределов Канады, вы можете работать, пока мы обрабатываем ваши заявки на разрешение на учебу и совместную работу.

Кто не имеет права

Вы не имеете права на разрешение на совместную работу, если принимаете одно из следующих условий:

Английский или французский как второй язык (ESL / FSL),
общих курса, или
курсов для подготовки к другой учебной программе.

Если вы не имеете права на получение разрешения на совместную работу, но хотите работать в Канаде, вам необходимо подать заявление на разрешение на работу.

Как поступать

Порядок подачи заявления на разрешение на совместную работу зависит от того, подавали вы уже заявление на получение разрешения на учебу или нет. Ответьте на несколько вопросов, чтобы получить инструкции.

Как онлайн-подача заявки помогает вам

Никаких курьерских услуг и сроков доставки почты — мы сразу же получим вашу заявку.
Ваши заявки могут быть обработаны быстрее.
Это поможет вам убедиться, что ваша заявка заполнена, прежде чем подавать ее.
Вы можете быстро подать больше документов онлайн (если мы вас об этом попросим).
Вы получаете обновления о статусе своей заявки прямо в своем онлайн-аккаунте.

Для использования инструмента необходимо включить Javascript.

Подайте онлайн-заявку на разрешение на совместную работу

В большинстве случаев вы должны подать заявление онлайн для получения разрешения на совместную работу.

Шаг 1. Убедитесь, что у вас есть то, что вам нужно

Чтобы подать заявку онлайн, вам понадобится:

сканер или фотоаппарат для создания электронных копий ваших документов и
действующая кредитная или дебетовая карта.

Шаг 2. Прочтите инструкцию

Даже если вы подаете заявление онлайн, вам следует прочитать инструкцию до того, как вы заполните . Руководство объяснит, как заполнять каждое поле в форме.

Шаг 3. Подготовьте ответы к онлайн-инструменту

Прежде чем вы сможете загрузить свои формы, вы должны ответить на несколько вопросов. Мы используем ваши ответы, чтобы создать для вас индивидуальный контрольный список документов.

Шаг 4. Узнайте, какую комиссию вы должны заплатить

Чтобы получить разрешение на совместную работу, вам не нужно платить никаких сборов.

Шаг 5. Создайте учетную запись в Интернете или войдите в систему.

Чтобы подать заявку онлайн, вам потребуется учетная запись. Вы можете использовать свою учетную запись для:

оплатите комиссию
подайте заявку
проверьте свой статус

Создайте учетную запись или войдите в систему

Если вы не можете подать заявку онлайн

Вы можете подать заявление в бумажном виде, если:

Вы не можете подать заявление онлайн по причине инвалидности
есть проблема с онлайн-заявкой

Что делать, если вы не можете подать заявку онлайн

Начните свое совместное размещение за пределами Канады

Если вы учитесь онлайн из-за пределов Канады из-за пандемии COVID-19, вы все равно можете пройти совместное обучение.Вы можете начать работать, даже если заявки на разрешение на учебу и совместную работу еще находятся в процессе обработки.

Если ваше учебное заведение и работодатель согласны, вы можете либо

принять канадское рабочее место и начать работать удаленно из вашей страны или
работа в компании в вашей стране

Если вы еще не подавали заявку на разрешение на работу в кооперативе

Вы не можете подать заявку на разрешение на совместную работу отдельно от заявки на разрешение на учебу, если вы подаете заявление из-за пределов Канады.

Если ваше заявление на получение разрешения на учебу все еще обрабатывается и вам нужно разрешение на совместную работу, вы можете использовать веб-форму, чтобы отправить новое письмо о принятии, которое показывает, что вы приняты в программу с обязательным рабочим компонентом .

Если ваше разрешение на учебу уже утверждено и у вас нет разрешения на совместную работу для завершения обязательного рабочего компонента вашей программы, вы все равно можете пройти совместное трудоустройство за пределами Канады .Вы не можете пройти совместное размещение в Канаде без разрешения на совместную работу.

Подать заявление с разрешением на учебу

Если вы еще не подавали заявление на получение разрешения на учебу, вы можете одновременно подать заявление на получение разрешения на совместную работу.

В письме о зачислении от указанного учебного заведения должно быть подтверждено, что совместная работа или стажировка являются частью учебной программы вашей программы. Затем вы можете подать заявление на разрешение на учебу, и мы обработаем ваше разрешение на совместную работу вместе с вашим заявлением на разрешение на учебу.

emqx / emqx-coap: шлюз EMQ X CoAP

emqx-coap — это шлюз CoAP для брокера EMQ X. Он переводит сообщения CoAP в сообщения MQTT и делает возможным взаимодействие между клиентами CoAP и клиентами MQTT.

Пример использования клиента

libcoap — отличная библиотека coap, в которой есть простой клиентский инструмент. Рекомендуется использовать libcoap в качестве клиента coap.

Чтобы скомпилировать libcoap, выполните следующие шаги:

  git clone http: // github.com / obgm / libcoap
cd libcoap
./autogen.sh
./configure --enable-documentation = no --enable-tests = no
делать

Пример публикации:

  libcoap / examples / coap-client -m put -e 1234 "coap: //127.0.0.1/mqtt/topic1? C = client1 & u = tom & p = secret"

название темы — «topic1», а НЕ «/ topic1»
идентификатор клиента — client1
имя пользователя: tom
пароль секретный
— это текстовая строка «1234»

Было опубликовано сообщение mqtt с topic = «topic1», payload = «1234».Любой клиент mqtt или клиент coap, подписавшийся на эту тему, может получить это сообщение немедленно.

Пример подписки:

  libcoap / examples / coap-client -m get -s 10 "coap: //127.0.0.1/mqtt/topic1? C = client1 & u = tom & p = secret"

название темы — «topic1», а НЕ «/ topic1»
идентификатор клиента — client1
имя пользователя: tom
пароль секретный
время подписки 10 секунд

И вы получите следующий результат, если какой-либо клиент mqtt или клиент coap отправил сообщение с текстом «1234567» на «topic1»:

  v: 1 t: CON c: GET i: 31ae {} []
1234567v: 1 t: CON c: GET i: 31af {} [Наблюдать: 1, Uri-Path: mqtt, Uri-Path: topic1, Uri-Query: c = client1, Uri-Query: u = tom, Uri-Query : p = секрет]

Выходное сообщение плохо отформатировано, что скрывает «1234567» в начале 2-й строки.

Настроить

Обычный

Файл: etc / emqx_coap.conf

 ## UDP-порт, который прослушивает CoAP.
##
## Значение: Порт
coap.port = 5683

## Интервал поддержки активности в секундах.
##
## Значение: Продолжительность
## -s: секунды
## -m: минуты
## -h: часы
coap.keepalive = 120 сек.

## Следует ли включать статистику для клиентов CoAP.
##
## Значение: включено | выключенный
coap.enable_stats = off

DTLS

emqx_coap по умолчанию включает одностороннюю аутентификацию.

Если вы хотите отключить его, прокомментируйте эти строки.

Файл: etc / emqx_coap.conf

 ## Порт DTLS, который прослушивает CoAP.
##
## Значение: Порт
coap.dtls.port = 5684

## Файл закрытого ключа для DTLS
##
## Значение: файл
coap.dtls.keyfile = {{platform_etc_dir}} / certs / key.pem

## Сертификат сервера для DTLS.
##
## Значение: файл
coap.dtls.certfile = {{platform_etc_dir}} / certs / cert.pem

Включить двустороннюю аутентификацию

Для двусторонней аутентификации:

 ## Сервер выполняет только проверку x509-пути в режиме verify_peer,
##, поскольку он затем отправляет запрос сертификата клиенту (это
## сообщение не отправляется, если опция проверки - verify_none).## Вы также можете указать опцию fail_if_no_peer_cert.
## Дополнительная информация: http://erlang.org/doc/man/ssl.html
##
## Значение: verify_peer | verify_none
## coap.dtls.verify = verify_peer

## Сертификаты CA в кодировке PEM для DTLS
##
## Значение: файл
## coap.dtls.cacertfile = {{platform_etc_dir}} / certs / cacert.pem

## Используется вместе с {verify, verify_peer} сервером SSL. Если установлено значение true,
## сервер выходит из строя, если у клиента нет сертификата для отправки, то есть
## отправляет пустой сертификат.##
## Значение: true | ложный
## coap.dtls.fail_if_no_peer_cert = false

Нагрузка emqx-coap

 ./bin/emqx_ctl плагины загрузить emqx_coap

Наблюдение за работой клиента CoAP (подписка на тему)

Чтобы подписаться на любую тему, введите следующую команду:

  GET coap: // localhost / mqtt / {topicname}? C = {clientid} & u = {username} & p = {password} с OBSERVE = 0

«mqtt» в пути обязательно.
замените {topicname}, {clientid}, {username} и {password} вашими истинными значениями.
{topicname} и {clientid} являются обязательными.
, если clientid отсутствует, будет возвращен bad_request.
{topicname} в URI должно быть закодировано в процентах, чтобы исключить использование специальных символов, таких как + и #.
{username} и {password} не являются обязательными.
, если {username} и {password} неверны, будет возвращена ошибка uauthorized.
подписана на qos1.

CoAP Client Unobserve Operation (тема отказа от подписки)

Чтобы отменить наблюдение, введите следующую команду:

  GET coap: // localhost / mqtt / {topicname}? C = {clientid} & u = {username} & p = {password} с OBSERVE = 1

«mqtt» в пути обязательно.
замените {topicname}, {clientid}, {username} и {password} вашими истинными значениями.
{topicname} и {clientid} являются обязательными.
, если clientid отсутствует, будет возвращен bad_request.
{topicname} в URI должно быть закодировано в процентах, чтобы исключить использование специальных символов, таких как + и #.
{username} и {password} не являются обязательными.
, если {username} и {password} неверны, будет возвращена ошибка uauthorized.

Операция уведомления клиента CoAP (сообщение с подпиской)

Сервер отправит уведомление о наблюдении в виде подписанного сообщения.

Его полезная нагрузка в точности совпадает с полезной нагрузкой mqtt.
— «приложение / октет-поток».

Операция публикации клиента CoAP

Выполните команду coap put для публикации. Например:

  PUT coap: // localhost / mqtt / {topicname}? C = {clientid} & u = {username} & p = {password}

«mqtt» в пути обязательно.
замените {topicname}, {clientid}, {username} и {password} вашими истинными значениями.
{topicname} и {clientid} являются обязательными.
, если clientid отсутствует, будет возвращен bad_request.
{topicname} в URI должно быть закодировано в процентах, чтобы исключить использование специальных символов, таких как + и #.
{username} и {password} не являются обязательными.
, если {username} и {password} неверны, будет возвращена ошибка uauthorized.
могут быть любые двоичные данные.
— «приложение / октет-поток».
будет отправлено с qos0.

CoAP Client Keep Alive

Устройство должно периодически выдавать команду get, служить в качестве эхо-запроса для поддержания сеанса mqtt в сети.

  GET coap: // localhost / mqtt / {any_topicname}? C = {clientid} & u = {username} & p = {password}

«mqtt» в пути обязательно.
замените {any_topicname}, {clientid}, {username} и {password} вашими истинными значениями.
{any_topicname} не является обязательным и должно быть закодировано в процентах для предотвращения использования специальных символов.
{clientid} является обязательным. Если clientid отсутствует, будет возвращен bad_request.
{username} и {password} не являются обязательными.
, если {username} и {password} неверны, будет возвращена ошибка uauthorized.
должен периодически выполнять поддержку активности, чтобы поддерживать сеанс mqtt в сети, особенно те устройства, которые находятся в сети NAT.

Примечания клиента CoAP

Шлюз

emqx-coap не принимает запросы POST и DELETE.

Темы в URI должны быть закодированы в процентах, но соответствующая опция uri_path имеет преобразование в процентное кодирование.См. RFC 7252, раздел 6.4, «Разложение URI на параметры»:

Обратите внимание, что эти правила полностью разрешают любое процентное кодирование.

Это означает, что клиент coap несет ответственность за преобразование любой кодировки percert в истинный символ при сборке пакета coap.

ClientId, имя пользователя, пароль и тема

ClientId / имя пользователя / пароль / тема в URI-адресе coap являются концепциями mqtt. То есть emqx-coap пытается уместить сообщение coap в систему mqtt, заимствуя клиент / имя пользователя / пароль / тему из mqtt.

Возможности Auth / ACL / Hook в mqtt также применимы к материалам coap. Например:

Если имя пользователя / пароль не авторизованы, клиент coap получит ошибку uauthorized.
Если имени пользователя или клиенту не разрешено публиковать определенную тему, сообщение coap будет фактически отброшено, хотя клиент coap получит подтверждение от emqx-coap.
Если сообщение coap опубликовано, ловушка message.publish также может перехватить это сообщение.

известные локации

Открытие всегда возвращается «,»

Например,

  libcoap / examples / coap-client -m get "coap: // 127.0.0.1 /. Хорошо известный / ядро "

Лицензия

Лицензия Apache, версия 2.0

Автор

EMQ X Team.

Конфигурация адаптера

CoAP :: Eclipse Hono ™

Адаптер протокола CoAP предоставляет конечные точки на основе CoAP для API телеметрии, событий и управления и управления Eclipse Hono ™ южной границы.

Адаптер реализован как приложение Spring Boot с использованием Eclipse Californium ™ для реализации обработка протокола CoAP.Его можно запустить либо прямо из командной строки, либо запустив соответствующий Из него создан образ Docker.

Адаптер поддерживает следующие стандартные варианты конфигурации:

Конфигурация службы

В следующей таблице представлен обзор переменных конфигурации и соответствующих параметров командной строки для настройки адаптера CoAP.

Переменная среды Параметр командной строки	Обязательно	По умолчанию	Описание
`HONO_APP_MAX_INSTANCES` `--hono.app.maxInstances`	нет	# Ядра ЦП	Количество экземпляров вершины для развертывания. Если не установлен, развертывается по одной вертикали на каждое ядро процессора.
`HONO_COAP_AUTHENTICATION_REQUIRED` `--hono.coap.authenticationRequired`	нет	`истина`	Если установлено значение `true` , адаптер протокола требует, чтобы устройства аутентифицировались при подключении к адаптеру.Учетные данные, предоставленные устройством, проверяются с помощью настроенной службы учетных данных. Устройства, не прошедшие аутентификацию, не могут подключаться к адаптеру.
`HONO_COAP_BIND_ADDRESS` `--hono.coap.bindAddress`	нет	`127.0.0.1`	IP-адрес сетевого интерфейса, к которому должен быть привязан защищенный порт. Подробнее см. Конфигурация порта ниже.
`HONO_COAP_CERT_PATH` `--hono.coap.certPath`	нет	–	Абсолютный путь к файлу PEM, содержащему сертификат, который адаптер протокола должен использовать для аутентификации клиентов. Эта опция должна использоваться вместе с `HONO_COAP_KEY_PATH` . В качестве альтернативы можно использовать параметр `HONO_COAP_KEY_STORE_PATH` для настройки хранилища ключей, содержащего как ключ, так и сертификат. Обратите внимание, что адаптер CoAP поддерживает только ключи на основе ECDSA.
`HONO_COAP_COAP_THREADS` `--hono.coap.coap Резьбы`	нет	2	Число потоков, используемых для обработки обмена сообщениями CoAP на уровне протокола.
`HONO_COAP_CONNECTOR_THREADS` `--hono.coap.connector Резьбы`	нет	2	Количество потоков, используемых для приема / отправки пакетов UDP. Коннектор запустит заданное количество потоков для каждого направления, как исходящего (отправка), так и входящего (получение).
`HONO_COAP_DTLS_THREADS` `--hono.coap.dtlsThreads`	нет	32	Число потоков, используемых для обработки обмена сообщениями DTLS на уровне соединения.
`HONO_COAP_DTLS_RETRANSMISSION_TIMEOUT` `--hono.coap.dtlsRetransmissionTimeout`	нет	2000	Тайм-аут в миллисекундах для повторной передачи DTLS.
`HONO_COAP_DEFAULTS_ENABLED` `--hono.coap.defaultsEnabled`	нет	`истина`	Если установлено значение `true` , адаптер протокола использует значения по умолчанию , зарегистрированные для устройства, чтобы дополнять сообщения, публикуемые устройством, с отсутствующей информацией, такой как тип содержимого. В частности, адаптер протокола добавляет значения по умолчанию, зарегистрированные для устройства как свойства (приложения) с тем же именем, в сообщения AMQP 1.0, которые он отправляет в нисходящем направлении в сеть обмена сообщениями AMQP.
`HONO_COAP_EXCHANGE_LIFETIME` `--hono.coap.exchangeLifetime`	нет	247000	Время жизни обмена в миллисекундах. Согласно RFC 7252, это значение составляет 247 с. Такое большое время требует еще и огромное количество кучи. Это время включает время обработки 100 секунд и повторные передачи сообщений CON. Следовательно, практическая ценность может быть намного меньше.
`HONO_COAP_INSECURE_NETWORK_CONFIG` `--hono.coap.insecureNetworkConfig`	нет	–	Абсолютный путь к файлу свойств Californium, содержащему свойства конфигурации сети, которые следует использовать для незащищенного порта CoAP.Если не задан, будут использоваться свойства Californium по умолчанию.
`HONO_COAP_INSECURE_PORT` `--hono.coap.insecurePort`	нет	–	Небезопасный порт, который должен прослушивать адаптер протокола. Подробнее см. Конфигурация порта ниже.
`HONO_COAP_INSECURE_PORT_BIND_ADDRESS` `--hono.coap.insecurePortBindAddress`	нет	`127,0.0,1`	IP-адрес сетевого интерфейса, к которому должен быть привязан незащищенный порт. Подробнее см. Конфигурация порта ниже.
`HONO_COAP_INSECURE_PORT_ENABLED` `--hono.coap.insecurePortEnabled`	нет	`ложный`	Если установлено значение `true` , адаптер протокола откроет незащищенный порт (не защищенный TLS), используя либо номер порта, установленный с помощью `HONO_COAP_INSECURE_PORT` , либо номер порта по умолчанию ( `5683` ), если он не установлен явно. Подробнее см. Конфигурация порта ниже.
`HONO_COAP_KEY_PATH` `--hono.coap.keyPath`	нет	–	Абсолютный путь к PEM-файлу (PKCS8), содержащему закрытый ключ, который адаптер протокола должен использовать для аутентификации клиентов. Эта опция должна использоваться вместе с `HONO_COAP_CERT_PATH` . В качестве альтернативы, параметр `HONO_COAP_KEY_STORE_PATH` может использоваться для настройки хранилища ключей, содержащего как ключ, так и сертификат.Обратите внимание, что адаптер CoAP поддерживает только ключи на основе ECDSA.
`HONO_COAP_KEY_STORE_PASSWORD` `--hono.coap.keyStorePassword`	нет	–	Пароль, необходимый для чтения содержимого хранилища ключей.
`HONO_COAP_KEY_STORE_PATH` `--hono.coap.keyStorePath`	нет	–	Абсолютный путь к хранилищу ключей Java, содержащему закрытый ключ и сертификат, которые адаптер протокола должен использовать для аутентификации клиентов.Либо этот параметр, либо параметры `HONO_COAP_KEY_PATH` и `HONO_COAP_CERT_PATH` должны быть установлены для включения защищенных соединений TLS с клиентами. Формат хранилища ключей может быть `JKS` или `PKCS12` , обозначенный суффиксом файла `.jks` или `.p12` соответственно. Обратите внимание, что адаптер CoAP поддерживает только ключи на основе ECDSA.
`HONO_COAP_MAX_CONNECTIONS` `--hono.coap.maxConnections`	нет	`0`	Максимальное количество одновременных подключений DTLS, которое должен принять адаптер протокола.Если установлено значение `0` , адаптер протокола определяет разумное значение на основе доступных ресурсов, таких как память и ЦП.
`HONO_COAP_MAX_PAYLOAD_SIZE` `--hono.coap.maxPayloadSize`	нет	`2048`	Максимально допустимый размер тела входящего запроса CoAP в байтах. Запросы с большим размером тела отклоняются с ответом 4,13 `Request entity too large` .
`HONO_COAP_MESSAGE_OFFLOADING_ENABLED` `--hono.coap.messageOffloadingEnabled`	нет	правда	Позволяет очистить полезную нагрузку и сериализованные сообщения, сохраняемые для дедупликации, чтобы уменьшить потребление кучи. Экспериментальный.
`HONO_COAP_NETWORK_CONFIG` `--hono.coap.networkConfig`	нет	–	Абсолютный путь к файлу свойств Californium, содержащему свойства конфигурации сети, которые следует использовать для защищенного порта CoAP.Если не задан, будут использоваться свойства Californium по умолчанию.
`HONO_COAP_PORT` `--hono.coap.port`	нет	–	Защищенный порт, который должен прослушивать адаптер протокола. Подробнее см. Конфигурация порта ниже.
`HONO_COAP_TENANT_IDLE_TIMEOUT` `--hono.coap.tenantIdleTimeout`	нет	`0 мс`	Продолжительность, по истечении которой адаптер протокола удаляет локальное состояние клиента (например,г. открыть ссылки AMQP) с суммой и единицей измерения, например `2ч` 2 часа. См. Документацию по Spring Boot для объяснения формата. Значение `0 мс` отключает тайм-аут.
`HONO_COAP_TIMEOUT_TO_ACK` `--hono.coap.timeoutToAck`	нет	500	Тайм-аут в миллисекундах для отправки ACK для запроса CoAP CON. Если ответ доступен до этого тайм-аута, используется более эффективный совмещенный ответ.Если время ожидания истекло без получения ответа, пустой ACK отправляется обратно клиенту, а ответ отправляется в отдельном CON, как только он становится доступным. Специальные значения: `-1` означает всегда совмещать ответ в ACK и никогда не отправлять отдельный CON; `0` означает всегда отправлять ACK немедленно и включать ответ в отдельный CON.

Переменные нужно устанавливать только в том случае, если необходимо изменить значение по умолчанию.

Конфигурация порта

Адаптер протокола CoAP можно настроить для прослушивания подключений на

только безопасный порт (по умолчанию) или
только незащищенный порт или
и безопасный, и незащищенный порт (конфигурация с двумя портами)

Адаптер протокола CoAP не запустится, если ни один из портов не настроен должным образом.

Только безопасный порт

Адаптер протокола открывает защищенный порт DTLS, если выполняется любой из следующих критериев.

Переменные среды HONO_COAP_KEY_STORE_PATH и HONO_COAP_KEY_STORE_PASSWORD устанавливаются для загрузки ключа и сертификата из защищенного паролем хранилища ключей или
переменные среды HONO_COAP_KEY_PATH и HONO_COAP_CERT_PATH устанавливаются для загрузки ключа и сертификата из двух отдельных файлов PEM в формате PKCS8 или
переменная среды HONO_COAP_PORT установлена на допустимый номер порта.

При запуске адаптер протокола привяжет защищенный DTLS сокет UDP к настроенному порту. Если порт не задан явно, используется защищенный порт 5684 CoAP по умолчанию.

Переменная HONO_COAP_BIND_ADDRESS может использоваться для указания сетевого интерфейса, на котором должен быть открыт порт. По умолчанию порт привязан только к петлевому устройству , т.е. порт будет доступен только с локального хоста. Установка этой переменной на 0.0.0.0 позволит привязать порт к всем сетевым интерфейсам (будьте осторожны, чтобы порт непреднамеренно во внешний мир).

Только незащищенный порт

Защищенный порт в основном потребуется для производственных сценариев. Однако может быть желательно вместо этого открыть порт, не защищенный DTLS, например для тестирования. В любом случае, незащищенный порт должен быть явно включен

явная установка HONO_COAP_AUTHENTICATION_REQUIRED от до false и либо
- явная установка HONO_COAP_INSECURE_PORT на действительный номер порта или
- неявно настраивает небезопасный порт CoAP по умолчанию (5683), задав для HONO_COAP_INSECURE_PORT_ENABLED значение true .

Адаптер протокола выдает предупреждение на консоли, если HONO_COAP_INSECURE_PORT установлен на безопасный порт CoAP по умолчанию (5684).

Переменная HONO_COAP_INSECURE_PORT_BIND_ADDRESS может использоваться для указания сетевого интерфейса, на котором должен быть открыт порт. По умолчанию порт привязан только к петлевому устройству , т.е. порт будет доступен только с локального хоста. Эта переменная может использоваться для e.г. открывать порт, не защищенный DTLS, только на локальном интерфейсе, тем самым обеспечивая легкий доступ изнутри в локальной сети, при этом по-прежнему требуя зашифрованной связи при доступе извне через инфраструктуру общедоступной сети.

Установка для этой переменной значения 0.0.0.0 позволит привязывать порт ко всем сетевым интерфейсам (будьте осторожны, чтобы случайно не открыть порт для внешнего мира).

Примечание
Небезопасный порт будет привязан только в том случае, если для переменной HONO_COAP_AUTHENTICATION_REQUIRED установлено значение false , поскольку CoAP аутентифицирует клиентов (устройства) как часть рукопожатия DTLS.Таким образом, требование эффективной аутентификации устройств исключает установку порта, не защищенного DTLS.
Двухпортовый
Адаптер протокола можно настроить для одновременного открытия как безопасного, так и незащищенного порта, просто настройте оба порта, как описано выше. Чтобы это работало, оба порта должны быть настроены на использование разных номеров портов, в противном случае запуск не удастся.
Временные порты
Как для защищенных, так и для незащищенных номеров портов можно явно указать 0 .Затем адаптер протокола будет использовать произвольные (неиспользуемые) номера портов, определяемые операционной системой при запуске.
Аутентификация
Протокол CoAP основан на UDP и, как таковой, использует протокол DTLS для защиты связи между клиентом (устройством). и сервер (адаптер). Адаптер CoAP также использует рукопожатие DTLS для подтверждения своей идентичности устройствам и аутентификации. сами устройства. Протокол DTLS позволяет использовать для этого различные наборы шифров .Эти апартаменты в основном отличаются друг от друга типом секрета, который используется для подтверждения идентичности участников друг другу.
Один класс пакетов основан на секрете, который совместно используется клиентом и сервером, как в Схема аутентификации на основе имени пользователя и пароля. Этот класс пакетов называется pre-shared key или PSK-based и является очень популярен для случаев использования, когда устройства очень ограничены в отношении ЦП и памяти. Другой класс шифра Наборы основаны на сертификатах, которые используют асимметричное шифрование для подтверждения владения секретом (закрытым ключом).
Адаптер CoAP поддерживает комплекты шифров из обоих классов, но поддерживает только комплекты шифров из последнего класса, которые используют Алгоритм ECDSA для аутентификации. В частности, это означает, что клиенту и / или серверу необходимо использовать Криптография на основе эллиптических кривых Ключи на основе (ECC) вместо ключей на основе RSA.
При включении безопасного порта без настройки ключа и сертификата на основе ECC адаптер будет использовать только PSK. комплекты шифров для аутентификации. При настройке ключа и сертификата на основе ECC адаптер также предложит наборы шифров на основе сертификатов для использования клиентом для аутентификации.
В любом случае учетные данные устройства должны быть зарегистрированы в реестре устройства. Пожалуйста, обратитесь к Стандартные типы учетных данных и API управления реестром устройств для получения дополнительной информации.
CoAP (протокол ограниченного приложения) по TCP, TLS и WebSockets
CoAP (протокол ограниченного приложения) по TCP, TLS и WebSockets
CoAP (протокол ограниченного приложения) через TCP, TLS и WebSockets
draft-ietf-core-coap-tcp-tls-latest
Протокол ограниченного приложения (CoAP), хотя и вдохновлен HTTP, был разработан для использования UDP вместо TCP.Уровень сообщений протокола CoAP over UDP включает поддержку надежной доставки, простое управление перегрузкой и управление потоком.
Некоторые среды выигрывают от доступности CoAP, передаваемого через надежные транспортные средства, такие как TCP или TLS. В этом документе описаны изменения, необходимые для использования транспорта CoAP через TCP, TLS и WebSockets. Он также официально обновляет RFC 7641 для использования с этими транспортами и RFC 7959, чтобы разрешить использование более крупных сообщений через надежный транспорт.
Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.
Internet-Drafts являются рабочими документами Инженерной группы Интернета (IETF). Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов находится на https://datatracker.ietf.org/drafts/current/.
Интернет-проекты — это черновики документов, срок действия которых не превышает шести месяцев, и они могут быть обновлены, заменены или отменены другими документами в любое время. Неуместно использовать Интернет-черновики в качестве справочного материала или цитировать их иначе, как «незавершенную работу».«
Срок действия этого Интернет-проекта истекает 21 июня 2018 г.
Авторские права (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
Этот документ регулируется BCP 78 и Правовыми положениями IETF Trust, касающимися документов IETF (https://trustee.ietf.org/license-info), действующими на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права и ограничения в отношении этого документа.Компоненты кода, извлеченные из этого документа, должны включать упрощенный текст лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.
Ограниченный протокол приложений (CoAP) был разработан для развертываний Интернета вещей (IoT), предполагая, что UDP [RFC0768] может использоваться беспрепятственно, как и протокол безопасности транспортного уровня дейтаграмм (DTLS [RFC6347]) поверх UDP. Использование CoAP поверх UDP нацелено на простоту, имеет небольшой объем кода и небольшой размер передаваемых по сети сообщений.
Основная причина внедрения CoAP поверх TCP [RFC0793] и TLS [RFC5246] заключается в том, что некоторые сети не пересылают пакеты UDP. Согласно [EK2016], полная блокировка UDP происходит примерно в 2–4% наземных сетей доступа. Ухудшение UDP особенно сосредоточено в корпоративных сетях и сетях в географических регионах с другими проблемами подключения. Некоторые сети также ограничивают скорость UDP-трафика, как сообщается в [BK2015], а исследования развертывания, связанные со стандартизацией QUIC, показали, что числа около 0.3% [SW2016].
Внедрение CoAP через TCP также приводит к некоторым дополнительным эффектам, которые могут быть желательны в конкретном развертывании:
Там, где NAT присутствуют на пути связи, CoAP через TCP приводит к другому поведению обхода NAT, чем CoAP через UDP. NAT часто вычисляет таймеры истечения срока действия на основе протокола транспортного уровня, используемого протоколами приложений. Многие NAT поддерживают привязки NAT на основе TCP в течение более длительных периодов времени, исходя из предположения, что протокол транспортного уровня, такой как TCP, предлагает дополнительную информацию о жизненном цикле сеанса.UDP, с другой стороны, не предоставляет такую информацию NAT, и таймауты обычно намного короче [HomeGateway]. Согласно [HomeGateway] среднее время ожидания привязки TCP и UDP к NAT составляет 386 минут (TCP) и 160 секунд (UDP). Более короткие значения тайм-аута требуют более частой отправки сообщений поддержки активности. Следовательно, использование CoAP поверх TCP требует менее частой передачи сообщений проверки активности.
TCP
использует более сложные механизмы управления перегрузкой и потоком, чем механизмы по умолчанию, предоставляемые CoAP через UDP, что полезно для передачи больших объемов данных.(Тем не менее, продолжается работа по добавлению расширенного контроля перегрузки в CoAP через UDP, см. [I-D.ietf-core-cocoa].)
Обратите внимание, что использование CoAP через UDP (и CoAP через DTLS через UDP) по-прежнему является рекомендуемым транспортом для использования в сетях с ограниченными узлами, особенно при использовании совместно с поблочной передачей. CoAP через TCP применим в тех случаях, когда сетевая инфраструктура не оставляет другого выбора. Использование CoAP поверх TCP приводит к большему размеру кода, большему количеству обходов, повышенным требованиям к ОЗУ и большим размерам пакетов.Разработчикам, реализующим CoAP через TCP, рекомендуется проконсультироваться с [I-D.gomez-lwig-tcp-constrained-node-networks] для получения рекомендаций по реализации TCP с малым объемом памяти для устройств IoT.
Стандарты
, основанные на CoAP, такие как Lightweight Machine to Machine [LWM2M], в настоящее время используют CoAP поверх UDP в качестве транспорта; добавление поддержки CoAP через TCP позволяет им решать указанные выше проблемы для конкретных развертываний и защищать инвестиции в существующие реализации и развертывания CoAP.
Хотя HTTP / 2 также потенциально может удовлетворить потребность в обходе корпоративного межсетевого экрана, такой переход с CoAP на HTTP / 2 приведет к дополнительным затратам и задержкам.В настоящее время также доступно меньше реализаций HTTP / 2 для устройств с ограничениями по сравнению с CoAP. Поскольку CoAP также поддерживает групповую связь с использованием многоадресной рассылки на уровне IP и ненадежной связи, устройства IoT должны будут поддерживать HTTP / 2 в дополнение к CoAP.
Кроме того, CoAP может быть интегрирован в веб-среду, где внешний интерфейс использует CoAP через UDP от устройств IoT к облачной инфраструктуре, а затем CoAP через TCP между внутренними службами. Шлюз TCP-UDP можно использовать на границе облака для связи с устройством IoT на основе UDP.
Наконец, приложения CoAP, работающие в веб-браузере, могут не иметь доступа к другим соединениям, кроме HTTP. В этом случае протокол WebSocket [RFC6455] может использоваться для передачи запросов и ответов CoAP, в отличие от их перекрестного проксирования через HTTP на перекрестный прокси HTTP-CoAP. Это сохраняет функциональность CoAP без перевода, в частности, механизм Observe [RFC7641].
Чтобы удовлетворить вышеупомянутые требования к развертыванию, этот документ определяет, как транспортировать CoAP через TCP, CoAP через TLS и CoAP через WebSockets.В этих случаях надежность, предлагаемая транспортным протоколом, включает функции надежности уровня сообщений, используемых для CoAP через UDP. (Обратите внимание, что как для надежного транспорта, так и для уровня сообщений CoAP через UDP, надежность предлагается для каждого транспортного узла: если задействованы прокси-серверы — см. Разделы 5.7 и 10 [RFC7252], функция надежности этого уровня не распространяется от конца до конца. -end.) Рисунок 1 иллюстрирует наслоение:
+ -------------------------------- + | Приложение | + -------------------------------- + + -------------------------------- + | Запросы / Ответы / Сигнализация | CoAP (RFC 7252) / этот документ | -------------------------------- | | Обрамление сообщений | Этот документ + -------------------------------- + | Надежный транспорт | + -------------------------------- +
Рисунок 1: Уровни CoAP по надежным транспортным средствам
Этот документ определяет, как получить доступ к ресурсам с помощью запросов и ответов CoAP по протоколам TCP, TLS и WebSocket.Это позволяет приложениям с ограниченным соединением получать сквозное соединение CoAP либо путем прямого обмена данными CoAP с сервером CoAP, доступным через соединение TCP, TLS или WebSocket, либо через посредника CoAP, который передает запросы и ответы CoAP между различными транспортными потоками, такими как между WebSockets и UDP.
Раздел 7 обновляет спецификацию «Наблюдение за ресурсами в протоколе ограниченного приложения» для использования с CoAP через надежные транспорты. [RFC7641] — это расширение протокола CoAP, которое позволяет клиентам CoAP «наблюдать» за ресурсом на сервере CoAP.(Клиент CoAP извлекает представление ресурса и регистрируется для уведомления сервера CoAP при обновлении представления.)
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и « НЕОБЯЗАТЕЛЬНО »в этом документе следует интерпретировать, как описано в [RFC2119].
Этот документ предполагает, что читатели знакомы с терминами и концепциями, которые используются в [RFC6455], [RFC7252], [RFC7641] и [RFC7959].
Термин «надежный транспорт» используется только для обозначения транспортных протоколов, таких как TCP, которые обеспечивают надежную и упорядоченную доставку потока байтов.
Блочное расширение для надежной транспортировки (BERT):

BERT расширяет [RFC7959], позволяя использовать более крупные сообщения через надежный транспорт.
BERT Опция:

Вариант Block1 или Block2, который включает значение SZX, равное 7.
Блок BERT:

Полезная нагрузка сообщения CoAP, на которое влияет опция BERT при описательном использовании (см. Раздел 2.1 из [RFC7959]).
Транспортное соединение:

Базовое надежное соединение с потоком байтов, напрямую предоставляемое TCP или косвенно через TLS или WebSockets.
Подключение:

Транспортное соединение, если явно не указано иное.
Инициатор подключения:

Одноранговый узел, открывающий транспортное соединение, т. Е. Активное средство открытия TCP, клиент TLS или клиент WebSocket.
Приемник подключения:

Одноранговый узел, который принимает транспортное соединение, открытое другим одноранговым узлом, i.е., пассивное средство открытия TCP, сервер TLS или сервер WebSocket.
Модель взаимодействия запрос / ответ CoAP через TCP такая же, как CoAP через UDP. Основные отличия заключаются в уровне сообщений. Уровень сообщений CoAP поверх UDP поддерживает дополнительную надежность, определяя четыре типа сообщений: подтверждаемые, неподтвержденные, подтверждение и сброс. Кроме того, сообщения включают идентификатор сообщения, чтобы связать подтверждения с подтверждаемыми сообщениями и для обнаружения повторяющихся сообщений.
Управление транспортными соединениями оставлено на усмотрение приложения, т. Е. Настоящая спецификация не описывает, как приложение решает открыть соединение или повторно открыть другое при наличии сбоев (или того, что оно сочло бы ошибочным). отказ, см. также раздел 5.4). В частности, инициатор соединения не обязательно должен быть клиентом первого запроса, размещенного в соединении. Некоторые реализации захотят реализовать динамическое управление подключением, подобное тому, которое описано в разделе 6 [RFC7230] для HTTP, открывая соединение, когда первый клиентский запрос готов к отправке, и повторно используя его для дальнейших сообщений на некоторое время, пока не будет сообщение отправляется в течение определенного времени, и нет ожидающих запросов (возможно, с настраиваемым временем простоя), и запускается процесс выпуска (раздел 5.5). В реализациях этого типа освобождение или прерывание соединения могут не указываться как ошибки для приложения, а могут быть просто обработаны автоматическим повторным подключением, когда необходимость снова возникает. Другие реализации могут быть основаны на сконфигурированных соединениях, которые постоянно остаются открытыми и приводят к уведомлениям системы управления о выпуске или прерывании. Протокол, определенный в настоящей спецификации, предназначен для работы с любой моделью (или другими моделями управления соединением для конкретных приложений).
Концептуально CoAP через TCP заменяет большую часть уровня сообщений CoAP через UDP механизмом кадрирования поверх байтового потока, предоставляемого TCP / TLS, передавая информацию о длине для каждого сообщения, которое на транспорте дейтаграмм предоставляется UDP / Слой дейтаграммы DTLS.
TCP обеспечивает надежную передачу сообщений, поэтому уровень сообщений CoAP поверх TCP не требуется для поддержки подтверждений или обнаружения повторяющихся сообщений. В результате поля «Тип» и «Идентификатор сообщения» больше не требуются и удаляются из формата сообщения CoAP over TCP.
Рисунок 2 иллюстрирует разницу между CoAP по UDP и CoAP по надежному транспорту. Удаленные поля Тип и Идентификатор сообщения обозначены тире.
CoAP-клиент CoAP-сервер CoAP-клиент CoAP-сервер | | | | | ВЫН [0xbc90] | | (-------) [------] | | GET / температура | | GET / температура | | (Токен 0x71) | | (Токен 0x71) | + -------------------> | + -------------------> | | | | | | ACK [0xbc90] | | (-------) [------] | | 2.05 Содержание | | 2.05 Содержание | | (Токен 0x71) | | (Токен 0x71) | | «22,5 C» | | «22,5 C» | | <------------------- + | <------------------- + | | | | CoAP через UDP CoAP через надежный транспорт
Рисунок 2: Сравнение CoAP с ненадежным и надежным транспортом
Формат сообщения CoAP, определенный в [RFC7252], как показано на рисунке 3, полагается на транспорт дейтаграмм (UDP или DTLS поверх UDP) для разделения отдельных сообщений и предоставления информации о длине.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Ver | Т | ТКЛ | Код | ID сообщения | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Токен (если есть, байты TKL) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Варианты (если есть) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть)... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 3: RFC 7252 определил формат сообщения CoAP
Формат сообщения CoAP через TCP очень похож на формат, указанный для CoAP через UDP. Отличия заключаются в следующем:
Поскольку базовое TCP-соединение обеспечивает повторную передачу и дедупликацию, нет необходимости в механизмах надежности, обеспечиваемых CoAP через UDP. Поля Тип (T) и Идентификатор сообщения в заголовке сообщения CoAP опускаются.
Поле Версия (Версия) также опускается. В отличие от формата сообщения CoAP через UDP, формат сообщения для CoAP через TCP не включает номер версии. CoAP определен в [RFC7252] с номером версии 1. В настоящее время нет известной причины для поддержки номеров версий, отличных от 1. Если согласование версий необходимо решить в будущем, тогда сообщения о возможностях и настройках (см. CSM Раздел 5.3) были специально разработаны для включения такой потенциальной функции.
В потоковом транспортном протоколе, таком как TCP, необходима форма разграничения сообщений. Для этой цели CoAP over TCP вводит поле длины с переменным размером. На рисунке 4 показан скорректированный формат сообщения CoAP с измененной структурой для фиксированного заголовка (первые 4 байта CoAP поверх заголовка UDP), который включает информацию о длине переменного размера.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Лен | ТКЛ | Увеличенная длина (если есть, по выбору Лена)... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Код | Токен (если есть, байты TKL) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Варианты (если есть) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 4: Рама CoAP для надежного транспорта
Длина (длина):
4-битовое целое число без знака.Значение от 0 до 12 включительно указывает длину сообщения в байтах, начиная с первого бита поля Параметры. Для специальных конструкций зарезервированы три значения:
13:
8-битовое целое число без знака (расширенная длина) следует за начальным байтом и указывает длину опций / полезной нагрузки минус 13.
14:
16-битовое целое число без знака (расширенная длина) в сетевом порядке байтов следует за начальным байтом и указывает длину опций / полезной нагрузки минус 269.
15:
32-битное целое число без знака (расширенная длина) в сетевом порядке байтов следует за начальным байтом и указывает длину опций / полезной нагрузки минус 65805.
Кодирование поля "Длина" моделируется после поля "Длина параметра" в параметрах CoAP (см. Раздел 3.1 [RFC7252]).
Для простоты маркер полезной нагрузки (0xFF) показан на рисунке 4; Маркер полезной нагрузки указывает начало необязательной полезной нагрузки и отсутствует для полезной нагрузки нулевой длины (см. раздел 3 [RFC7252]).(Если имеется, маркер полезной нагрузки включается в длину сообщения, которая отсчитывается от начала поля «Параметры» до конца поля «Полезная нагрузка».)
Например: сообщение CoAP, содержащее только код 2.03 с токеном 7f и без параметров или полезной нагрузки, кодируется, как показано на рисунке 5.
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 0x01 | 0x43 | 0x7f | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Len = 0 ------> 0x01 ТКЛ = 1 ___ / Код = 2.03 -> 0x43 Токен = 0x7f
Рисунок 5: Сообщение CoAP без параметров или полезной нагрузки
Семантика других полей заголовка CoAP остается неизменной.
После установления транспортного соединения каждая конечная точка ДОЛЖНА отправить сообщение о возможностях и настройках (CSM, см. Раздел 5.3) в качестве своего первого сообщения в соединении. В этом сообщении устанавливаются начальные настройки и возможности конечной точки, такие как максимальный размер сообщения или поддержка поблочных передач.Отсутствие опций в CSM указывает на то, что базовые значения предполагаются.
Чтобы избежать тупиковой ситуации, инициатор соединения НЕ ДОЛЖЕН ждать, пока принимающий соединение отправит свое начальное сообщение CSM, прежде чем отправлять свое собственное начальное сообщение CSM. И наоборот, приемник соединения МОЖЕТ дождаться, пока инициатор соединения отправит свое начальное сообщение CSM, прежде чем отправлять свое собственное начальное сообщение CSM.
Во избежание ненужной задержки инициатор соединения МОЖЕТ отправлять дополнительные сообщения после своего первоначального CSM, не дожидаясь получения CSM принимающего соединения; однако важно отметить, что CSM получателя соединения может указывать возможности, которые влияют на то, как инициатор должен взаимодействовать с принимающим устройством.Например, принимающий CSM может указать параметр максимального размера сообщения (см. Раздел 5.3.1), который меньше базового значения (1152), чтобы ограничить как требования к буферизации, так и блокировку заголовка строки.
Конечные точки ДОЛЖНЫ обрабатывать отсутствующий или недопустимый CSM как ошибку соединения и прерывать соединение (см. Раздел 5.6).
Запросы и ответы CoAP обмениваются асинхронно по транспортному соединению. Клиент CoAP может отправлять несколько запросов, не дожидаясь ответа, а сервер CoAP может возвращать ответы в любом порядке.Ответы ДОЛЖНЫ быть возвращены через то же соединение, что и исходный запрос. Параллельные запросы различаются по их токену, который привязан к локальному соединению.
Транспортное соединение является двунаправленным, поэтому запросы могут отправляться как объектом, установившим соединение (инициатор соединения), так и удаленным хостом (приемником соединения). Если на одной стороне не реализован сервер CoAP, ДОЛЖЕН быть возвращен ответ об ошибке для всех запросов CoAP с другой стороны.Самый простой подход - всегда возвращать 5.01 (не реализовано). Более сложный фиктивный сервер также может возвращать ответы 4.xx, например, 4.04 (не найдено) или 4.02 (плохой вариант), где это необходимо.
Повторная передача и дедупликация сообщений обеспечивается протоколом TCP.
Пустые сообщения (код 0.00) всегда могут быть отправлены и ДОЛЖНЫ быть проигнорированы получателем. Это обеспечивает базовую функцию проверки активности, которая может обновлять привязки NAT.
Если клиент CoAP не получает никакого ответа в течение некоторого времени после отправки запроса CoAP (или, аналогично, когда клиент наблюдает за ресурсом и не получает никаких уведомлений в течение некоторого времени), он может отправить сообщение CoAP Ping Signaling ( см. раздел 5.4), чтобы протестировать транспортное соединение и убедиться, что сервер CoAP отвечает.
Когда базовое транспортное соединение закрывается или сбрасывается, состояние сигнализации и любое состояние наблюдения (см. Раздел 7.4), связанное с соединением, удаляется. В полете сообщения могут быть потеряны, а могут и нет.
CoAP через WebSockets намеренно похож на CoAP через TCP; поэтому в этом разделе указываются только различия между транспортами.
CoAP через WebSockets можно использовать в различных конфигурациях.Самая простая конфигурация - это получение или обновление клиентом CoAP ресурса CoAP, расположенного на сервере CoAP, который предоставляет конечную точку WebSocket (см. Рисунок 6). Клиент CoAP действует как клиент WebSocket, устанавливает соединение WebSocket и отправляет запрос CoAP, на который сервер CoAP возвращает ответ CoAP. Соединение WebSocket можно использовать для любого количества запросов.
___________ ___________ | | | | | _ | ___ запросы ___ | _ | | CoAP / \ \ -------------> / / \ CoAP | | Клиент \ __ / __ / <------------- \ __ \ __ / Сервер | | | ответы | | | ___________ | | ___________ | WebSocket =============> WebSocket Сервер клиентских подключений
Рисунок 6. Клиент CoAP (клиент WebSocket) обращается к серверу CoAP (сервер WebSocket)
Проблема с этой конфигурацией состоит в том, как идентифицировать ресурс в пространстве имен сервера CoAP.Когда протокол WebSocket используется выделенным клиентом напрямую (т. Е. Не с веб-страницы через веб-браузер), клиент может подключиться к любой конечной точке WebSocket. Раздел 8.3 и Раздел 8.4 определяют новые схемы URI, которые позволяют клиенту идентифицировать как конечную точку WebSocket, так и путь и запрос ресурса CoAP в этой конечной точке.
Другая возможная конфигурация - установить прокси-сервер пересылки CoAP в конечной точке WebSocket. В зависимости от того, какие транспорты доступны прокси-серверу, он может перенаправить запрос на сервер CoAP с конечной точкой CoAP UDP (рисунок 7), конечной точкой SMS (a.к.а. мобильный телефон) или даже другую конечную точку WebSocket. Клиент CoAP указывает ресурс, который должен быть обновлен или получен в опции Proxy-Uri.
___________ ___________ ___________ | | | | | | | _ | ___ ___ | _ _ | ___ ___ | _ | | CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP | | Клиент \ __ / __ / <--- \ __ \ __ / Прокси \ __ / __ / <--- \ __ \ __ / Сервер | | | | | | | | ___________ | | ___________ | | ___________ | WebSocket ===> WebSocket UDP UDP Клиент Сервер Клиент Сервер
Рисунок 7. Клиент CoAP (клиент WebSocket) обращается к серверу CoAP (сервер UDP) через прокси CoAP (сервер WebSocket / клиент UDP)
Третья возможная конфигурация - это сервер CoAP, работающий внутри веб-браузера (рисунок 8).Веб-браузер сначала подключается к конечной точке WebSocket, а затем становится доступным через сервер WebSocket. Когда соединение отсутствует, сервер CoAP недоступен. Поскольку сервер WebSocket - единственный способ связаться с сервером CoAP, прокси-сервер CoAP должен быть обратным прокси-сервером.
___________ ___________ ___________ | | | | | | | _ | ___ ___ | _ _ | ___ ___ | _ | | CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP | | Клиент \ __ / __ / <--- \ __ \ __ / Прокси \ __ \ __ / <--- \ __ / __ / Сервер | | | | | | | | ___________ | | ___________ | | ___________ | UDP UDP WebSocket <=== WebSocket Клиент Сервер Сервер Клиент
Рисунок 8: Клиент CoAP (клиент UDP) обращается к серверу CoAP (клиент WebSocket) через прокси CoAP (сервер UDP / сервер WebSocket)
Возможны другие конфигурации, в том числе те, в которых соединение WebSocket устанавливается через прокси-сервер HTTP.
Перед обменом запросами и ответами CoAP устанавливается соединение WebSocket, как определено в разделе 4 [RFC6455]. На рисунке 9 показан пример.
Клиент WebSocket ДОЛЖЕН включить имя подпротокола «coap» в список протоколов, что указывает на поддержку протокола, определенного в этом документе.
Клиент WebSocket включает имя хоста сервера WebSocket в поле заголовка Host своего рукопожатия согласно [RFC6455]. Поле заголовка Host также указывает значение по умолчанию для параметра Uri-Host в запросах от клиента WebSocket к серверу WebSocket.
ПОЛУЧИТЬ /.well-known/coap HTTP / 1.1 Хост: example.org Обновление: websocket Подключение: Обновление Sec-WebSocket-ключ: dGhlIHNhbXBsZSBub25jZQ == Sec-WebSocket-Протокол: coap Sec-WebSocket-Версия: 13 HTTP / 1.1 101 Протоколы переключения Обновление: websocket Подключение: Обновление Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK + xOo = Sec-WebSocket-Протокол: coap
Рисунок 9: Пример начального рукопожатия
Как только соединение WebSocket установлено, запросы и ответы CoAP можно обмениваться как сообщениями WebSocket.Поскольку CoAP использует двоичный формат сообщений, сообщения передаются в двоичных кадрах данных, как указано в разделах 5 и 6 [RFC6455].
Формат сообщения, показанный на рисунке 10, такой же, как формат сообщения CoAP через TCP (см. Раздел 3.2) с одним изменением. Поле Length (Len) ДОЛЖНО быть установлено в ноль, потому что фрейм WebSockets содержит длину.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Len = 0 | ТКЛ | Код | Токен (байты TKL)... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Варианты (если есть) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть) ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Рисунок 10: Формат сообщения CoAP через WebSockets
Как и в случае с CoAP через TCP, формат сообщения для CoAP через WebSockets исключает поле версии, определенное в CoAP через UDP. Если в будущем потребуется согласование версии CoAP, CoAP через WebSockets может удовлетворить это требование путем определения нового идентификатора подпротокола, который согласовывается во время открывающего рукопожатия.
Запросы и ответные сообщения могут быть фрагментированы, как указано в разделе 5.4 [RFC6455], хотя обычно они отправляются нефрагментированными, поскольку они имеют тенденцию быть небольшими и полностью буферизоваться перед передачей. Протокол WebSocket не предоставляет средств для мультиплексирования. Если нежелательно, чтобы большое сообщение монополизировало соединение, запросы и ответы могут передаваться по блокам, как определено в [RFC7959].
Как и в случае с CoAP через TCP, каждая конечная точка ДОЛЖНА отправить сообщение о возможностях и настройках (CSM см.3) в качестве их первого сообщения при соединении WebSocket.
запросов и ответов CoAP передаются асинхронно через соединение WebSocket. Клиент CoAP может отправлять несколько запросов, не дожидаясь ответа, а сервер CoAP может возвращать ответы в любом порядке. Ответы ДОЛЖНЫ быть возвращены через то же соединение, что и исходный запрос. Параллельные запросы различаются по их токену, который привязан к локальному соединению.
Соединение является двунаправленным, поэтому запросы могут отправляться как объектом, установившим соединение, так и удаленным хостом.
Как и в случае CoAP через TCP, повторная передача и дедупликация сообщений обеспечивается протоколом WebSocket. Таким образом, CoAP через WebSockets не делает различий между подтверждаемыми и неподтверждаемыми сообщениями и не предоставляет сообщения подтверждения или сброса.
Как и в случае с CoAP через TCP, клиент CoAP может проверить работоспособность CoAP через соединение WebSocket, отправив сообщение CoAP Ping Signaling (раздел 5.4). WebSocket Ping и нежелательные фреймы Pong (Раздел 5.5 [RFC6455]) НЕ СЛЕДУЕТ использовать для предотвращения передачи избыточного трафика обслуживания.
Сигнальные сообщения специально вводятся только для CoAP через надежный транспорт, чтобы одноранговые узлы могли:
Изучите связанные характеристики, такие как максимальный размер сообщения для соединения
Завершите соединение в обычном порядке
Предоставляет диагностическую информацию при разрыве соединения в ответ на состояние серьезной ошибки
Сигнализация - это третий основной вид сообщений в CoAP после запросов и ответов.Сообщения сигнализации имеют общую структуру с существующими сообщениями CoAP. Есть код, токен, параметры и дополнительная полезная нагрузка.
(См. Раздел 3 [RFC7252] для полной структуры формата сообщения, формата опции и формата значения опции.)
Код в диапазоне 7.00-7.31 указывает на сигнальное сообщение. Значения в этом диапазоне назначаются подрегистром «Сигнальные коды CoAP» (см. Раздел 11.1).
Для каждого сообщения есть отправитель и партнер, получающие сообщение.
Полезные данные
в сообщениях сигнализации - это полезные данные диагностики, как определено в разделе 5.5.2 [RFC7252]), если иное не определено опцией сообщения сигнализации.
Номера опций для сигнальных сообщений зависят от кода сообщения. Они не разделяют пространство номеров с опциями CoAP для сообщений запроса / ответа или с сообщениями сигнализации, использующими другие коды.
Номера опций назначаются суб-реестром «Номера опций сигнализации CoAP» (см. Раздел 11.2).
Опции сигнализации являются факультативными или критическими, как определено в Разделе 5.4.1 [RFC7252]. Если опция сигнализации критична и не понятна получателю, она ДОЛЖНА прервать соединение (см. Раздел 5.6). Если опция понятна, но не может быть обработана, опция документирует поведение.
Сообщения о возможностях и настройках (CSM) используются для двух целей:
Каждая опция возможностей указывает получателю одну возможность отправителя.
Каждый вариант настройки указывает настройку, которая будет применена отправителем.
Один CSM ДОЛЖЕН быть отправлен каждой конечной точкой в начале транспортного соединения.Дальнейший CSM МОЖЕТ быть отправлен в любое другое время любой конечной точкой в течение срока службы соединения.
Возможности и параметры настройки суммируются. CSM не отменяет ранее отправленное указание или настройку возможностей, даже если они не повторяются. Сообщение о возможности без какой-либо опции - это не операция (и может использоваться как таковая). Отправленный параметр может переопределить предыдущее значение для того же параметра. Опция определяет, как поступить в этом случае, если это необходимо.
Базовые значения для параметров CSM перечислены ниже.Это значения возможностей и настроек до того, как какие-либо сообщения о возможностях и настройках отправят измененное значение.
Это не значения по умолчанию для опции, как определено в разделе 5.4.4 в [RFC7252]. Значения по умолчанию применяются для каждого сообщения и, таким образом, сбрасываются, если значение отсутствует в данном сообщении о возможностях и настройках.
Сообщения о возможностях и настройках
обозначаются кодом 7.01 (CSM).
Отправитель может использовать выборочную опцию Max-Message-Size, чтобы указать максимальный размер сообщения в байтах, которое он может получить.Указанный размер сообщения включает все сообщение, начиная с первого байта заголовка сообщения и заканчивая концом полезной нагрузки сообщения.
(Обратите внимание, что нет никакой связи между размером сообщения и общим размером тела запроса или ответа, которое может быть достигнуто при поблочной передаче. Например, обмен, изображенный ниже на рисунке 13, может быть выполнен, если клиент CoAP указывает значение около 6000 байт для параметра Max-Message-Size, даже несмотря на то, что общий размер тела, переданного клиенту, составляет 3072 + 5120 + 4711 = 12903 байта.)
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 CSM Максимальный размер сообщения uint 0-4 1152
Согласно разделу 4.6 [RFC7252], базовое значение (и значение, используемое, когда эта опция не реализована) составляет 1152.
Активное значение параметра максимального размера сообщения заменяется каждый раз, когда параметр отправляется с измененным значением. Его начальное значение - это его базовое значение.
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
4 CSM Блок-мудрая передача пустой 0 (нет)
Отправитель может использовать опцию выборочной блочной передачи, чтобы указать, что он поддерживает протокол поблочной передачи [RFC7959].
Если опция не указана, партнер не имеет информации о том, поддерживается ли блочная передача отправителем или нет. Реализация, желающая предложить своему партнеру блочную передачу, поэтому должна указать вариант блочной-мудрой-передачи.
Если параметр максимального размера сообщения указан со значением, превышающим 1152 (в том же или другом сообщении CSM), параметр блочной мудрой передачи также указывает на поддержку BERT (см. Раздел 6). Впоследствии, если параметр максимального размера сообщения указан со значением, равным или меньшим 1152, поддержка BERT больше не указывается.(Обратите внимание, что указание на поддержку BERT не обязывает ни один из партнеров фактически выбрать использование BERT.)
Примечание по реализации: при указании значения параметра Max-Message-Size с намерением включить BERT, указывающая реализация может захотеть выбрать сообщение размера BERT, которое она хочет поощрять, и добавить дельту для заголовка и любых параметров, которые также должны быть включены в сообщение. Раздел 4.6 [RFC7252] добавляет 128 байтов к максимальному размеру блока 1024, чтобы получить размер сообщения по умолчанию, равный 1152.Реализация с поддержкой BERT может захотеть указать размер блока BERT 2048 или больше, кратное 1024, и в то же время быть более щедрым для размера заголовка и добавленных опций (скажем, 256 или 512). Однако добавление 1024 или более к базовому размеру блока BERT может побудить одноранговую реализацию изменять размер блока BERT в зависимости от размера включенных опций, что может быть труднее установить для взаимодействия.
В CoAP через надежные транспорты пустые сообщения (код 0.00) всегда могут быть отправлены и ДОЛЖНЫ быть проигнорированы получателем.Это обеспечивает базовую функцию поддержания активности. Напротив, сообщения Ping и Pong являются двусторонним обменом.
При получении сообщения Ping получатель ДОЛЖЕН вернуть в ответ сообщение Pong с идентичным токеном. Если Ping не содержит опцию с семантикой задержки, например опцию Custody, он ДОЛЖЕН ответить как можно скорее. Как и все сообщения сигнализации, получатель сообщения Ping или Pong ДОЛЖЕН игнорировать необязательные параметры, которые он не понимает.
сообщений Ping и Pong обозначаются цифрой 7.Код 02 (Ping) и код 7.03 (Pong).
Обратите внимание, что, как и в случае с аналогичными механизмами, определенными в [RFC6455] и [RFC7540], настоящая спецификация не определяет какое-либо конкретное максимальное время, в течение которого отправитель сообщения Ping должен разрешить ожидание ответа Pong. Любые ограничения терпения для этого ответа зависят от приложения, использующего эти сообщения, как и любой подход к восстановлению после неспособности ответить вовремя.
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 Пинг, Понг Опека пустой 0 (нет)
При ответе на сообщение Ping получатель может включить в сообщение Pong факультативную опцию хранения.Этот параметр указывает, что приложение обработало все сообщения запроса / ответа, полученные до сообщения Ping в текущем соединении. (Обратите внимание, что нет определения конкретной семантики приложения для «обработанного», но ожидается, что получатель сообщения Pong с опцией хранения должен иметь возможность освобождать буферы на основе этого указания.)
Отправитель также может включить выборочную опцию хранения в сообщение Ping, чтобы явно запросить включение выборочной опции опеки в соответствующее сообщение Pong.В этом случае получателю СЛЕДУЕТ отложить свое сообщение Pong до тех пор, пока он не завершит обработку всех сообщений запроса / ответа, полученных до сообщения Ping в текущем соединении.
Сообщение Release указывает, что отправитель не хочет продолжать поддерживать транспортное соединение и выбирает упорядоченное завершение работы, но хочет предоставить партнеру возможность фактически начать закрытие соединения. Подробности в опциях. МОЖЕТ быть включена полезная нагрузка диагностики (см. Раздел 5.5.2 [RFC7252]).
Одноранговый узел обычно отвечает на сообщение Release, закрывая транспортное соединение. (В случае, если этого не происходит, отправитель релиза может захотеть реализовать механизм тайм-аута, если избавление от соединения действительно важно для него.)
Сообщения могут находиться в полете или ответы не могут быть получены, когда отправитель решает отправить сообщение Release (что является одной из причин, по которой отправитель решил подождать с закрытием соединения). Одноранговому узлу, отвечающему на сообщение Release, СЛЕДУЕТ отложить закрытие соединения до тех пор, пока он не ответит на все запросы, полученные им до сообщения Release.Он также МОЖЕТ ждать ответов на свои запросы.
Отправителю сообщения Release НЕ РЕКОМЕНДУЕТСЯ продолжать посылать запросы по тому соединению, которое он уже указал для освобождения: одноранговый узел может закрыть соединение в любое время и пропустить эти запросы. Однако партнер не обязан проверять это условие.
Сообщения о выпуске
обозначаются кодом 7.04 (выпуск).
Сообщения о выпуске
могут указывать на одну или несколько причин с помощью дополнительных опций.Определены следующие параметры:
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 х Выпуск Альтернативный адрес строка 1-255 (нет)
Выборочная опция альтернативного адреса запрашивает у партнера вместо этого открыть соединение по той же схеме, что и текущее соединение, с заданным альтернативным транспортным адресом.Его значение имеет форму «авторитет», как определено в разделе 3.2 [RFC3986]. (Существующее состояние, относящееся к соединению, не переносится из текущего соединения в новое соединение.)
Опция альтернативного адреса - это повторяемая опция, как определено в разделе 5.4.5 [RFC7252]. Если включено несколько экземпляров опции, одноранговый узел может выбрать любой из альтернативных транспортных адресов.
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
4 Выпуск Задержка uint 0–3 (нет)
Выборочная опция удержания указывает, что сервер запрашивает, чтобы одноранговый узел не повторно подключался к нему в течение количества секунд, указанного в значении.
Сообщение Abort указывает, что отправитель не может продолжать поддерживать транспортное соединение и даже не может дождаться упорядоченного разъединения. Отправитель завершает соединение сразу после прерывания (и может или не может дождаться сообщения Release или Abort или закрытия соединения в обратном направлении). Информационные данные диагностики (см. Раздел 5.5.2 [RFC7252]) ДОЛЖНЫ быть включены в сообщение Abort. Когда отправитель решает отправить сообщение об отмене, сообщения могут находиться в процессе отправки или не могут быть получены ответы.Обычно ожидается, что они НЕ будут обработаны.
Сообщения об отмене обозначаются кодом 7.05 (Отмена).
Сообщения об отмене могут указывать на одну или несколько причин с помощью дополнительных опций. Определен следующий вариант:
C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 Прервать Bad-CSM-Option uint 0-2 (нет)
Выборочная опция Bad-CSM-Option указывает, что отправитель не может обработать опцию CSM, идентифицированную его номером опции, например.г. когда это критично и номер опции неизвестен отправителю, или когда существует проблема параметра со значением выборной опции. СЛЕДУЕТ включать более подробную информацию в качестве диагностической полезной нагрузки.
Для CoAP через UDP сообщения, содержащие нарушения синтаксиса, обрабатываются как ошибки формата сообщения. Как описано в разделах 4.2 и 4.3 [RFC7252], такие сообщения отклоняются путем отправки соответствующего сообщения Reset или игнорирования сообщения в противном случае.
Для CoAP через надежные транспорты получатель отклоняет такие сообщения, отправляя сообщение Abort, а в противном случае игнорирует (не обрабатывает) сообщение.В этом случае для сообщения Abort не определена конкретная опция, так как подробности лучше оставить диагностической полезной нагрузке.
Пример закодированного сообщения Ping с непустым токеном показан на рисунке 11.
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 0x01 | 0xe2 | 0x42 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Len = 0 -------> 0x01 ТКЛ = 1 ___ / Код = 7.02 Пинг -> 0xe2 Токен = 0x42
Рисунок 11: Пример сообщения Ping
Закодированный пример соответствующего сообщения Pong показан на рисунке 12.
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 0x01 | 0xe3 | 0x42 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Len = 0 -------> 0x01 ТКЛ = 1 ___ / Код = 7.03 Понг -> 0xe3 Токен = 0x42
Рисунок 12: Пример сообщения Pong
Ограничения размера сообщения, определенные в разделе 4.6 CoAP [RFC7252] для предотвращения фрагментации IP, не являются необходимыми, когда CoAP используется поверх надежного транспорта. Хотя это говорит о том, что протокол блочной передачи [RFC7959] также больше не нужен, он остается применимым для ряда случаев:
большие сообщения, такие как загрузки микропрограмм, могут вызвать нежелательную блокировку заголовка линии при использовании одного транспортного соединения
шлюз UDP-TCP может просто не иметь контекста для преобразования сообщения с параметром блокировки в эквивалентный обмен без использования параметра блокировки (потребуется преобразовать весь поблочный обмен от начала до конца в один обмен)
«Блочное расширение для надежного транспорта (BERT)» расширяет блочный протокол, позволяя использовать более крупные сообщения поверх надежного транспорта.
Использование этого нового расширения сигнализируется отправкой параметров блока 1 или блока 2 с SZX == 7 («параметр BERT»). SZX == 7 - это зарезервированное значение в [RFC7959].
При использовании элемента управления опция BERT интерпретируется так же, как эквивалентная опция с SZX == 6, за исключением того, что она также указывает на возможность обработки блоков BERT. Как и в случае с базовым блочным протоколом, получателю запроса CoAP с опцией BERT в использовании управления разрешается ответить другим значением SZX, например.г. вместо этого отправить блок, отличный от BERT.
В описательном использовании параметр BERT интерпретируется так же, как эквивалентный параметр с SZX == 6, за исключением того, что полезная нагрузка также может содержать несколько блоков. Для неокончательных блоков BERT полезная нагрузка всегда кратна 1024 байтам. Для конечных блоков BERT полезная нагрузка кратна (возможно 0) 1024 байтам плюс частичный блок размером менее 1024 байтов.
Получатель неокончательного блока BERT (M = 1) концептуально разделяет полезную нагрузку на последовательность блоков размером 1024 байта и действует точно так же, как если бы он получил эту последовательность вместе с номерами блоков, начинающимися с и последовательно увеличивающимися с, номер блока, указанный в опции блокировки.Другими словами, весь блок BERT позиционируется в позиции байта, которая получается в результате умножения номера блока на 1024. Положение дополнительных блоков, подлежащих передаче, указывается путем увеличения номера блока на количество элементов в этой последовательности (т. Е. размер полезной нагрузки, деленный на 1024 байта).
Как и в случае SZX == 6, получатель последнего блока BERT (M = 0) просто добавляет полезную нагрузку в позицию байта, которая обозначена номером блока, умноженным на 1024.
Следующие примеры иллюстрируют параметры BERT. Значение SZX == 7 помечается как «BERT» или как «BERT (nnn)», чтобы указать полезную нагрузку размером nnn.
Во всех этих примерах параметр блока раскладывается, чтобы указать тип параметра блока (1 или 2), за которым следует двоеточие, номер блока (ЧИСЛО), дополнительный бит (M) и размер блока (2 ** (SZX +4)) через косую черту. Например, значение параметра Block2, равное 33, будет отображаться как 2: 2/0/32), или значение параметра Block1, равное 59, будет отображаться как 1: 3/1/128.
На рисунке 13 показан запрос GET с ответом, разделенным на три блока BERT. Первый ответ содержит 3072 байта полезной нагрузки; второй - 5120; и третий, 4711. Обратите внимание, как увеличивается номер блока, чтобы переместить позицию внутри тела ответа вперед.
CoAP-клиент CoAP-сервер | | | GET, / status ------> | | | | <------ 2.05 Контент, 2: 0/1 / BERT (3072) | | | | GET, / status, 2: 3/0 / BERT ------> | | | | <------ 2.05 Содержание, 2: 3/1 / BERT (5120) | | | | GET, / status, 2: 8/0 / BERT ------> | | | | <------ 2.05 Содержание, 2: 8/0 / BERT (4711) |
Рисунок 13: GET с блоками BERT
На рисунке 14 показан обмен PUT с блоками BERT.
CoAP-клиент CoAP-сервер | | | PUT, / options, 1: 0/1 / BERT (8192) ------> | | | | <------ 2.31 Продолжить, 1: 0/1 / BERT | | | | PUT, / options, 1: 8/1 / BERT (16384) ------> | | | | <------ 2.31 Продолжить, 1: 8/1 / BERT | | | | PUT, / options, 1: 24/0 / BERT (5683) ------> | | | | <------ 2.04 Изменено, 1: 24/0 / BERT | | |
Рисунок 14: PUT с блоками BERT
В этом разделе описывается, как процедуры, определенные в [RFC7641] для наблюдения за ресурсами через CoAP, применяются (и при необходимости изменяются) для надежного транспорта. В этом разделе «клиент» и «сервер» относятся к клиенту CoAP и серверу CoAP.
При использовании параметра наблюдения с CoAP через UDP в уведомлениях от сервера для параметра устанавливается возрастающий порядковый номер для обнаружения переупорядочения на клиенте, поскольку сообщения могут поступать в другом порядке, чем они были отправлены.Этот порядковый номер не требуется для CoAP через надежные транспорты, поскольку протокол TCP обеспечивает надежную и упорядоченную доставку сообщений. Значение параметра наблюдения в уведомлениях 2.xx МОЖЕТ быть пустым при передаче и ДОЛЖНО игнорироваться при приеме.
Примечание по реализации: это означает, что прокси-сервер от транспорта с переупорядочением к надежному (в порядке) транспорту (например, прокси-сервер UDP-TCP) должен обрабатывать параметр наблюдения в уведомлениях в соответствии с правилами в разделе 3.4 из [RFC7641].
Для CoAP через UDP серверные уведомления клиента могут быть подтверждаемыми или неподтвержденными. Подтверждаемое сообщение требует, чтобы клиент ответил либо сообщением подтверждения, либо сообщением сброса. Сообщение подтверждения указывает, что клиент активен и желает получать дальнейшие уведомления. Сообщение сброса указывает, что клиент не распознает маркер, из-за чего сервер удаляет связанную запись из списка наблюдателей.
Поскольку TCP устраняет необходимость в уровне сообщений для поддержки надежности, CoAP поверх надежных транспортов не поддерживает подтверждаемые или неподтверждаемые типы сообщений.Все уведомления надежно доставляются клиенту с положительным подтверждением получения на уровне TCP. Если клиент не распознает токен в уведомлении, он МОЖЕТ немедленно прервать соединение (см. Раздел 5.6).
Для CoAP через UDP, если клиент не получает уведомление в течение некоторого времени, он МОЖЕТ отправить новый запрос GET с тем же токеном, что и исходный запрос, чтобы повторно зарегистрировать свой интерес к ресурсу и убедиться, что сервер все еще отвечает .Для CoAP над надежными транспортными средствами более эффективно проверять работоспособность соединения (и всех его активных наблюдений), отправляя одно сообщение CoAP Ping Signaling (раздел 5.4), а не отдельные запросы для подтверждения каждого активного наблюдения. (Обратите внимание, что такой пинг / понг подтверждает только один прыжок: прокси-сервер не обязан и не ожидать, что он будет реагировать на пинг, проверяя все его последующие наблюдения или все соединения, если таковые имеются, лежащие в их основе. Прокси-сервер МОЖЕТ поддерживать свой собственный график для подтверждения будущих наблюдений, на которые он полагается; однако, как правило, прокси не рекомендуется генерировать большое количество исходящих проверок на основе одной входящей проверки.)
Для CoAP через UDP клиент, который больше не заинтересован в получении уведомлений, может «забыть» наблюдение и ответить на следующее уведомление от сервера сообщением сброса, чтобы отменить наблюдение.
Для CoAP через надежные транспорты клиент ДОЛЖЕН явно отменить регистрацию, выполнив запрос GET, в котором в поле Token установлен маркер наблюдения, которое необходимо отменить, и включается параметр наблюдения со значением, установленным на 1 (отмена регистрации).
Если клиент наблюдает за одним или несколькими ресурсами через надежный транспорт, то сервер CoAP (или посредник в роли сервера CoAP) ДОЛЖЕН удалить все записи, связанные с конечной точкой клиента, из списков наблюдателей, когда соединение закрывается или время вышло.
CoAP через UDP [RFC7252] определяет схемы URI «coap» и «coap». В этом документе представлены четыре дополнительных схемы URI для идентификации ресурсов CoAP и предоставления средств поиска ресурса:
схема URI «coap + tcp» для CoAP через TCP
схема URI «coaps + tcp» для CoAP через TCP, защищенная TLS
схема URI «coap + ws» для CoAP через WebSockets
схема URI «coaps + ws» для CoAP через WebSockets, защищенная TLS
Ресурсы, доступные через эти схемы, не имеют общего идентификатора, даже если их идентификаторы ресурсов указывают на одинаковые полномочия (один и тот же хост прослушивает один и тот же TCP-порт).Они размещены в разных пространствах имен, поскольку каждая схема URI подразумевает отдельный исходный сервер.
Синтаксис схем URI в этом разделе определяется с использованием расширенной формы Бэкуса-Наура (ABNF) [RFC5234]. Определения «host», «port», «path-abempty» и «query» взяты из [RFC3986].
Раздел 8 (Multicast CoAP) в [RFC7252] не применим к этим схемам.
Как и в случае схем «coap» и «coaps», определенных в [RFC7252], все схемы URI, определенные в этом разделе, также поддерживают префикс пути «/.well-known / », определенный в [RFC5785] для« хорошо известных местоположений »в пространстве имен хоста. Это обеспечивает обнаружение в соответствии с разделом 7 [RFC7252].
Схема URI «coap + tcp» идентифицирует ресурсы CoAP, которые предназначены для доступа с использованием CoAP через TCP.
coap-tcp-URI = "coap + tcp:" "//" хост [":" порт] path-abempty ["?" запрос ]
Синтаксис, определенный в разделе 6.1 [RFC7252], применяется к этой схеме URI со следующими изменениями:
Подкомпонент порта указывает порт TCP, на котором находится приемник подключения CoAP.(Если он пуст или не задан, предполагается, что по умолчанию используется порт 5683, как и в случае с UDP.)
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Вопросы совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].
Схема URI «coaps + tcp» идентифицирует ресурсы CoAP, которые предназначены для доступа с использованием CoAP через TCP, защищенных с помощью TLS.
coaps-tcp-URI = "coaps + tcp:" "//" хост [":" порт] path-abempty ["?" запрос ]
Синтаксис, определенный в разделе 6.2 [RFC7252], применяется к этой схеме URI со следующими изменениями:
Подкомпонент порта указывает порт TCP, на котором расположен сервер TLS для приемника соединения CoAP. Если он пуст или не задан, предполагается порт по умолчанию 5684.
Если сервер TLS не поддерживает расширение согласования протокола прикладного уровня (ALPN) [RFC7301] или желает обслуживать клиентов TLS, которые не поддерживают ALPN, он МОЖЕТ предложить конечную точку coaps + tcp на TCP-порту 5684.Эта конечная точка также МОЖЕТ быть включена ALPN. Сервер TLS МОЖЕТ предлагать конечные точки coaps + tcp на портах, отличных от TCP-порта 5684, который ДОЛЖЕН быть включен ALPN.
Для TCP-портов, отличных от порта 5684, клиент TLS ДОЛЖЕН использовать расширение ALPN для объявления идентификатора протокола «coap» (см. Раздел 11.7) в списке протоколов в своем ClientHello. Если TCP-сервер выбирает и возвращает идентификатор протокола «coap», используя расширение ALPN в своем ServerHello, то соединение устанавливается успешно. Если сервер TLS либо не согласовывает расширение ALPN, либо возвращает предупреждение no_application_protocol, клиент TLS ДОЛЖЕН закрыть соединение.
Для TCP-порта 5684 клиент TLS МОЖЕТ использовать расширение ALPN для объявления идентификатора протокола «coap» в списке протоколов в своем ClientHello. Если сервер TLS выбирает и возвращает идентификатор протокола «coap», используя расширение ALPN в своем ServerHello, то соединение устанавливается успешно. Если сервер TLS возвращает предупреждение no_application_protocol, клиент TLS ДОЛЖЕН закрыть соединение. Если сервер TLS не согласовывает расширение ALPN, неявно выбирается coaps + tcp.
Для TCP-порта 5684, если клиент TLS не использует расширение ALPN для согласования протокола, то неявно выбирается coaps + tcp.
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Вопросы совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].
Схема URI «coap + ws» определяет ресурсы CoAP, которые предназначены для доступа с использованием CoAP через WebSockets.
coap-ws-URI = "coap + ws:" "//" хост [":" порт] path-abempty ["?" запрос ]
Подкомпонент порта НЕОБЯЗАТЕЛЬНЫЙ. По умолчанию это порт 80.
Конечная точка WebSocket идентифицируется URI «ws», который состоит из авторитетной части URI «coap + ws» и хорошо известного пути «/.well-known/coap» [RFC5785] [ID.bormann- hybi-ws-wk]. Части пути и запроса URI «coap + ws» идентифицируют ресурс в указанной конечной точке, с которым можно работать с помощью методов, определенных CoAP:
coap + ws: // пример.орг / датчики / температура? u = Cel \ ______ ______ / \ ___________ ___________ / \ / \ / Uri-Path: "датчики" ws: //example.org/.well-known/coap Uri-Path: "температура" Uri-запрос: "u = Cel"
Рисунок 15. Схема URI «coap + ws»
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Вопросы совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].
Схема URI «coaps + ws» идентифицирует ресурсы CoAP, которые предназначены для доступа с использованием CoAP через WebSockets, защищенные TLS.
coaps-ws-URI = "coaps + ws:" "//" хост [":" порт] path-abempty ["?" запрос ]
Подкомпонент порта НЕОБЯЗАТЕЛЬНЫЙ. По умолчанию это порт 443.
Конечная точка WebSocket идентифицируется URI «wss», который состоит из авторитетной части URI «coaps + ws» и хорошо известного пути «/.хорошо известный / coap »[RFC5785] [I-D.bormann-hybi-ws-wk]. Части пути и запроса URI «coaps + ws» идентифицируют ресурс в указанной конечной точке, с которым можно работать с помощью методов, определенных CoAP.
coaps + ws: //example.org/sensors/temperature? u = Cel \ ______ ______ / \ ___________ ___________ / \ / \ / Uri-Path: "датчики" wss: //example.org/.well-known/coap Uri-Path: "температура" Uri-запрос: "u = Cel"
Рисунок 16. Схема URI «coaps + ws»
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Вопросы совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].
CoAP через надежный транспорт поддерживает свойство из Раздела 5.10.1 [RFC7252]:
Значения по умолчанию для параметров Uri-Host и Uri-Port достаточны для запросов к большинству серверов.
Если не указано иное, значением по умолчанию для параметра Uri-Host Option является литерал IP, представляющий IP-адрес назначения сообщения запроса.Значение по умолчанию для параметра Uri-Port - TCP-порт назначения.
Для CoAP через TLS эти значения по умолчанию одинаковы, если не согласовано указание имени сервера (SNI) [RFC6066]. В этом случае значением по умолчанию для параметра Uri-Host в запросах от клиента TLS к серверу TLS является хост SNI.
Для CoAP через WebSockets значение по умолчанию параметра Uri-Host в запросах от клиента WebSocket к серверу WebSocket указывается в поле заголовка Host в подтверждении связи WebSocket.
Шаги те же, что указаны в разделе 6.4 [RFC7252] с небольшими изменениями.
Этот шаг из [RFC7252]:
3. Если | url | не имеет компонента , значение которого, когда конвертируется в нижний регистр ASCII, принимает значение «coap» или «coaps», затем не выполняется этот алгоритм.
обновлено до:
3. Если | url | не имеет компонента , значение которого, когда преобразован в нижний регистр ASCII, это "coap + tcp", "coaps + tcp", «coap + ws» или «coaps + ws», то этот алгоритм не работает.
Этот шаг из [RFC7252]:
7. Если | порт | не совпадает с UDP-портом назначения запроса, включите параметр Uri-Port и пусть значение этого параметра будет | порт |.
обновлено до:
7. Если | порт | не совпадает с TCP-портом назначения запроса, включите параметр Uri-Port и пусть значение этого параметра будет | порт |.
Шаги такие же, как указано в разделе 6.5 [RFC7252] с небольшими изменениями.
Этот шаг из [RFC7252]:
1.Если запрос защищен с помощью DTLS, пусть | url | быть строкой «копы: //». В противном случае пусть | url | быть строкой «coap: //».
обновлено до:
1. Для CoAP через TCP, если запрос защищен с помощью TLS, пусть | url | быть строкой "coaps + tcp: //". В противном случае пусть | url | быть строкой "coap + tcp: //". Для CoAP через WebSockets, если запрос защищено с помощью TLS, пусть | url | быть строкой "coaps + ws: //". В противном случае пусть | url | быть строкой «coap + ws: //».
Этот шаг из [RFC7252]:
4.Если запрос включает параметр Uri-Port, пусть | порт | будь то стоимость опциона. В противном случае пусть | порт | быть просьбой порт назначения UDP.
обновлено до:
4. Если запрос включает параметр Uri-Port, пусть | port | будь то стоимость опциона. В противном случае пусть | порт | быть запросом TCP-порт назначения.
Security Challenges for the Internet of Things [SecurityChallenges] рекомендует:
… важно, чтобы в наборах протоколов IoT было указано обязательное для реализации, но необязательное для использования решение безопасности.Это гарантирует, что безопасность будет доступна во всех реализациях, но ее можно будет настроить для использования, когда нет необходимости (например, в закрытой среде). … Даже если эти функции расширяют возможности таких устройств.
Решение безопасности ДОЛЖНО быть реализовано для защиты CoAP через надежные транспорты и ДОЛЖНО быть включено по умолчанию. В этом документе определяется привязка TLS, но при необходимости МОГУТ использоваться альтернативные решения на разных уровнях стека протоколов для защиты CoAP через надежные транспорты.Обратите внимание, что в настоящее время ведется работа по поддержке модели безопасности на основе объектов данных для CoAP, которая не зависит от транспорта (см. [I-D.ietf-core-object-security]).
Применяется руководство по использованию TLS в [RFC7925], включая руководство по комплектам шифров в этом документе, которые получены из обязательных для реализации (MTI) комплектов шифров, определенных в [RFC7252].
Это руководство предполагает реализацию в ограниченном устройстве или для связи с ограниченным устройством. Однако CoAP через TCP / TLS имеет более широкое применение.Это может, например, быть реализовано на шлюзе или на устройстве, которое менее ограничено (например, смартфон или планшет), для связи с одноранговым узлом, который также менее ограничен, или в серверной среде, которая взаимодействует только с ограниченные устройства через прокси. В качестве исключения из предыдущего абзаца в этом случае более уместны рекомендации [RFC7525].
Поскольку рекомендации, предлагаемые в [RFC7925] и [RFC7525], различаются с точки зрения алгоритмов и типов учетных данных, предполагается, что реализация CoAP через TCP / TLS, которая должна поддерживать оба случая, реализует рекомендации, предлагаемые обеими спецификациями.
На этапе инициализации устройству CoAP предоставляется необходимая информация о безопасности, включая материалы для ключей, списки управления доступом и серверы авторизации. В конце фазы инициализации устройство будет в одном из четырех режимов безопасности:
NoSec:
TLS отключен.
PreSharedKey:
TLS включен. Применяются рекомендации в разделе 4.2 [RFC7925].
RawPublicKey:
TLS включен.Применяются рекомендации в разделе 4.3 [RFC7925].
Сертификат:
TLS включен. Применяются рекомендации в разделе 4.4 [RFC7925].
Режим «NoSec» является необязательным для реализации. Система просто отправляет пакеты по обычному TCP, на что указывает схема «coap + tcp» и порт TCP CoAP по умолчанию. Система защищена только тем, что злоумышленники не могут отправлять или получать пакеты из сети с узлами CoAP.
«PreSharedKey», «RawPublicKey» или «Certificate» являются обязательными для реализации для привязки TLS в зависимости от типа учетных данных, используемых с устройством.Эти режимы безопасности достигаются с помощью TLS и обозначаются схемой «coaps + tcp» и портом по умолчанию CoAP, защищенным TLS.
Клиент CoAP, запрашивающий ресурс, идентифицированный URI «coaps + ws», согласовывает безопасное соединение WebSocket с конечной точкой сервера WebSocket с URI «wss». Это описано в Разделе 8.4.
Клиент ДОЛЖЕН выполнить квитирование TLS после открытия соединения с сервером. Применяются рекомендации в разделе 4.1 [RFC6455]. Когда сервер CoAP предоставляет ресурсы, идентифицированные URI «coaps + ws», руководство в Разделе 4.4 [RFC7925] применяется к обязательной реализации функциональности TLS для сертификатов. В отношении требований на стороне сервера при приеме входящих подключений через порт HTTPS (HTTP-over-TLS) применяются рекомендации в разделе 4.2 [RFC6455].
Обратите внимание, что это формально наследует обязательные для реализации наборы шифров, определенные в [RFC5246]. Однако обычно современные браузеры реализуют более свежие наборы шифров, которые затем автоматически выбираются через JavaScript WebSocket API. Серверы WebSocket, которые обеспечивают Secure CoAP через WebSockets для варианта использования браузера, должны будут следовать настройкам браузера и ДОЛЖНЫ следовать [RFC7525].
Применяются соображения безопасности [RFC7252]. Для CoAP через WebSockets и CoAP через TLS-защищенные WebSockets также применяются соображения безопасности [RFC6455].
Невозможно слепо следовать указаниям опции альтернативного адреса. В частности, одноранговый узел НЕ ДОЛЖЕН предполагать, что успешное соединение с альтернативным адресом наследует все свойства безопасности текущего соединения.
IANA просят создать третий суб-реестр для значений поля кода в заголовке CoAP (раздел 12.1 из [RFC7252]). Название этого подрегистра - «Сигнальные коды CoAP».
Каждая запись в суб-реестре должна включать сигнальный код в диапазоне 7.00-7.31, его имя и ссылку на его документацию.
Первоначальные записи в этом подрегистре следующие:
Сигнальные коды CoAP
Код Имя Номер ссылки
7,01 CSM [RFCthis]
7.02 Пинг [RFCthis]
7,03 Понг [RFCthis]
7,04 Выпуск [RFCthis]
7,05 Прервать [RFCthis]
Все остальные сигнальные коды не назначены.
Политика IANA в отношении будущих дополнений к этому субреестру - «Проверка IETF или Утверждение IESG», как описано в [RFC8126].
IANA просят создать вспомогательный реестр для номеров опций, используемых в опциях сигнализации CoAP в реестре «Параметры CoRE».Имя этого подрегистра - «Номера опций сигнализации CoAP».
Каждая запись в подрегистре должна включать один или несколько кодов из подрегистра кодов сигнализации (раздел 11.1), номер опции, название опции и ссылку на документацию по опции.
Первоначальные записи в этом подрегистре следующие:
Коды опций сигнала CoAP
Относится к Число Имя Номер ссылки
7.01 2 Максимальный размер сообщения [RFCthis]
7,01 4 Блок-мудрая передача [RFCthis]
7,02, 7,03 2 Опека [RFCthis]
7,04 2 Альтернативный адрес [RFCthis]
7,04 4 Задержка [RFCthis]
7.05 2 Bad-CSM-Option [RFCthis]
Политика IANA в отношении будущих дополнений к этому субреестру основана на диапазонах номеров для номеров опций, аналогично политике, определенной в разделе 12.2 [RFC7252]. (Политика аналогична, а не идентична, потому что структура подрегистра включает дополнительный столбец; однако значение этого столбца не влияет на политику.)
В документации для номера опции сигнализации должна быть указана семантика опции с этим номером, включая следующие свойства:
Является ли вариант критическим или факультативным, в зависимости от номера варианта.
Повторяется ли опция.
Формат и длина значения опциона.
Базовое значение для опции, если таковая имеется.
IANA запрашивает назначение номера порта 5683 и имени службы «coap + tcp» в соответствии с [RFC6335].
Название службы.

coap + tcp
Транспортный протокол.

tcp
Правопреемник.

IESG
Связаться.

Председатель IETF
Описание.

Протокол ограниченного приложения (CoAP)
Ссылка.

[RFCthis]
Номер порта.

5683
IANA запрашивает назначение номера порта 5684 и имени службы «coaps + tcp» в соответствии с [RFC6335]. Номер порта запрашивается в исключительном случае реализаций TLS, которые не поддерживают «Расширение согласования протокола прикладного уровня» [RFC7301].
Название службы.

колпачки + tcp
Транспортный протокол.

tcp
Правопреемник.

IESG
Связаться.

Председатель IETF
Описание.

Протокол ограниченного приложения (CoAP)
Ссылка.

[RFC7301], [RFCthis]
Номер порта.

5684
схем URI зарегистрированы в реестре «Схемы унифицированного идентификатора ресурса (URI)», поддерживаемом в [IANA.ури-схемы].
IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coap + tcp». Этот запрос на регистрацию соответствует [RFC7595].
Название схемы:

coap + tcp
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с помощью TCP.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул

Раздел 8.1 в [RFCthis]
IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coaps + tcp». Этот запрос на регистрацию соответствует [RFC7595].
Название схемы:

колпачки + tcp
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с помощью TLS.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул

Раздел 8.2 в [RFCthis]
IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coap + ws». Этот запрос на регистрацию соответствует [RFC7595].
Название схемы:

coap + ws
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с использованием протокола WebSocket.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул

Раздел 8.3 в [RFCthis]
IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coaps + ws». Этот запрос на регистрацию соответствует [RFC7595].
Название схемы:

колпачки + WS
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с использованием протокола WebSocket, защищенного с помощью TLS.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Ссылки:

, раздел 8.4 в [RFCthis]
IANA просят зарегистрировать известный URI «coap» в реестре «Well-Known URIs». Этот запрос на регистрацию соответствует [RFC5785]:
Суффикс URI.

копка
Заменить контроллер.

IETF
Документ (ы) спецификаций.

[RFCthis]
Связанная информация.

Нет.
IANA запрошено присвоить следующее значение в реестре «Идентификаторы протокола согласования протоколов уровня приложений (ALPN)», созданном [RFC7301]. Строка «coap» идентифицирует CoAP при использовании поверх TLS.
Протокол.

CoAP
Идентификационная последовательность.

0x63 0x6f 0x61 0x70 («колпак»)
Ссылка.

[RFCthis]
IANA запрашивает регистрацию подпротокола WebSocket CoAP в «Реестре имен подпротокола WebSocket»:
Идентификатор подпротокола.

копка
Общее имя подпротокола.

Протокол ограниченного приложения (CoAP)
Определение подпротокола.

[RFCthis]
IANA просят добавить [RFCthis] к ссылкам на следующие записи, зарегистрированные [RFC7959] в подреестре «Номера вариантов CoAP», определенном в [RFC7252]:
Номера опций CoAP
Номер Имя Номер ссылки
23 Блок2 RFC 7959, [RFCthis]
27 Блок1 RFC 7959, [RFCthis]
[I-D.bormann-hybi-ws-wk] Борман, К., «Хорошо известные URI для протокола WebSocket», Internet-Draft draft-bormann-hybi-ws-wk-00, май 2017 г.
[RFC0793] Постел, Дж., "Протокол управления передачей", STD 7, RFC 793, DOI 10.17487 / RFC0793, сентябрь 1981 г.
[RFC2119] Браднер, С., «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487 / RFC2119, март 1997.
[RFC3986] Бернерс-Ли, Т., Филдинг, Р. и Л. Масинтер, «Универсальный идентификатор ресурса (URI): общий синтаксис», STD 66, RFC 3986, DOI 10.17487 / RFC3986, январь 2005 г.
[RFC5246] Диркс, Т. и Э. Рескорла, "Протокол безопасности транспортного уровня (TLS), версия 1.2", RFC 5246, DOI 10.17487 / RFC5246, август 2008 г.
[RFC5785] Ноттингем, М.и Э. Хаммер-Лахав, «Определение хорошо известных универсальных идентификаторов ресурсов (URI)», RFC 5785, DOI 10.17487 / RFC5785, апрель 2010 г.
[RFC6066] Истлейк 3-й, Д., «Расширения безопасности транспортного уровня (TLS): определения расширений», RFC 6066, DOI 10.17487 / RFC6066, январь 2011 г.
[RFC6455] И. Фетте и А. Мельников, "Протокол WebSocket", RFC 6455, DOI 10.17487 / RFC6455, декабрь 2011 г.
[RFC7252] Шелби, З., Хартке, К. и К. Борман, «Протокол ограниченного приложения (CoAP)», RFC 7252, DOI 10.17487 / RFC7252, июнь 2014 г.
[RFC7301] Фридл, С., Попов, А., Лэнгли, А. и Э. Стефан, «Расширение согласования протокола прикладного уровня безопасности транспортного уровня (TLS)», RFC 7301, DOI 10.17487 / RFC7301, июль 2014 г.
[RFC7525] Шеффер, Ю., Хольц, Р. и П. Сен-Андре, «Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)», BCP 195, RFC 7525, DOI 10.17487 / RFC7525, май 2015 г.
[RFC7595] Талер Д., Хансен Т. и Т. Харди, «Рекомендации и процедуры регистрации для схем URI», BCP 35, RFC 7595, DOI 10.17487 / RFC7595, июнь 2015 г.
[RFC7641] Хартке, К., «Наблюдение за ресурсами в протоколе ограниченного приложения (CoAP)», RFC 7641, DOI 10.17487 / RFC7641, сентябрь 2015 г.
[RFC7925] Чофениг, Х.и Т. Фоссати, «Профили безопасности транспортного уровня (TLS) / дейтаграммной безопасности транспортного уровня (DTLS) для Интернета вещей», RFC 7925, DOI 10.17487 / RFC7925, июль 2016 г.
[RFC7959] Борман, К. и З. Шелби, «Блочные передачи в протоколе с ограничениями приложений (CoAP)», RFC 7959, DOI 10.17487 / RFC7959, август 2016 г.
[RFC8126] Коттон, М., Лейба, Б. и Т. Нартен, «Рекомендации по написанию раздела о соображениях IANA в RFC», BCP 26, RFC 8126, DOI 10.17487 / RFC8126, июнь 2017 г.
[BK2015] Бирн, К. и Дж. Клеберг, «Рекомендации по развертыванию UDP», Proceedings draft-byrne-opsec-udp-advisory-00 (срок действия истек), 2015 г.
[EK2016] Эделин, К., Кюлевинд, М., Траммелл, Б., Абен, Э. и Б. Доннет, «Использование UDP для развития Интернет-транспорта», Proceedings arXiv preprint 1612.07816, 2016.
[HomeGateway] Эггерт, Л., «Экспериментальное исследование характеристик домашних шлюзов», Труды 10-й ежегодной конференции по измерению Интернета, 2010.
[I-D.gomez-lwig-tcp-ограниченные-узлы-сети] Гомес, К., Кроукрофт, Дж. И М. Шарф, «TCP через сети с ограниченными узлами», Internet-Draft draft-gomez-lwig-tcp-constrained-node-networks-03, июнь 2017 г.
[I-D.ietf-core-какао] Борман, К., Бецлер, А., Гомес, К.и И. Демиркол, «Простой контроль перегрузки CoAP / расширенный», Internet-Draft draft-ietf-core-cocoa-02, октябрь 2017 г.
[I-D.ietf-core-object-security] Селандер, Г., Матссон, Дж., Паломбини, Ф. и Л. Зейтц, «Безопасность объектов для ограниченных сред RESTful (OSCORE)», Internet-Draft draft-ietf-core-object-security-07, ноябрь 2017 г.
[схемы IANA.uri] IANA, «Схемы универсального идентификатора ресурса (URI)»
[LWM2M] Открытый мобильный альянс, Техническая спецификация "Легкие машины в машины", версия 1.0 ", февраль 2017 г.
[RFC0768] Постел, Дж., "Протокол дейтаграмм пользователя", STD 6, RFC 768, DOI 10.17487 / RFC0768, август 1980 г.
[RFC5234] Крокер Д. и П. Оверелл, «Расширенный BNF для спецификаций синтаксиса: ABNF», STD 68, RFC 5234, DOI 10.17487 / RFC5234, январь 2008 г.
[RFC6335] Коттон, М., Эггерт, Л., Тач, Дж., Вестерлунд, М. и С. Чешир, «Процедуры управления адресами Интернета (IANA) для управления реестром имени службы и номера порта транспортного протокола», BCP 165 , RFC 6335, DOI 10.17487 / RFC6335, август 2011 г.
[RFC6347] Рескорла, Э. и Н. Модадугу, «Версия 1.2 безопасности транспортного уровня дейтаграмм», RFC 6347, DOI 10.17487 / RFC6347, январь 2012 г.
[RFC7230] Филдинг, Р. и Дж. Решке, «Протокол передачи гипертекста (HTTP / 1.1): синтаксис сообщений и маршрутизация», RFC 7230, DOI 10.17487 / RFC7230, июнь 2014 г.
[RFC7540] Белше, М., Peon, R. и M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP / 2)", RFC 7540, DOI 10.17487 / RFC7540, May 2015.
[Проблемы безопасности] Полк, Т. и С. Тернер, «Проблемы безопасности для Интернета вещей», Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011.
[SW2016] Светт, И., "QUIC Deployment Experience @Google", Proceedings https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf, 2016.
В этом разделе приведены примеры первых двух конфигураций, обсуждаемых в разделе 4.
Пример процесса, которому следует клиент CoAP для извлечения представления ресурса, идентифицированного URI «coap + ws», может быть следующим. На рисунке 17 ниже подробно показан обмен сообщениями WebSocket и CoAP.
Клиент CoAP получает URI , например, из представления ресурса, которое он получил ранее.
Устанавливает соединение WebSocket с URI конечной точки, состоящим из авторитета «example.org» и известного пути «/.well-known/coap», .
Обмен сообщениями
CSM (раздел 5.3) (не показаны из-за недостатка места).
Он отправляет однокадровое замаскированное двоичное сообщение, содержащее запрос CoAP. Запрос указывает целевой ресурс с параметрами Uri-Path («датчики», «температура») и Uri-Query («u = Cel»).
Ожидает ответа от сервера.
Клиент CoAP использует соединение для дальнейших запросов, или соединение закрыто.
CoAP CoAP Клиент-сервер (WebSocket (WebSocket Клиент) Сервер) | | | | + =========> | ПОЛУЧИТЬ /.well-known/coap HTTP / 1.1 | | Хост: example.org | | Обновление: websocket | | Подключение: Обновление | | Sec-WebSocket-ключ: dGhlIHNhbXBsZSBub25jZQ == | | Sec-WebSocket-Протокол: coap | | Sec-WebSocket-Версия: 13 | | | <========= + HTTP / 1.1 101 коммутационные протоколы | | Обновление: websocket | | Подключение: Обновление | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK + xOo = | | Sec-WebSocket-Протокол: coap :: : <-------->: Обмен сообщениями CSM (не показано) | | + ---------> | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 1) | | + ------------------------- + | | | ПОЛУЧИТЬ | | | | Токен: 0x53 | | | | Uri-Path: «датчики» | | | | Ури-Путь: «температура» | | | | Uri-Query: "u = Cel" | | | + ------------------------- + | | | <--------- + Двоичный кадр (код операции =% x2, FIN = 1, MASK = 0) | | + ------------------------- + | | | 2.05 Содержание | | | | Токен: 0x53 | | | | Полезная нагрузка: «22,3 кэла» | | | + ------------------------- + :: :: + ---------> | Закрыть кадр (код операции =% x8, FIN = 1, MASK = 1) | | | <--------- + Закрыть кадр (код операции =% x8, FIN = 1, MASK = 0) | |
Рисунок 17: Клиент CoAP извлекает представление ресурса, идентифицированного URI
«coap + ws».
На рис. 18 показано, как клиент CoAP использует прокси-сервер CoAP с конечной точкой WebSocket для получения представления ресурса coap: // [2001: db8 :: 1] / .Использование прокси-сервера пересылки и адрес конечной точки WebSocket определяется клиентом из правил локальной конфигурации. URI запроса указывается в опции Proxy-Uri. Поскольку URI запроса использует схему URI «coap», прокси-сервер выполняет запрос, отправляя подтверждаемый запрос GET по UDP на сервер CoAP и возвращая ответ клиенту через соединение WebSocket.
CoAP CoAP CoAP Клиентский прокси-сервер (WebSocket (WebSocket (UDP Клиент) Сервер) Конечная точка) | | | + ---------> | | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 1) | | | + ------------------------------------ + | | | | ПОЛУЧИТЬ | | | | | Токен: 0x7d | | | | | Proxy-Uri: "coap: // [2001: db8 :: 1] /" | | | | + ------------------------------------ + | | | | + ---------> | Сообщение CoAP (Ver = 1, T = Con, MID = 0x8f54) | | | + ------------------------------------ + | | | | ПОЛУЧИТЬ | | | | | Токен: 0x0a15 | | | | + ------------------------------------ + | | | | | <--------- + сообщение CoAP (Ver = 1, T = Ack, MID = 0x8f54) | | | + ------------------------------------ + | | | | 2.05 Содержание | | | | | Токен: 0x0a15 | | | | | Полезная нагрузка: «готово» | | | | + ------------------------------------ + | | | | <--------- + | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 0) | | | + ------------------------------------ + | | | | 2.05 Содержание | | | | | Токен: 0x7d | | | | | Полезная нагрузка: «готово» | | | | + ------------------------------------ + | | |
Рисунок 18: Клиент CoAP извлекает представление ресурса, идентифицированного URI «coap», через прокси CoAP с поддержкой WebSocket
Редактору RFC предлагается удалить этот раздел при публикации.
Объединенный draft-savolainen-core-coap-websockets-07 Объединенный draft-bormann-core-block-bert-01 Объединенный draft-bormann-core-coap-sig-02
Редакционные обновления
Добавлен обязательный обмен сообщениями Возможности и Настройки после подключения
Добавлена поддержка coaps + tcp порт 5684 и более подробная информация о согласовании протокола уровня приложений (ALPN)
Добавлено руководство по пинг-понгу с сигнализацией CoAP по сравнению с WebSocket Ping-Pong
Обновленные ссылки и требования к соображениям безопасности TLS
Обновленные ссылки
Добавлено приложение: обновления к RFC7641, наблюдая за ресурсами в протоколе с ограничениями (CoAP)
Обновлен обмен сообщениями о возможностях и настройках (CSM) в открывающем рукопожатии, чтобы инициатор мог отправлять сообщения до получения CSM-получателя
Адресованный отзыв от последнего звонка рабочей группы
Добавлен раздел "Обеспечение безопасности CoAP" и информативная ссылка на OSCOAP
.
Удалены параметры Server-Name и Bad-Server-Name
Разъяснен обмен сообщениями о возможностях и настройках (CSM)
Обновленные требования к ответу Pong
Добавлена терминология инициатора и приемника соединения, где это необходимо.
Обновлен LWM2M 1.0 информативная ссылка
Адресованный отзыв от второй рабочей группы Последний звонок
Адресованный отзыв от IETF Last Call
Адресованный отзыв из обзора ARTART
Адресованный отзыв из обзора GENART
Адресованный отзыв из обзора TSVART
Добавлены идентификаторы фрагментов в схемы URI
Добавлены «Обновления RFC7959» для BERT
.
Добавлены «Обновления RFC6455» для расширения известного механизма URI на ws и wss
.
Уточнено использование известного механизма URI для всех схем URI
Заменен NoSec на дополнительный для реализации
Мы хотели бы поблагодарить Стивена Берара, Джеффри Кристалло, Оливье Делаби, Эско Дейк, Кристиана Гровса, Надира Джаведа, Майкла Костера, Матиаса Ковач, Ахима Крауса, Дэвида Наварро, Шимона Сасина, Горана Селандера, Зака Шелби, Эндрю Саммерса, Джулиена Вермилларда. и Gengyu Wei за их отзывы.
Обзоры последнего звонка от Йошифуми Нисида, Марка Ноттингема и Мерала Ширазипура, а также нескольких рецензентов IESG предоставили подробные комментарии; из IESG мы хотели бы особо выделить Бена Кэмпбелла, Мирью Кюлевинд, Эрика Рескорла, Адама Роуча и ответственного AD Алексея Мельникова.
Маттиас Ковач Siemens AG Отто-Хан-Ринг 6 Мюнхен D-81739 Телефон: + 49-173-5288856 Электронная почта: [email protected] Теему Саволайнен Nokia Technologies Hatanpaan valtatie 30 Тампере FI-33100 Финляндия Электронная почта: [email protected] Валик Солорзано Барбоза Зебра Технологии 820 W. Jackson Blvd. Люкс 700 Чикаго 60607 Соединенные Штаты Америки Телефон: + 1-847-634-6700 Электронная почта: [email protected]
Карстен Борман Борман Университет Бремена TZI Постфах 330440 Бремен, D-28359 Германия Телефон: + 49-421-218-63921 Электронная почта: [email protected]

Саймон Лемей Lemay Зебра Технологии 820 W. Jackson Blvd. Люкс 700 Чикаго, 60607 Соединенные Штаты Америки Телефон: + 1-847-634-6700 Электронная почта: slemay @ zebra.ком

Клаус Хартке Хартке Университет Бремена TZI Постфах 330440 Бремен, D-28359 Германия Телефон: + 49-421-218-63905 Электронная почта: [email protected]

Билханан Сильвераджан Сильвераджан Технологический университет Тампере Korkeakoulunkatu 10 Тампере, FI-33720 Финляндия Электронная почта: [email protected]
шаблонов привязки Web of Things (WoT)
шаблонов привязки Web of Things (WoT)
Абстрактные
W3C Web of Вещи позволяют приложениям взаимодействовать и управлять подключенные вещи в веб-масштабе.Стандартизированный реферат модель взаимодействия, представленная описанием вещи WoT, позволяет приложения масштабироваться и развиваться независимо от отдельные вещи.
Многие протоколы и стандарты сетевого уровня для подключенных Вещи уже разработаны и имеют миллионы устройств, развернутых сегодня в полевых условиях. Эти стандарты сходящиеся на общем наборе транспортных протоколов и передачи слоев, но каждый из них имеет свои форматы контента, схемы полезной нагрузки, и типы данных.
Несмотря на использование уникальных форматов и моделей данных, высокоуровневый можно смоделировать взаимодействия, проявляемые большинством связанных вещей использование возможностей взаимодействия Свойство, Действие и Событие Описание WoT Thing.
Шаблоны привязки
позволяют адаптировать Описание вещи к конкретному протоколу или использованию полезной нагрузки данных через разные стандарты. Это делается с помощью дополнительных описательный словарь, который используется в Вещи Описание.
Этот документ описывает начальный набор словарного запаса расширения к описанию вещей WoT, которые составляют Шаблоны привязки. Ожидается, что со временем дополнительные протоколы и структуры полезной нагрузки будут адаптированы дальнейшее расширение шаблонов привязки.
Статус этого документа
В этом разделе описывается статус этого документа на время его публикации. Другие документы могут заменять это документ.Список текущих публикаций W3C и последнюю версию этого технического отчета можно найти в W3C технические отчеты индекс на https://www.w3.org/TR/.
Примечание редактора: W3C WoT WG просит оставить отзыв
Пожалуйста, внесите свой вклад в этот черновик, используя GitHub Проблема с привязкой WoT Хранилище шаблонов. Для отзывов о безопасности и соображения конфиденциальности, пожалуйста, используйте WoT Security и Вопросы конфиденциальности, поскольку они затрагивают все наши документы.
Этот документ был опубликован Рабочей группой Web of Things как Примечание Рабочей группы.
Комментарии относительно этого документа приветствуются. Пожалуйста, отправьте их на [email protected] (архивы).
Публикация в качестве примечания рабочей группы не подразумевает одобрения по W3C Членство. Это черновик документа, который может быть обновлен, заменены или устарели другими документами в любое время. это неуместно цитировать этот документ, кроме работы в прогресс.
Этот документ был подготовлен группой действует в соответствии с Патентной политикой W3C .
Данный документ регулируется 1 марта 2019 г. W3C Процесс Документ.
Таблица Содержание
1. Введение
1.1 Методы и параметры протокола
1,2 Типы носителей
1.3 Структура полезной нагрузки
1.4 Типы данных и ограничения значений
2. Соответствие
3. Терминология
4. Обзор шаблонов привязки
4,1 Схема данных
4.1.1 Структура полезной нагрузки
4.1.2 Типы данных и значение ограничения
4.1.3 Привязка схемы XML
4.1.3.1 Определение объекта в XML Схема
4.1.3.2 Схема массива в XML Схема
4.2 Элемент Forms
4.2.1 Типы операций
4.2.2 Типы контента
4.2.3 Методы протокола и Опции
4.2.4 URI Переменные шаблона
4.3 Возможности взаимодействия
4.3.1 Привязки для свойств
4.3.2 Привязки для действий
4.3.3 Привязки для событий
4,4 Модель обработки и время выполнения
5. Словарь
5,1 DataSchema Словарь
5.2 Форма Операция Тип Словарь
5.2.1 Формы собственности
5.2.2 Формы действий
5.2.3 Формы событий
5.3 Словарь протокола
5.3.1 Словарь HTTP
5.3.1.1 Словарь терминов HTTP
5.3.1.2 Словарь HTTP по умолчанию Условия
5.3.2 Словарь CoAP
5.3.2.1 Словарь терминов CoAP
5.3.2.2 Словарь по умолчанию для CoAP Условия
5.3.3 Словарь MQTT
5.3.3.1 Словарь терминов MQTT
5.3.3.2 Словарь по умолчанию MQTT Условия
5.3.4 подпротокол Словарный запас
6. Примеры описаний вещей, включая привязки протокола
7. Вопросы безопасности и конфиденциальности
А. Примерные последовательности возможностей взаимодействия
A.1 Взаимодействие с собственностью
A.1.1 Свойство чтения (HTTP привязка)
A.1.2 Свойство записи (HTTP привязка)
A.1.3 Соблюдать свойство (Привязка HTTP с подпротоколом длинного опроса)
А.1.4 Соблюдать свойство (Связывание HTTP с событием, отправленным сервером подпротокол)
A.1.5 Соблюдать свойство (Связывание HTTP с подпротоколом WebSocket)
A.2 Действие Взаимодействия
A.2.1 Вызов действия (HTTP привязка)
А.3 События взаимодействия
A.3.1 Подписаться, уведомить и событие отмены подписки (HTTP-привязка с Long Подпротокол опроса)
A.3.2 Подписаться, уведомить и событие отказа от подписки (HTTP-привязка к серверу Подпротокол отправленного события)
А.3.3 Подписаться, уведомить и событие отмены подписки (привязка HTTP с WebSocket подпротокол)
B. Благодарности
C. Список литературы
C.1 Нормативные ссылки
C.2 Информативные ссылки
1. Введение
Шаблоны привязки состоят из многоразового словаря и расширения к описанию WoT Thing [ WOT-THING-DESCRIPTION ] формат, позволяющий клиенту приложения (потребителю) взаимодействовать, используя последовательную модель взаимодействия, с вещами которые раскрывают различные протоколы и их использование.
Шаблоны привязки
позволяют потребителям адаптироваться к базовый протокол и сетевые API-конструкции. Один раз базовый протокол (например,г., HTTP [ RFC7231 ], CoAP [ RFC7252 ], MQTT [ MQTT ] и т. Д.) определены, следующие адаптации определяют конкретное использование в рамках данной платформы.
Примечание редактора: Дополнительные привязки протокола
Этот документ содержит примеры протокола Привязки для HTTP, CoAP и MQTT. Другие протоколы могут быть добавлен в том же стиле дизайна и с использованием полезной нагрузки сопоставления, которые могут быть выражены как объекты, совместимые с JSON.Будущие расширения для других форматов определения полезной нагрузки: также обдумал.
1,1 Методы и параметры протокола
Большинство протоколов имеют относительно небольшой набор методов, которые определить тип сообщения, семантическое намерение сообщение. Шаблоны архитектуры REST и PubSub приводят к разные протоколы разными методами. Общие методы в этих протоколах можно найти GET, PUT, POST, DELETE, PUBLISH, и ПОДПИСАТЬСЯ.Шаблоны привязки описывают, как эти существующие методы и словари могут быть описаны в Вещи Описание.
Это делается путем сопоставления методов протокола с абстрактные условия доступа к взаимодействию с WoT свойство чтения , свойство записи , Соблюдайте собственность , Соблюдайте собственность , invokeaction , subscribeevent , отписался от события , прочитать все свойства , написать все свойства , читатьмножественные свойства , запись множественных свойств .
Возможные варианты протокола также указаны в Связывание протокола. Они используются для выбора режимов передачи, чтобы запрашивать уведомления из наблюдаемых ресурсов или иным образом расширить семантику методов протокола.
1,2 СМИ Типы
Следует максимально использовать типы носителей, зарегистрированные IANA. [ IANA-MEDIA-TYPES ] (например, application / json ), чтобы разъединить приложения из подключенных вещей.Стандартные мосты и переводы из частных форматов в удобные для Интернета такие языки, как JSON и XML, являются частью адаптации нужный.
Правильная индикация типов носителей позволяет обработка сериализованных документов. Таким образом, документы можно обменивать в любом формате и разрешить верхний слои приложения для адаптации к различным форматам.
1,3 Структура полезной нагрузки
Данные, сериализованные в стандартный тип носителя, все еще остаются в структура, специфичная для модели данных платформы и нуждающаяся в быть понятыми Потребителями (ср.различные типы JSON документы).
Язык определения данных DataSchema элементы, описанные в [ WOT-THING-DESCRIPTION ], позволяет описывать произвольные структуры вложением массивы и объекты. Спецификации констант и переменных могут смешиваться.
1,4 Типы данных и ограничения значений
В настоящее время используются простые типы данных и ограничения значений многоуровневым и описательным способом в [ WOT-THING-DESCRIPTION ].Доступны дополнительные формы ограничений, помогающие адаптироваться к базовым типам данных. Платформо-зависимая 8-битная например, целое число без знака может быть определено как целое число с минимумом 0 и максимумом 255; специфический для системы представление (например, точное количество битов) на Вещи и Потребитель не имеет отношения к интероперабельности.
2. Соответствие
Кроме разделов, помеченных как ненормативные, все авторские руководящие принципы, диаграммы, примеры и примечания в этой спецификации являются ненормативными.Все остальное в этой спецификации нормативный.
Ключевые слова ДОЛЖНЫ , НЕ ДОЛЖНЫ , ДОЛЖНЫ и НЕ ДОЛЖЕН быть в этом документе интерпретируется, как описано в BCP 14 [ RFC2119 ] [ RFC8174 ] когда и только когда они появляются заглавными буквами, как показано здесь.
3. Терминология
Этот раздел не является нормативным.
Основная терминология WoT, такая как Thing , Consumer , Thing Description ( TD ), Взаимодействие Модель , Взаимодействие Affordance , Имущество , Действие , Событие , Протокол Привязка , Servient , Интерфейс WoT , WoT Runtime и т. Д.определено в разделе 3 спецификации архитектуры WoT [ WOT-ARCHITECTURE ].
Кроме того, данная спецификация вводит следующие определения:
TD Контекст Добавочный номер
Механизм расширения Thing Описания с дополнительным словарем Условия использования @context , как указано в JSON-LD [ json-ld11 ]. Это основа для семантические аннотации и расширения основных механизмов, таких как как привязки протоколов, схемы безопасности и схемы данных.
Словарь
Сборник словарных терминов, идентифицируется пространством имен IRI.
Срок и Словарь терминов
Строка символов. Когда Срок является частью Словарь, то есть с префиксом пространства имен IRI [ RFC3987 ], это называется термином словарного запаса. Для ради удобочитаемости Словарь терминов присутствующие в этом документе всегда записываются в компактном форма, а не как полные IRI.
4. Обзор шаблонов привязки
Этот раздел не является нормативным.
В этом разделе описаны механизмы привязки шаблонов с примерами.
4,1 Данные Схема
Схема данных описывает структуру полезной нагрузки и включает элементы данных, которые передаются между Потребителем и Вещью во время взаимодействия.
4.1.1 Структура полезной нагрузки
Структура полезной нагрузки определяется DataSchema элементов описания вещи.Элементы DataSchema должны использоваться экземпляром PropertyAffordance , г. вход / выход из ActionAffordance , г. данные / подписка / отмена EventAffordance или uri Переменная из Взаимодействие . Как указано в [ WOT-THING-DESCRIPTION ], DataSchema Словарь - это подмножество JSON Схема [ json-schema ]
В случае наличия акций дополнительные ключевые слова вход и выход используется для предоставления двух разных схем, когда данные могут быть обмен в обоих направлениях, например, в случае вызов возможности действия с входными параметрами и получение информации о статусе.
В случае возможности проведения мероприятий дополнительные ключевые слова данные , подписка и Отмена используются для описания полезной нагрузки когда данные о событии доставляются Exposed Thing, полезная нагрузка, необходимая для подписки на событие и полезная нагрузка необходимо отменить получение данных о событии от Exposed Вещь соответственно.
В дополнение к образцу образца в [ WOT-THING-DESCRIPTION ] объекта с конструкциями имя / значение или простыми массивами, Привязки протоколов для существующих стандартов могут потребовать вложенных массивы и объекты, а некоторые постоянные значения должны быть указано.
Ниже приведены примеры различных полезных нагрузок и их соответствующий DataSchema .
Например, простая структура полезной нагрузки может использовать карта:
{ «уровень»: 50, «время»: 10 }
Пример 2 : DataSchema для простого JSON Полезная нагрузка объекта
{ "тип": "объект", "характеристики": { "уровень": { "@type": ["iot: LevelData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 }, "время": { "@type": ["iot: TransitionTimeData"], "тип": "целое число", «минимум»: 0, «максимум»: 65535 } } }
SenML может использовать следующую конструкцию:
[ { «бн»: «/ пример / свет /» }, { «n»: «уровень», "v": 50 }, { «n»: «время», "v": 10 } ]
{ "тип": "массив", "Предметы": [ { "тип": "объект", "характеристики": { "bn": { "тип": "строка", "const": "пример / свет" } } }, { "тип": "объект", "характеристики": { "n": { "тип": "строка", "const": "уровень" }, "v": { "@type": ["iot: LevelData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 } } }, { "тип": "объект", "характеристики": { "n": { "тип": "строка", "const": "время" }, "v": { "@type": ["iot: TransitionTimeData"], "тип": "целое число", «минимум»: 0, «максимум»: 65535 } } } ] }
Пакетный сбор в соответствии с OCF может быть структурирован как это:
[ { "href": "/ пример / свет / уровень", "rep": { «затемнение»: 50 } }, { "href": "/ пример / свет / время", "rep": { "ramptime": 10 } } ]
{ "тип": "массив", "Предметы": [ { "тип": "объект", "характеристики": { "href": { "тип": "строка", «const»: «/ пример / свет / уровень» }, "rep": { "тип": "объект", "характеристики": { "затемнение": { "@type": ["iot: LevelData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 } } } } }, { "тип": "объект", "характеристики": { "href": { "тип": "строка", «const»: «/ пример / свет / время» }, "rep": { "тип": "объект", "характеристики": { "ramptime": { "@type": ["iot: TransitionTimeData"], "тип": "целое число", «минимум»: 0, «максимум»: 65535 } } } } } ] }
И смарт-объект IPSO на LWM2M может выглядеть как следующий:
{ "bn": "/ 3001/0 /", "е": [ { «n»: «5044», «v»: 0.5 }, { «n»: «5002», «v»: 10,0 } ] }
{ "тип": "объект", "характеристики": { "bn": { "тип": "строка", "const": "/ 3001/0 /" }, "e": { "тип": "массив", "Предметы": [ { "тип": "объект", "характеристики": { "n": { "тип": "строка", "const": "5044" }, "v": { "@type": ["iot: LevelData"], "тип": "число", «минимум»: 0.0, «максимум»: 1.0 } } }, { "тип": "объект", "Характеристики": { "n": { "тип": "строка", "const": "5002" }, "v": { "@type": ["iot: TransitionTimeData"], "тип": "число", «минимум»: 0,0, «максимум»: 6553,5 } } } ] } } }
4.1.2 Типы данных и значение ограничения
Обратите внимание, что в примере 7 выше значения плавающие. точка ( двойной ), в то время как в других примерах целочисленные значения. В общем, потребители должны следовать схемы данных строго, не генерируя ничего, что не указано в Описание вещи WoT, но следует принять дополнительные данные из Вещи, не указанные явно в Вещи WoT Описание. Это означает, что Потребитель, отправляющий полезную нагрузку в Примере 7 следует использовать числа с плавающей запятой в полезная нагрузка.
4.1.3 Привязка схемы XML В В предыдущих разделах на примерах было показано, какие данные, чьи значение описывается с помощью схемы данных, выглядит так, когда сериализован в JSON. В этом разделе описывается, как набирать определения, описанные с помощью схемы данных, могут быть сопоставлены в определения схемы XML, используя те же примеры. Данный эти схемы данных, обеспечивая отображение на схему XML позволяет инструментам XML напрямую проверять сериализованные данные XML, Например.Структура XML, для которой это отображение разработан на основе EXI4JSON [exi-for-json].
4.1.3.1 Определение объекта в XML Схема Ниже показана пример схемы данных схемы объекта. Предмет состоит из двух именованных литералов id (типа целое число ) и имя (типа строка ), где id требуется для присутствовать. Пример 9 : Описание схемы JSON требуемого JSON Объект
{ "тип": "объект", "характеристики": { "я бы": { "тип": "целое число" }, "название": { "тип": "строка" } }, "обязательный": [ "я бы" ] }
Когда объект является анонимным (т.е.е. Это является корнем или участвует в массиве определение), приведенное выше определение объекта преобразуется в следующий элемент схемы XML определение. Пример 10 : сопоставление схемы XML вышеуказанного Схема JSON с анонимным объектом

В противном случае (т.е. объект является членом определения другого объекта , таким образом, имеет имя), определение объекта преобразуется в следующее Определение элемента схемы XML. Примечание $ имя представляет имя объекта и требует быть заменено фактическим названием объект . Пример 11 : сопоставление схемы XML вышеуказанного Схема JSON с неанонимным объектом

4.1.3.2 Схема массива в схему XML Ниже показан пример схемы данных схемы массива. В массив состоит ровно из трех чисел литералы с каждым значением в диапазоне значений [0 ... 2047]. Пример 12 : Описание схемы JSON для требуется массив JSON
{ "тип": "массив", "Предметы": { "тип": "число", «минимум»: 0, «максимум»: 2047 }, "minItems": 3, "maxItems": 3 }
Когда массив является анонимным (т.е.е. Это является корнем или участвует в другом массив определение), указанное выше Массив Определение преобразуется в следующее Определение элемента схемы XML. Пример 13 : сопоставление схемы XML вышеуказанного Схема JSON с анонимным массивом

В противном случае (т.е. массив является членом определения объекта , таким образом, имеет имя), определение массива преобразуется в следующее определение элемента схемы XML. Примечание $ name представляет имя массив , и его необходимо заменить на Фактическое имя массива . Пример 14 : сопоставление схемы XML вышеуказанного Схема JSON с неанонимным массивом

4.2 Элемент формы
Элементы формы содержат URI [ RFC3986 ] указывая на пример взаимодействия и описания настроек протокола и опций, которые предполагается использовать при между Потребителем и Вещью для взаимодействия.
4.2.1 Типы операций Типы операций формы
описывают предполагаемую семантику выполнение операции, описанной в форме.
Например, взаимодействие "Свойство" позволяет читать и операции записи.Привязка протокола может содержать форму для операции чтения и другой формы для записи операция. Значение атрибута op для форма указывает, какая форма есть, и позволяет Потребитель выбирает правильную форму для операции обязательный.
"op": "readproperty" "op": "writeproperty"
Словарь в разделе 4 перечисляет рекомендуемый набор формы, а также полные примеры TD в разделе 5 содержат примеры использования типов операций с формами.
4.2.2 Типы содержимого Типы содержимого
определяют детали сериализации и другие правила обработки полезной нагрузки. Тип контента используется для выбора сериализатора / десериализатора и для выбора дополнительный набор правил и ограничений для протокола Водитель. Тип контента включает в себя тип медиа и потенциал параметры для типа носителя.
Например, тип носителя application / ocf + cbor указывает, что CBOR используется сериализация, но также правила OCF и пространства имен применяются к обработке представления.
Некоторые драйверы специальных протоколов могут быть вызваны с помощью незарегистрированный тип носителя (например, x- ) вместе с настраиваемым URI Схема [ RFC3986 ] и собственный набор методов и опций протокола, определенных для эта схема URI.
Если тип носителя - application / xml (или его двоичное представление application / exi ) и для полезной нагрузки предусмотрена схема данных, полезные данные ограничены схемой XML, полученной из Схема данных.См. § 3.1.3 Схема XML Связывание схемы Связывание для получения схемы XML из определения схемы данных.
Ниже приведены несколько примеров полезных данных в формате JSON и их соответствующие эквивалентные полезные данные в XML.
Пример 16 : Полезная нагрузка JSON типа Object для указания желаемого яркость и частота мигания лампы
{ «яркость»: 200, "частота": "быстро" }
Пример 17 : Соответствующие полезные данные XML для предыдущего JSON Полезная нагрузка
<объект> 200 <частота> быстро
Пример 18 : JSON Payload типа Array для указания желаемого яркость и частота мигания лампы
[ 520, г. 184, г. 1314 ]
Пример 19 : Соответствующие полезные данные XML для предыдущего JSON Полезная нагрузка
<массив> 520 184 1314
4.2.3 Методы и параметры протокола
Каждый целевой протокол может указывать разные имена методов. для аналогичных операций, и может быть семантическая различия между похожими именами методов разных протоколы. Кроме того, платформы могут использовать разные методы реализации конкретного взаимодействия WoT Доступность. Например, POST может использоваться для написания Стоимость свойства на одной платформе, в то время как PUT может использоваться в Другой.По этим причинам нам требуется способность укажите, какой метод использовать для конкретного взаимодействия. Мы также предоставим словарный запас, чтобы различать методы разных протоколов.
W3C Словарь RDF для HTTP [ HTTP-in-RDF10 ] используется для определения методов и опций, указанных в Привязки протокола HTTP.
Для единообразия мы будем использовать то же шаблон проектирования онтологии, чтобы получить словарь для каждого целевой протокол, e.г. CoAP, MQTT.
В приведенном ниже примере показаны некоторые определения методов для различные протоколы.
"htv: methodName": "GET" "mqv: controlPacketValue": "ПОДПИСАТЬСЯ" "cov: methodName": "GET"
Параметры заголовка в HTTP, CoAP, MQTT иногда должны быть включен в привязку протокола, чтобы успешно взаимодействовать с базовым протоколом. Пример ниже показывает структуру определения HTTP-заголовка параметры, согласно W3C HTTP Словарь в RDF.
Примечание: разные формы в переплете могут нуждаться в разных конструкции заголовков, поэтому htv: headers Конструкция является расширением Элемент "формы" ТД.
Протоколы могут иметь определенные подпротоколы, которые могут быть используется для некоторых типов взаимодействия. Например, чтобы получить асинхронные уведомления с использованием HTTP, некоторые серверы могут поддержка длинного опроса ( longpoll ), WebSub [ WebSub ] ( websub ) и события, отправленные сервером [ html ] (также известный как EventSource; sse ).Элемент подпротокола может быть определенным в экземпляре формы, чтобы указать на использование одного из эти протоколы, например длинный опрос с его особыми использование HTTP:
{ "op": "subscribeevent", "href": "https://mylamp.example.com/overheating", «субпротокол»: «длинный опрос» }
4.2.4 Переменные шаблона URI
Когда возможности взаимодействия требуют динамических переменных в href их можно описать с помощью uriVariables в схеме данных взаимодействие.Например, p и d в http://192.168.1.25/left?p=2&d=1 может быть описано с помощью шаблона, как определено в [ RFC6570 ]]: http://192.168.1.25/left{?p,d} .
В таком случае переменные шаблона URI ДОЛЖНЫ быть собраны в Элемент uriVariables на основе JSON-объекта с связанные (уникальные) имена переменных в виде имен JSON.
Сериализация каждого значения на карте, присвоенного uriVariables в экземпляре Форма ДОЛЖНА полагаться на DataSchema, как описано в § 3.1 Схема данных.
Фрагмент аффорданса действия с использованием шаблона URI и uriVariables приведено ниже:
Пример 23 : Доступность действий с использованием переменных шаблона URI
... "действия": { "LeftDown": { ... "uriVariables": { "p": {"тип": "целое число", "минимум": 0, "максимум": 16}, «d»: {«тип»: «целое число», «минимум»: 0, «максимум»: 1} }, "формы": [{ «href»: «http: // 192.168.1.25 / слева {? P, d} ", "htv: methodName": "GET" }] }, ... }, ...
4,3 Возможности взаимодействия
Этот раздел не является нормативным.
В этом разделе описаны уникальные аспекты привязки протоколов. для трех возможностей взаимодействия с WoT.
4.3.1 Привязки для свойств
В этом разделе описаны уникальные аспекты протокола. привязки для взаимодействия WoT Property.
Абстрактные операции, представленные для свойства Взаимодействие readproperty , свойство записи , свойство наблюдения и unobserveproperty . Они отображаются используя операции формы, которые описывают, как абстрактный операция выполняется, в результате чего семантический интерпретация аналогична отправке HTML-формы.
Кроме того, абстрактные операции, представленные для несколько взаимодействий свойств прочитать все свойства , написать все свойства , читать несколько свойств и запись множественных свойств .
Пример 24 : Пример использования операции формы для свойства
{ "op": "свойство записи", "href": "/ пример / уровень", "htv: methodName": "POST" }
Элемент формы в приведенном выше примере передает заявление: "Чтобы сделать , напишите свойство из Свойство субъекта (контекст формы), выполните HTTP POST на ресурсе по целевому URI / пример / уровень ."
Свойства могут быть наблюдаемыми, определяемыми ключевым словом TD "наблюдаемый". Если есть форма наблюдения и извлечение форма, форма наблюдения может быть обозначена включением op = соблюдайте свойство в форме. Наблюдать форма также может указывать параметры заголовка для использования, как указано в наблюдении в CoAP [ RFC7641 ] для пример установки параметра CoAP Observe на 0 в шапке запускает наблюдение.
4.3.2 Привязки для действий
Этот раздел не является нормативным.
В этом разделе описаны уникальные аспекты протокола. привязки для действий.
Абстрактная операция над Действиями invokeaction . Точно так же, как абстрактные операции со свойствами отображаются с использованием формы типы операций, абстрактная операция Действия также нанесен на карту.
Пример 25 : Пример использование операции формы для действия
{ "op": "invokeaction", "href": "/ пример / levelaction", "http: methodName": "POST" }
Элемент формы в приведенном выше примере передает оператор: "Чтобы выполнить invokeaction из субъект Действие (контекст формы), выполнить POST на ресурсе по целевому URI / пример / уровень ."
4.3.3 Привязки для событий
Этот раздел не является нормативным.
В этом разделе описаны уникальные аспекты протокола. привязки для возможностей взаимодействия с событиями WoT.
Абстрактные операции над событиями: подписаться на событие и отписался от подписки . В subscribeevent операция может напрямую включать доставка экземпляра события из предварительно определенного URI в наблюдаемые ресурсы или темы pubsub, закодированные в URI.В качестве альтернативы он может вернуть URI местоположения или ресурса. из какого экземпляра события можно получить, либо наблюдение или какой-либо другой механизм, в зависимости от протокол передачи.
Обычно происходит только отказ от подписки , событие когда протокол передачи не имеет неявной отписки такая операция, как закрытие соединения. Примеры Веб-перехватчики, требующие определенных запросов на отказ от подписки.
Если привязка предлагает наблюдаемый ресурс события из какие события получены, будет форма, которая описывает требуемую операцию уровня передачи, для пример CoAP Observe или HTTP Long Polling.
Пример 26 : Пример использование операции формы для событий
{ "op": "subscribeevent", "href": "mqtt: //wot.example.com/levelevent", "mqv: controlPacketValue": "ПОДПИСАТЬСЯ" }
Элемент формы в приведенном выше примере передает заявление: "Чтобы подписаться на событие Тема Событие (контекст формы), выполнить MQTT ПОДПИСАТЬСЯ на на тему / levelevent на брокер по адресу wot.example.com с использованием порт MQTT по умолчанию. "
4,4 Модель обработки и время выполнения
Этот раздел не является нормативным.
В этом разделе описана модель обработки для протокола Привязки к абстрактным взаимодействиям WoT предоставляется Scripting API.
DataSchema элементов (см. § 3.1 Схема данных ) обрабатываются, и значение масштабирование выполняется в библиотеке приложения или слой адаптации.
Элементы формы, которые определяют href, метод, параметры и contentType обрабатываются в контексте драйвера, который изолирован от приложения.
Приложение или уровень адаптации протокола, создает экземпляр соответствующего элемента DataSchema и отправляет его вместе с выбранным содержимым формы в драйвер протокола или, в случае получения, получает полезную нагрузку формирует драйвер протокола и использует соответствующий DataSchema элемент для извлечения значений поля представляет интерес.
Разделение контекста выполнения между приложение и драйвер протокола позволяют изолировать домены сбоя и изоляция доменов безопасности.
Примечание редактора: Множественные привязки безопасности
Дополнительная информация в описании вещи может считаться частью обязательного протокола, относящегося к протоколы безопасности. В настоящее время существует единственная декларация привязок безопасности для каждого экземпляра TD, без определенных способ указать разные протоколы безопасности для каждой формы элемент, который может указывать на другую передачу протокол.
Привязки протокола могут использоваться прокси-серверами, где Потребляемый Вещь имеет привязку к протоколу и соответствующий Exposed Вещь может иметь другую привязку к протоколу.
5. Словарь
В этом разделе обобщается словарь, используемый для привязки Шаблоны. Словарь определен в других документах, в в частности Описание WoT Thing [ WOT-THING-DESCRIPTION ]
5,1 DataSchema Словарь
DataSchema элементы описывают структуру полезная нагрузка. DataSchema класс и словарь определено в [ WOT-THING-DESCRIPTION ]. Свойства и события напрямую реализуют DataSchema класс (т.е. они содержат соответствующие поля, такие как типа ), которые описывает передачу данных в любом направлении. Действия могут определить входную схему данных для данных срабатывания отправляется в действие и / или выводит данные схема для данных результата или состояния, возвращаемых из Действие.
5.2 Форма Операция Тип Словарь
С каждым аффордансом взаимодействия связана операция формы типы (например, op ), которые используются для выбора формы элемент, соответствующий предполагаемому взаимодействию с Массив форм. Например, для одного взаимодействия Потребитель можно выбрать элемент формы, соответствующий чтению Собственность, наблюдая за Собственностью или записывая в Собственность используя тип операции формы.
5.2.1 Формы собственности
Properties может предоставлять readproperty и writeproperty операций, которые отображаются в GET и PUT / POST REST API соответственно. Недвижимость также может соблюдается, если они обеспечивают Observiceproperty работу и наблюдение можно остановить, если собственность предоставляет ненаблюдаемую собственность операция.
op Срок Описание
readproperty Прочитать недвижимость.Требуется Только запись должно быть установлено значение false .
свойство записи Написать недвижимость. Требуется Только чтение должно быть установлено значение false .
Наблюдать за недвижимостью Наблюдать за недвижимостью. Требует наблюдаемый должен быть установлен на правда .
ненаблюдаемая собственность Скрыть собственность.Требует наблюдаемый должен быть установлен на правда .
5.2.2 Формы действия
Действия обеспечивают только вызов операции. Для полноты картины также есть форма определен тип операции.
op Срок Описание
invokeaction Вызов действия.
5.2.3 Формы событий
События описывают конечные точки подписки, с которых экземпляры событий можно получить и отписаться конечные точки, чтобы перестать получать экземпляры событий.
op Срок Описание
подписка событие Подписаться на событие.
отписатьсявент Отписаться от события.
5,3 Словарь протокола
Расширения базового словаря Thing Description могут информировать Потребителя о сообщении, специфичном для протокола конфигурации, такие как методы, параметры и коды состояния. По используя такую информацию, Потребитель может построить протокол конкретный запрос, который позволяет взаимодействовать с Разоблаченными Предмет.По умолчанию описание вещи включает HTTP Словарь, включая определения словаря HTTP RDF из словаря HTTP в RDF 1.0 [HTTP-in-RDF10].
Примечание редактора: Словарные определения протоколов
Рабочая группа WoT расследует хорошие способы также предоставить словарь COAP и MQTT в RDF. Будет ли РГ публиковать соответствующие примечания РГ, еще не известно. подлежит обсуждению.
Словари протоколов для каждого протокола представлены в виде двух таблиц на протокол. Детали первой таблицы термины словаря, тогда как второй перечисляет значения по умолчанию отображение op для данного протокола, если что значение op определено для данного протокола.
5.3.1 HTTP Словарь
5.3.1.1 Словарь терминов HTTP
Словарный термин Описание Переуступка Тип
htv: methodName Имя метода HTTP (литерал). опционально строка
(один из "GET" , г. «ПОСТ» , «ПОСТ» , г. «УДАЛИТЬ» , «ПАТЧ» )
htv: заголовки HTTP-заголовков, отправленных с сообщением. опционально массив htv: MessageHeader
htv: fieldName Название заголовка (буквальное), e.г., «Принять» , г. "Кодирование передачи" . обязательно в пределах htv: MessageHeader строка
htv: fieldValue Значение заголовка (литерал). обязательно в пределах htv: MessageHeader строка
5.3.1.2 Словарь HTTP по умолчанию Условия
op значение Привязка по умолчанию
readproperty "htv: methodName": "GET"
свойство записи "htv: methodName": "PUT"
invokeaction "htv: methodName": "POST"
прочитать все свойства "htv: methodName": "GET"
записьвсе свойства "htv: methodName": "PUT"
читатьмножественные свойства "htv: methodName": "GET"
запись множественных свойств "htv: methodName": "PUT"
5.3.2 Словарь CoAP
5.3.2.1 Словарь терминов CoAP
Словарный термин Описание Переуступка Тип
cov: methodName Название метода CoAP (буквальное). опционально строка
(один из "GET" (1), «ПОСТ» (2), «ПОСТ» (3), «УДАЛИТЬ» (4), «ПОЛУЧИТЬ» (5), "НАШИВКА" (6), «iPATCH» (7))
cov: опции опции CoAP, отправленные с сообщением, e.г., [{"cov: optionName": "Принять", "cov: optionValue": 110}] для наблюдения. опционально массив cov: MessageOption
cov: optionName Название опции (Literal), см. Параметры CoRE. обязательно в пределах cov: MessageOption строка
cov: optionValue Значение заголовка (литерал). обязательно в пределах cov: MessageOption любой Тип
5.3.2.2 Словарь по умолчанию для CoAP Условия
op значение Привязка по умолчанию
readproperty "cov: methodName": "GET"
свойство записи "cov: methodName": "PUT"
Наблюдать за недвижимостью "cov: methodName": «GET», «подпротокол»: «cov: наблюдать»
ненаблюдаемая собственность "cov: methodName": «GET», «подпротокол»: «cov: наблюдать»
invokeaction "cov: methodName": "POST"
подписатьсявент "cov: methodName": «GET», «подпротокол»: «cov: наблюдать»
отписатьсявент "cov: methodName": «GET», «подпротокол»: «cov: наблюдать»
прочитать все свойства "cov: methodName": "GET"
записьвсе свойства "cov: methodName": "PUT"
читатьмножественные свойства "cov: methodName": "GET"
запись множественных свойств "cov: methodName": "PUT"
Наблюдение за ресурсами в CoAP должно выполняться как указано в [ RFC7641 ].Поскольку наблюдение и ненаблюдение необходимо обозначать флаг Observe в заголовке, этот механизм также может быть описан в cov: варианты со значением [{"cov: optionName": "Наблюдать", "cov: optionValue": 0 }]. Однако этого недостаточно, чтобы описать механизм получения асинхронных обновлений от наблюдаемых ресурс. Таким образом, "subprotocol": "cov: Observation" - это используется для обозначения механизма наблюдения.
Примечание редактора
Как указано в CoAP Словарь терминов по умолчанию, рекомендуется использовать подпротокол для описания наблюдения. Таким образом, cov: options со значением [{ «cov: optionName»: «Наблюдать», «cov: optionValue»: 0 }] ДОЛЖЕН НЕ использовать вместе с «подпротокол»: «cov: наблюдать» , поскольку он может привести к путанице.
5.3.3 Словарь MQTT
5.3.3.1 Словарь терминов MQTT
Словарный термин Описание Переуступка Тип
mqv: controlPacketValue Тип пакета управления MQTT (буквальный). опционально строка
(одна из "ПУБЛИКАЦИЯ" (3), «ПОДПИСАТЬСЯ» (8), «ОТПРАВИТЬСЯ» (10))
кв.м .: варианты параметры MQTT, отправленные с сообщением, e.г., [{"mqv: optionName": "qos", «mqv: optionValue»: 1}]. опционально массив mqv: MessageOption
mqv: optionName Имя параметра (буквальное). обязательно в пределах mqv: MessageOption ) строка
(один из "qos" , "сохранить" , "дублировать" )
mqv: optionValue Значение заголовка (литерал). обязательно в пределах mqv: MessageOption ) Один из 0 , 1 или 2 (только для qos )
5.3.3.2 Словарь по умолчанию MQTT Условия
op значение Привязка по умолчанию
readproperty "mqv: controlPacketValue": «ПОДПИСАТЬСЯ»,
свойство записи "mqv: controlPacketValue": «ПУБЛИКАЦИЯ»
Наблюдать за недвижимостью "mqv: controlPacketValue": «ПОДПИСАТЬСЯ»
ненаблюдаемая собственность "mqv: controlPacketValue": «ОТПИСАТЬСЯ»
invokeaction "mqv: controlPacketValue": «ПУБЛИКАЦИЯ»
подписатьсявент "mqv: controlPacketValue": «ПОДПИСАТЬСЯ»
отписатьсявент "mqv: controlPacketValue": «ОТПРАВИТЬСЯ»
прочитать все свойства "mqv: controlPacketValue": «ПОДПИСАТЬСЯ»
записьвсе свойства "mqv: controlPacketValue": «ПУБЛИКАЦИЯ»
читатьмножественные свойства "mqv: controlPacketValue": «ПОДПИСАТЬСЯ»
запись множественных свойств "mqv: controlPacketValue": «ПУБЛИКАЦИЯ»
Для протокола MQTT, если клиент MQTT публикует сообщение в теме с установленным флагом сохранения верно, будущие подписчики темы также будут получить это сообщение.Вне этого случая это не можно прочитать свойство, но можно только наблюдать Это. Кроме того, в элементе формы с протоколом MQTT, если op содержит readproperty (это означает, что флаг сохранения установлен в значение true), ДОЛЖЕН также содержать Собственность . С другой стороны, если Издатель MQTT не устанавливает для флага сохранения значение true, собственность будет только наблюдаема.В этом случае свойство в раскрытом описании вещи НЕ ДОЛЖНО иметь форму . элементы с протоколом MQTT, содержащие readproperty операция.
5.3.4 подпротокол Словарь
Поле подпротокола определено в [ WOT-THING-DESCRIPTION ].
В настоящее время поддерживаются следующие значения: longpoll , websub и sse определен для HTTP.Подпротоколы могут использоваться для асинхронной доставки событий или наблюдения Характеристики.
Для WebSockets - зарегистрированный IANA Websocket. Подпротоколы [ iana-web-socket-registry ] может быть использовано.
Для CoAP, «подпротокол»: «cov: наблюдать» может использоваться для описания асинхронных операций наблюдения как определено [ RFC6741 ]
6. Примеры описаний вещей включая привязки протокола
Этот раздел не является нормативным.
В следующих примерах TD используются вымышленные CoAP и MQTT. Привязки протоколов, поскольку такие привязки протоколов недоступны по адресу время написания данной спецификации. Эти TD Расширения контекста предполагают, что в Словарь RDF похож на [ HTTP-in-RDF10 ], то есть доступный через пространство имен http://www.example.org/coap-binding# и http://www.example.org/mqtt-binding# , соответственно. Дополненный cov : methodName член указывает Потребителю, какой метод CoAP должен быть применяется (e.g., GET для кода метода CoAP 0,01, POST для кода метода CoAP 0,02, или iPATCH для кода метода CoAP 0,07). В добавлен член "mqv: controlPacketValue" указывает Потребителю, какую команду MQTT нужно применить (например, 8 для подписки и 10 для отписки).
Можно увидеть TD с простым форматом полезной нагрузки и протоколами ниже. Здесь каждое аффорданс взаимодействия имеет одну форму с одним протокол.
{ "@context": [ "https://www.w3.org/2019/wot/td/v1", { "iot": "http://iotschema.org/", "cov": "http://www.example.org/coap-binding#" «mqv»: «http://www.example.org/mqtt-binding#» } ], «@type»: [«Вещь», «iot: Light», «iot: LevelCapability», «iot: BinarySwitchCapability»], "base": "http://example.com", "title": "Лампа", "id": "urn: dev: ops: 32473-WoTLamp-1234", "securityDefinitions": {"basic_sc": { «схема»: «базовая», "в": "заголовок" }}, "безопасность": ["basic_sc"], "характеристики": { "switchState": { "@type": ["iot: SwitchStatus", "iot: SwitchData"], "тип": "логическое", "writeOnly": ложь, "readOnly": ложь, "наблюдаемый": ложь, "формы": [ { "href": "/ пример / свет / токовый переключатель", «op»: [«свойство чтения», «свойство записи»], "contentType": "application / json" } ] }, "яркость": { "@type": ["iot: CurrentLevel", "iot: LevelData"], "тип": "число", "writeOnly": ложь, "readOnly": ложь, "наблюдаемый": ложь, "формы": [ { "href": "coap: // example.com / example / light / currentdimmer ", «op»: [«свойство чтения», «свойство записи»], "contentType": "application / json" } ] } }, "действия": { "включить": { "@type": ["iot: SwitchOnAction"], "Вход": { "тип": "логическое", "const": истина }, "формы": [ { "href": "/ пример / свет / токовый переключатель", "op": ["invokeaction"], "contentType": "application / json" } ] }, "выключить": { "@type": ["iot: SwitchOff"], "Вход": { "тип": "логическое", "const": ложь }, "формы": [ { "href": "/ пример / свет / токовый переключатель", "op": ["invokeaction"], "contentType": "application / json" } ] }, "setBrightness": { "@type": ["iot: SetLevelAction"], "Вход": { "@type": ["iot: LevelData"], "тип": "число" }, "формы": [ { "href": "/ example / light / currentdimmer", "op": ["invokeaction"], "contentType": "application / json" } ] } } }
Еще одна версия предыдущего ТД со сложной грузоподъемностью и несколько вариантов протокола показаны ниже.Примечательно, что яркость свойство можно прочитать через HTTP, записать через CoAP и наблюдаются через MQTT.
Пример 28 : TD с параметры протокола и сложная полезная нагрузка
{ "@context": [ "https://www.w3.org/2019/wot/td/v1", { "iot": "http://iotschema.org/", "cov": "http://www.example.org/coap-binding#" «mqv»: «http://www.example.org/mqtt-binding#» } ], "base": "http: // example.com / ", "@type": ["Thing", "iot: Light", "iot: LevelCapability", "iot: BinarySwitch"], "title": "Лампа", "id": "urn: dev: ops: 32473-WoTLamp-1234", "securityDefinitions": {"basic_sc": { «схема»: «базовая», "в": "заголовок" }}, "безопасность": ["basic_sc"], "характеристики": { "switchState": { "@type": ["iot: SwitchStatus"], "тип": "объект", "характеристики": { "выключатель": { "@type": ["iot: SwitchData"], "тип": "логическое" } }, "writeOnly": ложь, "readOnly": ложь, "наблюдаемый": правда, "формы": [ { "href": "/ пример / свет / токовый переключатель", "contentType": "application / json", "op": ["readproperty"], "htv: methodName": "GET" }, { "href": "/ пример / свет / токовый переключатель", "contentType": "application / json", "op": ["writeproperty"], "htv: methodName": "POST" }, { "href": "mqtt: // пример.com / example / light / currentswitch ", "op": ["наблюдать свойство"], "mqv: controlPacketValue": "ПОДПИСАТЬСЯ" } ] }, "яркость": { "@type": ["iot: CurrentLevel"], "тип": "объект", "характеристики": { "яркость": { "@type": ["iot: LevelData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 } }, "writeOnly": ложь, "readOnly": ложь, "наблюдаемый": правда, "формы": [ { "href": "coap: // example.com / example / light / currentdimmer ", "contentType": "application / json", "op": ["readproperty"], "cov: methodName": "GET" }, { "href": "/ example / light / currentdimmer", "contentType": "application / json", "op": ["writeproperty"], "htv: methodName": "POST" }, { "href": "mqtt: //example.com/example/light/currentdimmer", "op": ["наблюдать свойство"], "mqv: controlPacketValue": "ПОДПИСАТЬСЯ" } ] }, "transitionTime": { "@type": ["iot: TransitionTime"], "тип": "объект", "характеристики": { "transitionTime": { "@type": ["iot: TransitionTimeData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 } }, "writeOnly": ложь, "readOnly": ложь, "наблюдаемый": ложь, "формы": [ { "href": "/ example / light / transitiontime", "contentType": "application / json", "op": ["readproperty"], "htv: methodName": "GET" }, { "href": "/ example / light / transitiontime", "contentType": "application / json", "op": ["writeproperty"], "htv: methodName": "POST" } ] } }, "действия": { "включить": { "@type": ["iot: SwitchOnAction"], "Вход": { "тип": "объект", "характеристики": { "тип": "логическое", "const": истина } }, "формы": [ { "href": "/ пример / свет / токовый переключатель", "contentType": "application / json", "op": ["invokeaction"], "htv: methodName": "POST" } ] }, "выключить": { "@type": ["iot: SwitchOffAction"], "Вход": { "тип": "логическое", "const": ложь } }, "формы": [ { "href": "/ пример / свет / токовый переключатель", "contentType": "application / json", "op": ["invokeaction"], "htv: methodName": "POST" } ] }, "setBrightness": { "title": "Установить уровень яркости", "@type": ["iot: SetLevelAction"], "Вход": { "тип": "объект", "характеристики": { "яркость": { "@type": ["iot: LevelData"], "тип": "целое число", «минимум»: 0, «максимум»: 255 } }, "transitionTime": { "@type": ["iot: TransitionTimeData"], "тип": "целое число", «минимум»: 0, «максимум»: 65535 } }, "формы": [ { "href": "/ пример / свет /", "contentType": "application / json", "op": ["invokeaction"], "htv: methodName": "POST" } ] } } }
7. Вопросы безопасности и конфиденциальности
Примечание редактора
Вопросы безопасности и конфиденциальности остаются в силе. в стадии обсуждения и разработки; содержание ниже должно быть считается предварительным. Из-за сложности темы мы рассматриваем возможность создания отдельного документа, содержащего подробное обсуждение вопросов безопасности и конфиденциальности включая анализ рисков, модель угроз, рекомендуется смягчения последствий и соответствующие ссылки на передовой опыт.А резюме будет включено здесь. Незавершенные работы находятся в WoT Репозиторий безопасности и конфиденциальности. Пожалуйста, подайте любую безопасность или соображения конфиденциальности и / или проблемы с использованием проблемы GitHub особенность.
Безопасность - это сквозная проблема, которую необходимо решать во всех строительных блоках WoT. W3C WoT не определяет никаких новые механизмы безопасности, но содержит рекомендации по применению лучшие практики из области веб-безопасности, безопасности Интернета вещей и информации безопасность для общих требований к программному и аппаратному обеспечению.
Описание WoT Thing должно использоваться вместе с честностью. механизмы защиты и политики контроля доступа. Пользователи должны убедитесь, что конфиденциальная информация не включена в Сами ТД.
Шаблоны привязки WoT должны правильно покрывать безопасность механизмы, используемые базовыми Платформа Интернета вещей. За счет автоматизации сетевых взаимодействий необходимо в IoT, операторы должны гарантировать, что Вещи выставляются и потребляются в соответствии с требованиями со своими политиками безопасности.
Реализация WoT Runtime для WoT Scripting API должен иметь механизмы для предотвращения вредоносных доступ к системе и изоляция скриптов в мультитенанте Слуги.
A. Пример последовательности взаимодействия Возможности
Этот раздел не является нормативным.
В этом разделе показаны примеры последовательностей применения и протокольные транзакции, соответствующие операциям (определено в Спецификации описания вещи), реализующих различные взаимодействия между WoT Consumer и WoT Things.В иллюстрации показывают как конкретные транзакции протокола, так и взаимодействия между приложениями, работающими внутри WoT Consumer и WoT Thing, и Consumer Thing, и разоблачение Вещь абстракций.
Для простоты удаленные и локальные прокси между Потребитель и Вещь опускаются из следующих последовательности. Мы также предполагаем HTTP как конкретный протокол и исключить любые дополнительные транзакции для реализации безопасности, например, те, которые будут использоваться для аутентификации или для установки до безопасного соединения для HTTPS.Другие конкретные протоколы и однако добавление операций с ценными бумагами повлияет только на конкретные транзакции протокола, а не уровень приложения взаимодействие с Потребляемым и Открытым абстракции.
A.1 Взаимодействие свойств
A.1.1 Свойство чтения (привязка HTTP)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации readproperty работа с протоколом HTTP привязка.
A.1.2 Свойство записи (HTTP-привязка)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации writeproperty работа с протоколом HTTP привязка.
A.1.3 Соблюдать свойство (HTTP связывание с подпротоколом Long Polling)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации наблюдать свойство работа с HTTP привязка протокола с использованием "longpolling" (длинный опрос) подпротокол.
A.1.4 Соблюдать свойство (HTTP привязка к подпротоколу Server Sent Event)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации наблюдать свойство работа с HTTP привязка протокола с использованием "sse" (событие, отправленное сервером) подпротокол.
A.1.5 Соблюдать свойство (HTTP привязка к подпротоколу WebSocket)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации наблюдать свойство работа с HTTP привязка протокола с использованием подпротокола на основе WebSocket.
А.2 Действие взаимодействия
A.2.1 Вызов действия (привязка HTTP)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации invokeaction операция с протоколом HTTP привязка, где операция синхронна, а ответ от сервера откладывается до окончания действия завершает.
А.3 Взаимодействия событий
Обратите внимание, что здесь нет явной операции определяется для самого уведомления о событии. Используемый подпротокол для уведомления связано с подписаться на событие операции и любые необходимые конкретные транзакции протокола управляются протоколом Подсистема привязки.
Также возможны несколько подпротоколов для событий уведомление с помощью WebSockets. Диаграммы взаимодействия показывают только одна из нескольких возможных реализаций.
A.3.1 Подписка, уведомление и событие отмены подписки (HTTP-привязка с длинным опросом подпротокол)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации подписаться на событие и отписаться по событию операций с HTTP привязка протокола с использованием подпротокола длинного опроса.
A.3.2 Подписка, уведомление и событие отмены подписки (привязка HTTP к событию отправки сервером подпротокол)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации подписаться на событие и отписаться по событию операций с HTTP привязка протокола с использованием события, отправленного сервером подпротокол.
A.3.3 Подписка, уведомление и событие отмены подписки (HTTP-привязка с WebSocket подпротокол)
Следующая последовательность иллюстрирует применение и сетевые транзакции для реализации подписаться на событие и отписаться по событию операций с HTTP привязка протокола с использованием подпротокола WebSocket.
Б. Благодарности
Особая благодарность всем активным участникам W3C Web of Things Interest Group и Working Group за их технические вклад и предложения, которые привели к улучшению этого документ.
С. Список литературы
C.1 Нормативные ссылки
[IANA-MEDIA-TYPES]
Медиа Типы . IANA. URL: https: // www.iana.org/assignments/media-types/
[iana-web-socket-registry]
Реестр IANA для Websocket Подпротоколы . IANA. 24 мая 2019 г. URL: https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name
[RFC2119]
Ключ слова для использования в RFC для обозначения требований Уровни . С. Брэднер. IETF.Март 1997. Best Текущая практика. URL: https://tools.ietf.org/html/rfc2119
[RFC6741]
Идентификатор-Локатор Сетевой протокол (ILNP) Engineering Соображения . Р. Дж. Аткинсон; С. Н. Бхатти. IETF. Ноябрь 2012 г. Экспериментально. URL: https://tools.ietf.org/html/rfc6741
[RFC7641]
Наблюдение Ресурсы в протоколе ограниченного приложения (CoAP) .К. Хартке. IETF. Сентябрь 2015 г. Предлагаемый стандарт. URL: https://tools.ietf.org/html/rfc7641
[RFC8174]
Неопределенность Прописные и строчные буквы в RFC 2119 Ключевые слова . Б. Лейба. IETF. Май 2017 г. Наилучшая текущая практика. URL: https://tools.ietf.org/html/rfc8174
[WOT-THING-DESCRIPTION]
Интернет Вещей (WoT) Описание вещи .Себастьян Käbisch; Такуки Камия; Майкл МакКул; Виктор Шарпеней; Маттиас Ковач. W3C. 6 ноября 2019. Кандидат в W3C Рекомендация. URL: https://www.w3.org/TR/wot-thing-description/
C.2 Справочные ссылки
[html]
HTML Стандарт . Анне ван Кестерен; Доменик Деникола; Ян Хиксон; Филип Йегенштедт; Саймон Питерс. WHATWG.Уровень жизни. URL: https://html.spec.whatwg.org/multipage/
[HTTP-в-RDF10]
HTTP Словарь в RDF 1.0 . Йоханнес Кох; Карлос А. Веласко; Филип Аккерманн. W3C. 2 февраля 2017. W3C Примечание. URL: https://www.w3.org/TR/2017/NOTE-HTTP-in-RDF10-20170202/
[json-ld11]
JSON-LD 1.1 . Грегг Келлогг; Пьер-Антуан Шампен; Дэйв Лонгли.W3C. 12 декабря 2019 г. W3C кандидат в рекомендацию. URL: https://www.w3.org/TR/2019/CR-json-ld11-201
/
[json-schema]
Схема JSON: основные определения и терминология . K. Zyp. Инженерная группа Интернета (IETF). 31 год Январь 2013. Интернет-проект. URL: https://tools.ietf.org/html/draft-zyp-json-schema
[MQTT]
MQTT версии 5.0 . Эндрю Бэнкс; Эд Бриггс; Кен Боргендейл; Рахул Гупта. MQTT. 07 марта 2019. URL: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
[RFC3986]
Униформа Идентификатор ресурса (URI): общий синтаксис . Т. Бернерс-Ли; Р. Филдинг; Л. Масинтер. IETF. Январь 2005. Интернет-стандарт. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
интернационализированный Идентификаторы ресурсов (IRI) .М. Дюрст; М. Suignard. IETF. Январь 2005 г. Предлагаемый стандарт. URL: https://tools.ietf.org/html/rfc3987
[RFC6570]
URI Шаблон . Дж. Грегорио; Р. Филдинг; М. Хэдли; М. Ноттингем; Д. Орчард. IETF. Март 2012 г. Предлагается Стандарт. URL: https://tools.ietf.org/html/rfc6570
[RFC7231]
Гипертекст Протокол передачи (HTTP / 1.1): Семантика и Содержимое . Р. Филдинг, Ред .; J. Reschke, Ed .. IETF. Июнь 2014 г. Предлагаемый стандарт. URL: https://httpwg.org/specs/rfc7231.html
[RFC7252]
Протокол ограниченного приложения (CoAP) . Z. Шелби; К. Хартке; К. Борман. IETF. Июнь 2014 г. Предлагается Стандарт. URL: https://tools.ietf.org/html/rfc7252
[WebSub]
Вебсаб .Жюльен Женесту; Аарон Парецки. W3C. 23 января 2018. Рекомендация W3C. URL: https://www.w3.org/TR/websub/
[WOT-ARCHITECTURE]
Сеть из Вещи (WoT) Архитектура . Маттиас Ковач; Рюичи Мацукура; Майкл Лагалли; Тору Кавагути; Кунихико Томура; Кадзуо Каджимото. W3C. 30 января 2020. Предлагаемая рекомендация W3C. URL: https://www.w3.org/TR/2020/PR-wot-architecture-20200130/
↑
.

Код	Имя	Номер ссылки
7,01	CSM	[RFCthis]
7.02	Пинг	[RFCthis]
7,03	Понг	[RFCthis]
7,04	Выпуск	[RFCthis]
7,05	Прервать	[RFCthis]

Относится к	Число	Имя	Номер ссылки
7.01	2	Максимальный размер сообщения	[RFCthis]
7,01	4	Блок-мудрая передача	[RFCthis]
7,02, 7,03	2	Опека	[RFCthis]
7,04	2	Альтернативный адрес	[RFCthis]
7,04	4	Задержка	[RFCthis]
7.05	2	Bad-CSM-Option	[RFCthis]

Номер	Имя	Номер ссылки
23	Блок2	RFC 7959, [RFCthis]
27	Блок1	RFC 7959, [RFCthis]

[I-D.bormann-hybi-ws-wk]	Борман, К., «Хорошо известные URI для протокола WebSocket», Internet-Draft draft-bormann-hybi-ws-wk-00, май 2017 г.
[RFC0793]	Постел, Дж., "Протокол управления передачей", STD 7, RFC 793, DOI 10.17487 / RFC0793, сентябрь 1981 г.
[RFC2119]	Браднер, С., «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487 / RFC2119, март 1997.
[RFC3986]	Бернерс-Ли, Т., Филдинг, Р. и Л. Масинтер, «Универсальный идентификатор ресурса (URI): общий синтаксис», STD 66, RFC 3986, DOI 10.17487 / RFC3986, январь 2005 г.
[RFC5246]	Диркс, Т. и Э. Рескорла, "Протокол безопасности транспортного уровня (TLS), версия 1.2", RFC 5246, DOI 10.17487 / RFC5246, август 2008 г.
[RFC5785]	Ноттингем, М.и Э. Хаммер-Лахав, «Определение хорошо известных универсальных идентификаторов ресурсов (URI)», RFC 5785, DOI 10.17487 / RFC5785, апрель 2010 г.
[RFC6066]	Истлейк 3-й, Д., «Расширения безопасности транспортного уровня (TLS): определения расширений», RFC 6066, DOI 10.17487 / RFC6066, январь 2011 г.
[RFC6455]	И. Фетте и А. Мельников, "Протокол WebSocket", RFC 6455, DOI 10.17487 / RFC6455, декабрь 2011 г.
[RFC7252]	Шелби, З., Хартке, К. и К. Борман, «Протокол ограниченного приложения (CoAP)», RFC 7252, DOI 10.17487 / RFC7252, июнь 2014 г.
[RFC7301]	Фридл, С., Попов, А., Лэнгли, А. и Э. Стефан, «Расширение согласования протокола прикладного уровня безопасности транспортного уровня (TLS)», RFC 7301, DOI 10.17487 / RFC7301, июль 2014 г.
[RFC7525]	Шеффер, Ю., Хольц, Р. и П. Сен-Андре, «Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)», BCP 195, RFC 7525, DOI 10.17487 / RFC7525, май 2015 г.
[RFC7595]	Талер Д., Хансен Т. и Т. Харди, «Рекомендации и процедуры регистрации для схем URI», BCP 35, RFC 7595, DOI 10.17487 / RFC7595, июнь 2015 г.
[RFC7641]	Хартке, К., «Наблюдение за ресурсами в протоколе ограниченного приложения (CoAP)», RFC 7641, DOI 10.17487 / RFC7641, сентябрь 2015 г.
[RFC7925]	Чофениг, Х.и Т. Фоссати, «Профили безопасности транспортного уровня (TLS) / дейтаграммной безопасности транспортного уровня (DTLS) для Интернета вещей», RFC 7925, DOI 10.17487 / RFC7925, июль 2016 г.
[RFC7959]	Борман, К. и З. Шелби, «Блочные передачи в протоколе с ограничениями приложений (CoAP)», RFC 7959, DOI 10.17487 / RFC7959, август 2016 г.
[RFC8126]	Коттон, М., Лейба, Б. и Т. Нартен, «Рекомендации по написанию раздела о соображениях IANA в RFC», BCP 26, RFC 8126, DOI 10.17487 / RFC8126, июнь 2017 г.

[BK2015]	Бирн, К. и Дж. Клеберг, «Рекомендации по развертыванию UDP», Proceedings draft-byrne-opsec-udp-advisory-00 (срок действия истек), 2015 г.
[EK2016]	Эделин, К., Кюлевинд, М., Траммелл, Б., Абен, Э. и Б. Доннет, «Использование UDP для развития Интернет-транспорта», Proceedings arXiv preprint 1612.07816, 2016.
[HomeGateway]	Эггерт, Л., «Экспериментальное исследование характеристик домашних шлюзов», Труды 10-й ежегодной конференции по измерению Интернета, 2010.
[I-D.gomez-lwig-tcp-ограниченные-узлы-сети]	Гомес, К., Кроукрофт, Дж. И М. Шарф, «TCP через сети с ограниченными узлами», Internet-Draft draft-gomez-lwig-tcp-constrained-node-networks-03, июнь 2017 г.
[I-D.ietf-core-какао]	Борман, К., Бецлер, А., Гомес, К.и И. Демиркол, «Простой контроль перегрузки CoAP / расширенный», Internet-Draft draft-ietf-core-cocoa-02, октябрь 2017 г.
[I-D.ietf-core-object-security]	Селандер, Г., Матссон, Дж., Паломбини, Ф. и Л. Зейтц, «Безопасность объектов для ограниченных сред RESTful (OSCORE)», Internet-Draft draft-ietf-core-object-security-07, ноябрь 2017 г.
[схемы IANA.uri]	IANA, «Схемы универсального идентификатора ресурса (URI)»
[LWM2M]	Открытый мобильный альянс, Техническая спецификация "Легкие машины в машины", версия 1.0 ", февраль 2017 г.
[RFC0768]	Постел, Дж., "Протокол дейтаграмм пользователя", STD 6, RFC 768, DOI 10.17487 / RFC0768, август 1980 г.
[RFC5234]	Крокер Д. и П. Оверелл, «Расширенный BNF для спецификаций синтаксиса: ABNF», STD 68, RFC 5234, DOI 10.17487 / RFC5234, январь 2008 г.
[RFC6335]	Коттон, М., Эггерт, Л., Тач, Дж., Вестерлунд, М. и С. Чешир, «Процедуры управления адресами Интернета (IANA) для управления реестром имени службы и номера порта транспортного протокола», BCP 165 , RFC 6335, DOI 10.17487 / RFC6335, август 2011 г.
[RFC6347]	Рескорла, Э. и Н. Модадугу, «Версия 1.2 безопасности транспортного уровня дейтаграмм», RFC 6347, DOI 10.17487 / RFC6347, январь 2012 г.
[RFC7230]	Филдинг, Р. и Дж. Решке, «Протокол передачи гипертекста (HTTP / 1.1): синтаксис сообщений и маршрутизация», RFC 7230, DOI 10.17487 / RFC7230, июнь 2014 г.
[RFC7540]	Белше, М., Peon, R. и M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP / 2)", RFC 7540, DOI 10.17487 / RFC7540, May 2015.
[Проблемы безопасности]	Полк, Т. и С. Тернер, «Проблемы безопасности для Интернета вещей», Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011.
[SW2016]	Светт, И., "QUIC Deployment Experience @Google", Proceedings https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf, 2016.

`op` Срок	Описание
`readproperty`	Прочитать недвижимость.Требуется `Только запись` должно быть установлено значение `false` .
`свойство записи`	Написать недвижимость. Требуется `Только чтение` должно быть установлено значение `false` .
`Наблюдать за недвижимостью`	Наблюдать за недвижимостью. Требует `наблюдаемый` должен быть установлен на `правда` .
`ненаблюдаемая собственность`	Скрыть собственность.Требует `наблюдаемый` должен быть установлен на `правда` .

`op` Срок	Описание
`подписка событие`	Подписаться на событие.
`отписатьсявент`	Отписаться от события.

Словарный термин	Описание	Переуступка	Тип
`htv: methodName`	Имя метода HTTP (литерал).	опционально	`строка` (один из `"GET"` , г. `«ПОСТ»` , `«ПОСТ»` , г. `«УДАЛИТЬ»` , `«ПАТЧ»` )
`htv: заголовки`	HTTP-заголовков, отправленных с сообщением.	опционально	массив `htv: MessageHeader`
`htv: fieldName`	Название заголовка (буквальное), e.г., `«Принять»` , г. `"Кодирование передачи"` .	обязательно в пределах `htv: MessageHeader`	`строка`
`htv: fieldValue`	Значение заголовка (литерал).	обязательно в пределах `htv: MessageHeader`	`строка`

`op` значение	Привязка по умолчанию
`readproperty`	`"htv: methodName": "GET"`
`свойство записи`	`"htv: methodName": "PUT"`
`invokeaction`	`"htv: methodName": "POST"`
`прочитать все свойства`	`"htv: methodName": "GET"`
`записьвсе свойства`	`"htv: methodName": "PUT"`
`читатьмножественные свойства`	`"htv: methodName": "GET"`
`запись множественных свойств`	`"htv: methodName": "PUT"`

Словарный термин	Описание	Переуступка	Тип
`cov: methodName`	Название метода CoAP (буквальное).	опционально	`строка` (один из `"GET"` (1), `«ПОСТ»` (2), `«ПОСТ»` (3), `«УДАЛИТЬ»` (4), `«ПОЛУЧИТЬ»` (5), `"НАШИВКА"` (6), `«iPATCH»` (7))
`cov: опции`	опции CoAP, отправленные с сообщением, e.г., `[{"cov: optionName": "Принять", "cov: optionValue": 110}]` для наблюдения.	опционально	массив `cov: MessageOption`
`cov: optionName`	Название опции (Literal), см. Параметры CoRE.	обязательно в пределах `cov: MessageOption`	`строка`
`cov: optionValue`	Значение заголовка (литерал).	обязательно в пределах `cov: MessageOption`	`любой Тип`

`op` значение	Привязка по умолчанию
`readproperty`	`"cov: methodName": "GET"`
`свойство записи`	`"cov: methodName": "PUT"`
`Наблюдать за недвижимостью`	`"cov: methodName": «GET»`, `«подпротокол»: «cov: наблюдать»`
`ненаблюдаемая собственность`	`"cov: methodName": «GET»`, `«подпротокол»: «cov: наблюдать»`
`invokeaction`	`"cov: methodName": "POST"`
`подписатьсявент`	`"cov: methodName": «GET»`, `«подпротокол»: «cov: наблюдать»`
`отписатьсявент`	`"cov: methodName": «GET»`, `«подпротокол»: «cov: наблюдать»`
`прочитать все свойства`	`"cov: methodName": "GET"`
`записьвсе свойства`	`"cov: methodName": "PUT"`
`читатьмножественные свойства`	`"cov: methodName": "GET"`
`запись множественных свойств`	`"cov: methodName": "PUT"`

Словарный термин	Описание	Переуступка	Тип
`mqv: controlPacketValue`	Тип пакета управления MQTT (буквальный).	опционально	`строка` (одна из `"ПУБЛИКАЦИЯ"` (3), `«ПОДПИСАТЬСЯ»` (8), `«ОТПРАВИТЬСЯ»` (10))
`кв.м .: варианты`	параметры MQTT, отправленные с сообщением, e.г., `[{"mqv: optionName": "qos", «mqv: optionValue»: 1}]`.	опционально	массив `mqv: MessageOption`
`mqv: optionName`	Имя параметра (буквальное).	обязательно в пределах `mqv: MessageOption` )	`строка` (один из `"qos"` , `"сохранить"` , `"дублировать"` )
`mqv: optionValue`	Значение заголовка (литерал).	обязательно в пределах `mqv: MessageOption` )	Один из `0` , `1` или `2` (только для `qos` )

`op` значение	Привязка по умолчанию
`readproperty`	`"mqv: controlPacketValue": «ПОДПИСАТЬСЯ»,`
`свойство записи`	`"mqv: controlPacketValue": «ПУБЛИКАЦИЯ»`
`Наблюдать за недвижимостью`	`"mqv: controlPacketValue": «ПОДПИСАТЬСЯ»`
`ненаблюдаемая собственность`	`"mqv: controlPacketValue": «ОТПИСАТЬСЯ»`
`invokeaction`	`"mqv: controlPacketValue": «ПУБЛИКАЦИЯ»`
`подписатьсявент`	`"mqv: controlPacketValue": «ПОДПИСАТЬСЯ»`
`отписатьсявент`	`"mqv: controlPacketValue": «ОТПРАВИТЬСЯ»`
`прочитать все свойства`	`"mqv: controlPacketValue": «ПОДПИСАТЬСЯ»`
`записьвсе свойства`	`"mqv: controlPacketValue": «ПУБЛИКАЦИЯ»`
`читатьмножественные свойства`	`"mqv: controlPacketValue": «ПОДПИСАТЬСЯ»`
`запись множественных свойств`	`"mqv: controlPacketValue": «ПУБЛИКАЦИЯ»`

КоАП РФ Статья 32.13. Исполнение постановления о назначении обязательных работ

Ст. 3.13 КОАП РФ. Обязательные работы

последние изменения и поправки, судебная практика

Комментарий к Ст. 3.13 Кодекса об Административных Правонарушениях РФ

Новый КоАП предполагает освободить женщин, воспитывающих детей, от общественных работ — Общество

Сенатор предлагает освободить подростков от обязательных работ за правонарушения | Российское агентство правовой и судебной информации

Госдума разрешила восьмичасовые обязательные работы

В России предложили сократить максимальный срок обязательных работ

Когда я буду готов подать заявление на мое пребывание в должности?

Платформа пользовательских сервисов — стандартизированное управление и контроль Интернета вещей

Сопоставление конечных точек USP с URI CoAP

Сопоставление записей USP с сообщениями CoAP

Обработка успешного запроса CoAP

Обработка сбоев запроса CoAP

Шифрование сообщений MTP

Студент или стажер в кооперативе

Право на участие

COVID-19 и кооперативное размещение

Кто не имеет права

Как поступать

Как онлайн-подача заявки помогает вам

Подайте онлайн-заявку на разрешение на совместную работу

Шаг 1. Убедитесь, что у вас есть то, что вам нужно

Шаг 2. Прочтите инструкцию

Шаг 3. Подготовьте ответы к онлайн-инструменту

Шаг 4. Узнайте, какую комиссию вы должны заплатить

Шаг 5. Создайте учетную запись в Интернете или войдите в систему.

Если вы не можете подать заявку онлайн

Начните свое совместное размещение за пределами Канады

Если вы еще не подавали заявку на разрешение на работу в кооперативе

Подать заявление с разрешением на учебу

emqx / emqx-coap: шлюз EMQ X CoAP

Пример использования клиента

Пример публикации:

Пример подписки:

Настроить

Обычный

DTLS

Включить двустороннюю аутентификацию

Нагрузка emqx-coap

Наблюдение за работой клиента CoAP (подписка на тему)

CoAP Client Unobserve Operation (тема отказа от подписки)

Операция уведомления клиента CoAP (сообщение с подпиской)

Операция публикации клиента CoAP

CoAP Client Keep Alive

Примечания клиента CoAP

ClientId, имя пользователя, пароль и тема

известные локации

Лицензия

Автор

CoAP :: Eclipse Hono ™

Конфигурация службы

Конфигурация порта

Только безопасный порт

Только незащищенный порт

Двухпортовый

Временные порты

Аутентификация

CoAP (протокол ограниченного приложения) по TCP, TLS и WebSockets

шаблонов привязки Web of Things (WoT)

Абстрактные

Статус этого документа

Таблица Содержание

Оставить комментарий Отменить ответ