Показаны сообщения с ярлыком стандарты. Показать все сообщения
Показаны сообщения с ярлыком стандарты. Показать все сообщения

Стандарты BitCoin

Криптовалюты в своём развитии достигли такого этапа, когда становится сложно обходится без централизованной документации и учёта предложений по развитию. Количество сценариев использования электронных денег, основанных на протоколах шифрования, стремительно растёт и включает в себя протоколы платежей, форматы представления URI, описания команд взаимодействия P2P и много другое.

Яндекс OpenID всё

Получил письмо от поддержки Яндекса:

Здравствуйте!
Вы получили это письмо, потому что используете свою учётную запись Яндекса для входа на другие сайты. Это называется «социальной авторизацией», в её основе лежит протокол OpenID. Яндекс несколько лет использовал эту технологию, чтобы вам не приходилось регистрироваться на сторонних сайтах. Но время идёт, протокол устарел и качество его работы перестало нас устраивать.

Мы решили с 10 августа отключить поддержку OpenID и перейти на API Яндекс.Паспорта.

Рекомендуется получить прямой доступ ко всем сервисам, где использовался OpenID от яндекса. 

RFC от 1 апреля 2015 года

В 2015 году коллекция шутливых RFC обогатилась двумя новыми экземплярами:

RFC 7511 предлагает ввести в протокол IPv6 дополнительную опцию маршрутизации, которая позволит несчастным IP-пакетам получать как можно больше свежего воздуха, избегая передачи по меди или оптике в пользу беспроводных сред. Вероятно, от этого IP-пакеты станут более счастливыми и количество добра в мире увеличится.

RFC 7514 предлагает ввести в ICMP новое ообщение "Really Explicit Congestion Notification" (RECN), которое можно использовать в качестве совета уменьшить скорость передачи данных для таких устройств, которые не понимают нормального языка игнорируют потерю пакетов или сообщения Explicit Congestion Notification (ECN). Новый стандарт предлагает доводить такое сообщение аж до специалиста, ответственного за передачу пакетов на конкретном узле и даже выдавать аудио-сигнализацию или показывать pop-up сообщение, если подсистема text-to-speach отключена или звук выключен

DLNA: Что такое DMP, DMR и DMS?

Описывая своё знакомство с приставкой Dune HD TV, забыл рассказать, что этот медиаплеер умеет работать с DLNA (Digital Living Network Alliance). По крайней мере, как только подключил локальную сеть, дюна сразу увидела домашний Plex Media Server, и легко воспроизводит практически любой контент. Но есть одна беда,- веб-интерфейс плекса не позволяет запустить воспроизведение видео прямо на дюну. При этом, в каких-то программах для Android я такое видел,- выбор устройства, на которое хочется выводить сигнал. Пошёл искать, и выяснил для себя вот что:

Все SIP RFC




Ниже обновляемый список RFC, описывающих протокол SIP и его все его дополнения. Последнее обновление выполнено  06.02.2015 г. Кроме этого списка, поиск документа по конкретной теме начать можно с RFC 5411 (на английском языке), там есть почти полный список с разбивкой на категории и темы по состоянию на 2009 год.
Список длинный, разбит по годам появления документов:

Новые RFC про SIP:

Не успел собрать в один список все RFC по сипу, как в мае 2014 появилось 3 новых документа: rfc7245, касающийся архитектуры для реализации записи разговоров в SIP, и интернетворкинг SIP и XMPP в раздельных документах,- архитектур, адресация и обработка ошибок (rfc7247) и, отдельно, статусы присутствия (rfc7248). Общий список обновил, естественно.

Все RFC про SIP в одном месте!

Одно время меня активно интересовал SIP и разные его инкарнации в виде МультиФона, всевозможных SIP-телефонов и программных клиентов. Потом в силу определённых обстоятельств окружающей действительности, интересы немного изменились, но пятно на карме осталось. Чтобы подытожить накопленный опыт и вообще попытаться спрыгнуть с собственной тени, -  привёл в порядок старый пост про список спецификаций SIP. Пост был небольшой и неказистый,- немного кривое форматирование, да и RFC не все. В самом начале казалось, что список документов должен быть не очень большим, ссылок 20 или 30... Но реальность, как обычно, оказалась намного интереснее,- как выяснилось, с 2001 по 2014 год,  рабочие группы IETF опубликовали почти 200 спецификаций, информационных документов, размышлений о будущем протокола и сборников сигнального обмена на все случаи жизни. В эмпирическую оценку вкралась небольшая десятикратная погрешость :-).  И это ещё я не включал RFC, в названии которых нет аббревиатуры SIP, например, в список не попали стандарты, касающиеся форматов SDP.  Но зато, в процессе изучения аннотаций и вводных глав вспомнилось многое из того, что уже казалось забытым, ну и, конечно, новые какие-то вещи тоже попались. Вообщем, получился полный список SIP RFC с краткими русскими названиями.

April1: HTCPCP-TEA и NSA Certificate Extension

Фрагмент логотипа сайта http://www.rfc-editor.org/
В этом году на 1 апреля RFC опубликовал два новых чудесных документа:

Первый из них RFC 7168, озаглавленный The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA), повествует о нелёгкой судьбе кофейников, предоставляющих сетевые функции приготовления кофе по протоколу HTCPCP, но не умеющих при этом варить чай. К слову сказать, протокол HTCPCP тоже зафиксирован в RFC 2324 ещё 1 апреля 1998 года. Так вот, HTCPCP-TEA определяет дополнительные коды возврата, например, HTTP 300 Multiple Options возвращается кофеваркой, если URL, по которому обратился клиент, может запускать процесс приготовления и того и другого напитка. Кроме того, этот документ стандартизирует новый тип MIME message/teapot на случай, когда клиент, обращающийся по сети к кофеварке хочет непременно чаю (а если ещё да с мягкими французскими булочками,- как быть тогда?)

Второй первоапрельский RFC 2014 года,- RFC 7169 The NSA (No Secrecy Afforded) Certificate Extension,- предлагает добавить в сертификаты новое расширение "Секретность не поддерживается" на тот случай когда владелец сертификата не уверен, сможет ли он сохранить свои приватные ключи действительно приватными, или даже если прямо хочет сообщить, что приватные ключи публично доступны. Вообщем,- секретность,- это сложно.

Сравнить нельзя обновить

Ну, допустим, хочется сделать скрипт проверки и обновления какого либо файла из интернет. Хороший такой скрипт, чтобы лишней нагрузки на сервер не создавал, и лишний трафик не гонял. То есть, необходимо проверять обновление какого-либо ресурса по URL, и, при необходимости, загружать новую версию, или как-то по иначе отреагировать, письмо, например, послать. Тут на помощь приходят заголовки HTTP Last-Modified (в ответе сервера) и If-Modified-Since или If-Unmodified-Since(в запросе). При ближайшем рассмотрении оказывается, что значения в этих полях не имеет смысла из строкового приводить к типу datetime в принципе

FTL Communications

Очередной первоапрельский RFC: Соглашения для коммуникаций на скорости быстрее света (Design Considerations for Faster-Than-Light (FTL) Communication).

Автор упоминает некоторые аспекты взаимодействии пространства-времени при околосветовых скоростях и делает смелое предположение, что при скорости быстрее света время обращается вспять. Это может привести к таким неожиданным эффектам, что пакеты данных могут будут доставлены получателю раньше, чем они были посланы отправителем. Таким образом, существующий дизайн протокола TCP/IP не совсем подходит для передачи данных в среде FTL и требует доработки.

Помимо некоторых RFC, требующих переосмысления, автор рекомендует задуматься над соглашениями и ограничениями путешествий во времени, так как, по его мнению, FTL-коммуникации неминуемо приведут к возможности путешествий во времени:
That said, FTL communication might lead to FTL travel, where we can travel into the past. It may be necessary to start working on this yesterday.

Как позвонить на Марс

Внезапно выяснилось, что международная нумерация на +0 зарезервирована для абонентов на Луне, Венере и Марсе.

Правда, современные стандарты типа E.164 об этом умалчивают. Это я так разбирался со статистикой звонков. Встречал разное, даже в Сье́рра-Лео́не люди звонят, хотя это фрод наверняка. А межпланетных звонков на нашем софтсвиче пока не выявлено.

Широковещательная передача через атмосферу

Очередной первоапрельский RFC 6217: Regional Broadcast Using an Atmospheric Link Layer :-)

Предлагают использовать в качестве среды передачи атмосферу. В IPv4/6 слишком много лишних заголовков (Destination, TTL (Time to Live), DSCP (Diffserv Code Point), ECN (Explicit Congestion Notification), Hop Limits и т.д.). От этого всего можно отказаться. Оставим только необходимое:

      +-------------------------------+-----------------------------+
      |            Content            |           Source            |
      +-------------------------------+-----------------------------+

                     Рисунок 1: Формат датаграммы

Content - Поле переменной длины, содержащее инкапсулированные данные протоколов верхнего уровня,
Source - источник данных
В качестве источника могут выступать:
  • IP - адрес
  • номер телефона в формате E.123
  • IPv6 адрес в стандартной нотации (RFC 5952)
  • URI (RFC 3986)
  • географический адрес
  • и так далее...
Типичным примером использования такого вида связи может быть трансляция рекламных сообщений, типа такого:
 Content                          Source
   +------------------------------------------------------------+
   | Lobster Dinner - only $14.99    500 Boardwalk, Pt Pleasant |
   +------------------------------------------------------------+

                 Figure 2: Example ADVERT Datagram

Жгут ребята :-)

Полный список параметров SIP

Обнаружил полезный документ,- полный список заголовков SIP и других параметров (Session Initiation Protocol (SIP) Parameters):
В документе описаны:

Registries included below:
- Заголовки (Header Fields)
- Протоколы причин (Reason Protocols)
- Опциональные теги (Option Tags)
- Коды уведомлений (Warning Codes (warn-codes))
- Методы и коды ответов (Methods and Response Codes)
- Значения приватных заголовков (SIP Privacy Header Values)
- Имена механизмов безопасности (Security Mechanism Names)
- Схемы сжатия (Compression Schemes)
- Параметры URI (SIP/SIPS URI Parameters)
- Параметры и значения полей заголовков (Header Field Parameters and Parameter Values)
- Назначения и форматы URI (URI purposes)
- Пространства имён приоритетов (Resource-Priority Namespaces)
- Значения приоритетов (Resource-Priority Priority-values)
- Параметры идентификационной информации (Identity-Info Parameters)
- Параметры алгоритма идентификационной информации (Identity-Info Algorithm Parameter Values)
- Параметры настройки User-Agent (SIP Forum User Agent Configuration Parameters)

API к Я.ру

 Сначала вКонтакте открывает XMPP, теперь вот Яндекс запустил бету API к Я.ру. Гораздо интереснее не сама новость, а рассказ Ивана Сагалаева о том, как всё это делалось и устроено внутри. API сделано в соответствии с идеологией REST. Помимо собственно API сделан также сервис OAuth-авторизации для этого и других API Яндекса. В блоге яндекса есть даже пример кода на Python, реализующий смену настроения пользователя.

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

Skype: SDK и аудиокодек SILK

 Оказывается Skype ещё в марте открыл спецификации своего аудио кодека SILK для некоммерческого использования. Краткая информация по кодеку доступна на странице для разработчиков, оттуда же доступны ссылки на весьма интересный драфт драфт RFC и описание формата RTP payload с отсылками к RFC 3550 и нескольким другим. Ощущение такое, что изначально всё базировалось на SIP.

И ещё срочно в номер: появился SkypeKit SDK, который позволяет любым программам и устройствам использовать сеть Skype для обмена сообщениями, контроля статуса, аудио и видео-связи без необходимости установки проприетарного клиента.

UCIF

Компании Juniper Networks, Polycom, Logitech, Hewlett-Packard и Microsoft образовали некоммерческий альянс UCIF (Unified Communications Interoperability Forum) для совместного развития Unified Communications. Предполагается, что это позволит добиться совместимости ПО и устройств от различных производителей. Уже сейчас в альянс вступили такие компании, как Acme Packet, Aspect, AudioCodes, Broadcom, BroadSoft, Brocade, ClearOne, Jabra, Plantronics, RADVISION, Siemens Enterprise Communications и Teliris.

Мультифон: настройка входящих вызовов

Тем, кто пользуется альтернативными клиентами для Мультифона, узнать режим приёма входящих звонков или изменить входящую маршрутизацию можно с помощью обычного браузера (или HTTPs запроса, например с помощью wget)
Предположим, что ваш номер телефона — 79261234567, а пароль — aaaBBB

Серии рекомендаций ITU-T

Правильному IT-шнику надо учить матчасть. Помимо IETF, известной специалистам по множеству документов RFC существует Международный Институт Электросвязи (International Telecommunication Union). ITU является ведущим учреждением Организации Объединенных Наций в области информационно-коммуникационных технологий. Роль МСЭ, как всемирного координационного центра для органов государственного управления и частного сектора, состоит в том, чтобы помогать миру общаться, и осуществляется в виде деятельности трех основных секторов: радиосвязи, стандартизации и развития. Деятельность МСЭ по разработке стандартов (Сектор стандартизации электросвязи ITU-T) является самым известным и самым давним видом его деятельности.

Jabber от Яндекс

Вслед за поддержкой сторонних доменов Яндекс включил поддержку Jabber для доменов. Пока что сервис работает в режиме бета. Естественно, для корректной работы джаббера придётся настроить записи в DNS. Таким образом, Яндекс ещё на один шаг приблизился к вечно обгоняющему Гуглу.

Настроение TCP-пакетов

Для того, чтобы добавить немного антропоморфности потокам бит сетях всего мира, специалисты из Google R. Hay и W. Turkal предлагают использовать опции TCP для передачи настроения. Вольный перевод:

Сами по себе пакеты не могут чувствовать. Они созданы только для передачи данных от одного хоста к другому. Тем не менее, в некоторых ситуациях можно добавить им немного эмоциональности. Например, пакет, который пришлось отправить повторно (из-за того, что для него не было получено подтверждение ACK), может быть описан как "сердитый" или "разочарованный"


Предложение гугловцев зафиксировано в RFC 5841 1 апреля 2010 года, и содержит описание TCP Options для использования, возможные Use Cases, психологические характеристики различных пакетов (счастливые, удивлённые и смущённые пакеты, и даже апатичные, ага) и отсылки к используемой литературе и дополняемым RFC