Web call (uri2dec) open source project home page

Welcome

August 19, 2007

Кодирование URI десятичными цифрами

Filed under: Technical notes — admin @ 6:57 pm

Кодирование URI десятичными цифрами
Статус документа

Этот документ предлагает стандарт Интернет сообществу, и является запросом обсуждения и подачи замечаний. Пожалуйста, обращайтесь к текущей версии “Internet Official Protocol Standards” (STD 1) для получения статуса этого документа.
Документ соответствует требованиям пункта 10 RFC2026 [1].
Распространение этого документа не ограничено.

Авторские права

Copyright (C) Андрей Иванов (2006-2007). Все права зарезервированы.

Реферат

Документ обсуждает трансляцию доменных имен (DNS) и универсальных идентификаторов ресурсов Интернет (URI) в последовательности десятичных цифр для обеспечения простого ввода на номеронабирателях коммуникационных устройств и декодирование этих последовательностей в URI.

Содержание
Содержание 1
1. Введение 2
1.1. Термины 2
2. Проблема 2
3. Назначение 3
3.1. Сценарий 1 3
3.2. Сценарий 2 3
3.3. Сценарий 3 3
3.4. Сценарий 4 4
4. Области применения 4
5. Кодирование 4
5.1. Хеш 4
5.2. Ключ 5
5.3. Процедура инверсии адреса 5
5.4. Кодирование позиции буквы на клавише 6
5.5. Примеры 7
5.6. Замечание для случая нулевого ключа 8
5.7. Расширение 8
5.8. Номер сервиса 8
5.9. Запись 8
6. Предварительно инвертированный адрес 8
7. Декодирование 9
7.1. Определение, является ли число номером сервиса 9
7.2. Удаление расширения 9
7.3. Определение начала ключа 9
8. Кодировки 10
8.1. Регистр букв адреса 10
8.2. Национальные кодировки в адресе 10
8.3. Кодирование специальных символов 10
9. Поиск в адресных книгах 10
9.1. Приложения адресных книг 10
9.2. Иерархия адресных книг 10
9.3. Запоминание новых Хешей и Ключей 11
9.4. Коллизии хеша 11
10. Безопасность 11
11. Благодарности 11
12. Нормирующие документы 11
1. Введение
Документ описывает алгоритм кодирования доменных имен, идентификаторов ресурсов Интернет (URI) десятичными цифрами, который может использоваться для ввода человеком на номеронабирателях телефонов и других устройств.
Данный алгоритм в первую очередь предназначен для использования в VoIP приложениях, в частности, использующих SIP [4].
1.1. Термины
Слова “ДОЛЖНО”, “ТРЕБУЕТСЯ”, “БУДЕТ”, “РЕКОМЕНДОВАНО” и “МОЖЕТ”, встречаемые в этом документе должны интерпретироваться, как описано в RFC 2119 [2].
2. Проблема
Установление соединения, когда Инициатор использует обычный телефонный аппарат, снабженный 10 или 12 клавишным номеронабирателем (рис. 1), в частности, подключенный к традиционной телефонной сети, а вызываемый абонент - компьютер или IP-телефон, соединенный с Internet или частной IP сетью, сопряжено со сложностью, вызванной применением разных схем адресации:
в общедоступных телефонных сетях на основе стандарта E.164;
в Интернет на основе системы имен DNS.
В таком случае Инициатор должен определенным образом транслировать вводимую последовательность цифр с помощью номеронабирателя в адрес с использованием системы имен DNS.
Таким адресом в документе считается универсальный идентификатор ресурсов Интернет, описанный в RFC 3761 [3], хотя в общем случае допускается кодирование любой текстовой или бинарной последовательности.
[...]
Рисунок 1. Номеронабиратель.

В известных решениях – ENUM [5] и DUNDi [6] требуются дополнительные элементы, хранящие информацию для трансляции вводимого номера и адреса, в частности, отдельные системы хранения и поиска номеров телефонов.
Этот документ предлагает способ трансляции последовательности десятичных цифр на номеронабирателях “обычных” и IP телефонов в идентификаторы ресурсов Интернет без необходимости дополнительных элементов, называемый кодированием.
Принципиально кодирование состоит из двух шагов:
ввода адреса на номеронабирателе, Пользователь нажимает клавиши с соответствующими надписями; далее в документе полученная последовательность цифр называется Хешем;
добавлении к хешу последовательности цифр, приблизительно в два раза короче адреса, называемой Ключом.
Ключ должен либо вводиться Пользователем, либо устройство может пытаться восстановить ключ по Хешу, используя словари, называемые в документе Адресными книгами.
Получаемая последовательность цифр называется Интернет кодом сервиса, и она не является ни глобальным номером в стандарте E.164, ни локальным номером.
3. Назначение
В первую очередь кодирование предназначено для набора URL на номеронабирателях телефонов.
В общем же, описываемый алгоритм предназначен для кодирования последовательностей алфавитно-цифровых символов десятичными цифрами и декодирования кода обратно в последовательность алфавитно-цифровых символов.
Представлено несколько сценариев того, как может использоваться описанное кодирование (пункт 5) и декодирование (пункт 7).
3.1. Сценарий 1
Пользователь bob@commandus.com на IP телефоне нажимает кнопки с буквами:

2 5 4 2 3
a l i c e
и соединяется с alice@commandus.com
3.2. Сценарий 2
Пользователь carol@atlanta.com ранее звонила alice@commandus.com и на IP телефоне нажимает кнопки с буквами:

2 5 4 2 3 0 2 6 6 6 2 6 3 8 7 0 2 6 6
a l i c e @ c o m m a n d u s . c o m

и соединяется с alice@commandus.com через свой SIP proxy сервер.
3.3. Сценарий 3
Пользователь carol@atlanta.com нашла в списке адресов bob и первый раз звонит bob@commandus.com, и на IP телефоне нажимает кнопки с буквами:

2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
В ответ на запрос телефона, Carol затем вводит ключ:
1 1512622351721
и соединяется с bob@commandus.com через свой SIP proxy.
Последующие звонки Carol делает как в сценарии 3 (пункт 3.3)
2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
3.4. Сценарий 4
Пользователь carol@atlanta.com получила по почте другой список:
bob@commandus.com - 26602666263870262 0 1512622351721
alice@commandus.com – 2660266626387025423 0 51262235162333
Спросив Alice, почему ее номер телефона изменился, Carol получила ответ, что оба номера являются одинаково правильными.
4. Области применения
Из-за особенностей описываемого алгоритма, алгоритм наиболее эффективно может применяться в интерактивных системах “человек-машина”, снабженных номеронабирателем
Типичным применением является ввод цифровым кодом URI, в частности:
SIP адресов IP телефонии [4];
адресов почтовых и голосовых ящиков, рассылок и групп пользователей;
адресов других Интернет сервисов и ресурсов, например, веб ресурсов
Пользователем на номеронабирателе (рис. 1).
Типичные реализации алгоритма:
в носимых устройствах мобильной связи;
на коммутаторах мобильной, стационарной и другой связи;
на серверах VoIP телефонии
должны позволять декодировать код в адреса.
Алгоритм оптимизирован для кодирования адресов ресурсов Интернет и также рекомендуется как генератор “глобальных” номеров VoIP телефонов (кодирование).
Обратно, описанный алгоритм делает однозначное преобразование “глобальных” номеров VoIP телефонов (декодирование) в адреса, например, адреса SIP телефонов.
Также алгоритм подходит для штрихового кодирования, где применяются десятичное представление. Алгоритм также позволяет кодировать и декодировать любую информацию, как бинарную, так и представленную в различных кодировках.
5. Кодирование
5.1. Хеш
Для кодирования символов латинского алфавита и цифр от “0″ до “9″, а также нескольких символов пунктуации используется таблица 1, составленная в соответствии с рисунком 1:
Таблица 1. Начальные коды символов латиницы
Символы
Код
“1″
1
“a”, “b”, “c”, “2″
2
“d”, “e”, “f”, “3″
3
“g”, “h”, “i”, “4″
4
“j”, “k”, “l”, “5″
5
“m”, “n”, “o”, “6″
6
“p”, “q”, “r”, “s”, “-”, “/”, “:”, “7″
7
“t”, “u”, “v”, “8″
8
“w”, “x”, “y”, “z”, “_”, “?”, “&”, “9″
9
“.”, “@”, “%”, “0″
0
Например, для адреса:
alice@commandus.com
код начинается с:
2542302666263870266
что называется Хешем адреса.
Синтаксис Хеша определяется в форме Бэкуса-Наура (BNF) в соответствии с RFC-2234 [7]:
hash = {”0″..”9″}
Пользователь на номеронабирателе нажимает клавиши, имеющие соответствующие надписи, а вместо недостающих символов “@” и “.” нажимает клавишу “0″. Делая предположение, что имена запоминаются легче, чем номера, Пользователю не будет слишком сложно ввести последовательность цифр такой длины.
Кроме того, Пользователь может ввести неполный адрес, например:
alice
хеш:
25423
Хеш сам не может быть однозначно преобразован в адрес. Для этого необходима дополнительная информация, называемая Ключом. Ключ может быть введен Пользователем сразу в момент ввода после Хеша, либо устройство, на котором произведен ввод, МОЖЕТ попытаться найти в своей памяти или инициировать поиск в другом месте подходящих адресов. Поиск в адресных книгах описан в пункте 9.
В результате удачного поиска Хеш ДОЛЖЕН дополняться ключом. Если поиск не дал результатов, Пользователь должен самостоятельно ввести ключ.
Допускается и иной порядок формирования Хеша, с предварительно инвертированным адресом, который рассматривается отдельно.
5.2. Ключ
Ключ содержит информацию, необходимую того, чтобы Хеш мог быть однозначно преобразован в адрес.
key:= “1″|”0″ space {”0″..”7″}
Ключ всегда начинается с символа “1″ или “0″. Символ “0″ используется для предварительно инвертированных адресов (см. пункт 6), иначе используется “1″. Назначение инвертированных адресов поясняется ниже. Символ пробела введен для того, чтобы при записи визуально разделить группы цифр.
Далее делается инверсия адреса.
5.3. Процедура инверсии адреса
Для инверсии адреса делается следующее:
В хеше находятся символы “0″, что соответствует символам “.”, “@”, “,”, “0″ в строке адреса
По найденным позициям выделяются слова, не включая символы “.”, “@”, “,”, “0″. Эти символы составляют самостоятельные слова.
Слова копируются в обратном порядке в строку “инвертированного” адреса
Эти шаги описывают инверсию адреса, и для предварительно инвертированного адреса пропускаются.
Например, в
alice@commandus.com
выделяются слова
“alice” “@” “commandus” “.” “com”
и, поменяв порядок следования слов, адрес преобразуется в:
com.commandus@alice
Это называется инвертированным адресом. Для построения ключа используется не инвертированный адрес (так как ключ инвертирует символы).
5.4. Кодирование позиции буквы на клавише
Далее Ключ составляется из цифр “0″..”7″ следующим образом.
Для каждого символа кодируемой последовательности символов в таблице 2 определяется занимаемое число бит. Для разных символов число бит разное. Для символа “1″ число бит равно 0. Для большинства остальных символов число занимаемых бит равно 2, и некоторые требуют 3 бита.
Далее, в той же таблице для каждого символа определяется номер позиции.
Как видно на рисунке 1, номер позиции означает, какая по счету это буква на клавише, но не во всех случаях.
Этот номер кодируется 2 или 3 битами (кроме случая символа “1″, который не требует кодирования). Эти биты копируются в заранее обнуленный битовый вектор достаточного размера так, чтобы первый символ кодируемой последовательности символов занимал младший адрес, а последний – старший адрес. Как минимум, размер вектора для адреса должен быть не меньше 16 октетов.

Например:
alice
хеш:
25423
вектор:
e c i l a
01 00 10 10 01
MSB LSB
Затем битовый вектор будет преобразовываться в его восьмеричное представление.
Определяем самый старший значимый бит – бит 8. Нулевые значения старших разрядов не кодируются. Заметим, что бит 8 также является старшим битом в триаде:
100 101 001
MSB LSB
Затем адрес нужно выровнять на триаду так, чтобы номер старшего значимого бита был кратен 3 (2, 5, 8…). Для этого в вектор в младшие адреса добавляется от 2 до 4 бит. Так как триады уже выровнены, нужно добавить три бита.
Младшие два бита указывают на количество выравнивающих старших битов.
0…0 L L
MSB LSB
Целью выравнивания является сделать так, чтобы выровнять на триаду слово. В примере
выше нужен 1 дополнительный выравнивающий бит, с учетом 2 бит длины, тогда нужно добавить биты 001:
100 101 001 001
MSB LSB
Наконец, каждый триплет преобразуем в восьмеричную цифру (с использованием символов, начиная с «1»: «1»…«9», а не «0»… «7»), получаем:
5622
Таблица 2. Коды позиций символов латиницы
0
1
2
3
4
5
6
7
Число бит
1

0
C
A
B
2

2
D
E
F
3

2
G
H
I
4

2
J
K
L
5

2
O
M
N
6

2
P
Q
R
S
-
7
/
:
3
T
U
V
8

2
W
X
Y
Z
_
9
?
&
3
.
@
%
0

2
5.5. Примеры
Рассмотрим пример с разбиением адреса на слова. Например, для адреса:
alice@commandus.com
хеш:
2542302666263870266
вектор:
m o c . s u d n a m m o c @ e c i l a
01 00 00 00 011 01 00 10 01 01 01 00 00 01 01 00 10 10 01
MSB LSB
Выравнивающие биты:
38 значимых бит в ключе, для выравнивания нужен 1 бит, но число выравнивающих бит должно быть не меньше 2, поэтому нужно 4 бита. Выравнивающие биты:
0010
C учетом выравнивающих бит триплеты:
100 000 001 101 001 001 010 100 000 101 001 010 010 010
Ключ:
1 51262235162333
Хеш с Ключом:
2542302666263870266 1 51262235162333
Другой пример адреса:
bob@commandus.com
Хеш:
26202666263870266
вектор:
c o m . s u d n a m m o c @ b o b
01 00 00 00 011 01 00 10 01 01 01 00 00 01 10 00 10
MSB LSB
Выравнивающие биты:
34 бит в ключе, достаточно 2 бит, следовательно, выравнивающие биты:
001
C учетом выравнивающих бит триплеты:
100 000 001 010 110 000 101 101 100 010 001
MSB LSB
Ключ:
1 1512622351721
хеш с ключом:
26202666263870266 1 1512622351721
Сравнивая теперь ключи
bob@commandus.com - 1 1512622351721
alice@commandus.com – 1 51262235162333
видно, что выравнивание на триаду позволило достичь того, что однодоменные имена имеют одинаковое начало ключа.
5.6. Замечание для случая нулевого ключа
В случае если вычисленный ключ равен 0, он все равно указывается:
8 space 0
или
9 space 0
для инвертированного адреса.
5.7. Расширение
Для некоторых адресов Хеш и Ключ вместе составляют последовательность цифр, короче 16 символов и, чтобы отличать их от “локальных” номеров и от “глобальных” номеров стандарта E.164 [5], в таком случае в конце последовательности должны быть добавлены цифры “9″, так чтобы число цифр стало равно 16.
extension:= {”9″}
Для локальных адресов расширение может выравнивать номер телефона, но общее число цифр может быть меньше 16.
5.8. Номер сервиса
Формат номера сервиса:
service_number:= address|hash space [key] [extension]
5.9. Запись
Хеш и Ключ вместе составляют последовательность цифр, которую Пользователь набирает на номеронабирателе. Эта последовательность записывается в следующем виде:
record:= “ics:” serviceNumber
Например:
ics:bob@commandus.com 8 40126055421
(первая форма записи). ICS – это аббревиатура Internet Code of Service.
Допускается запись и во второй форме:
ics:26202666263870266 8 40126055421
При такой записи, однако, рекомендуется использовать предварительно инвертированный адрес (см. пункт 6).
6. Предварительно инвертированный адрес
Например, для адреса:
alice@commandus.com
инвертированный адрес получается обратной перестановкой слов:
com.commandus@Alice
и хеш его начинается с:
2660266626387025423
Для адреса
bob@commandus.com
Хеш будет:
26602666263870262
В инвертированном адресе Хеш начинается с одной и той же последовательности цифр, где 2660 - .com, 2666263870 – commandus, что делает его удобным для записи во второй форме.
7. Декодирование
7.1. Определение, является ли число номером сервиса
Если длина номера больше или равно 16, введенный номер является номером сервиса. Или устройство, инициирующее вызов (SIP телефон), или коммутатор вызывающей стороны должны декодировать номер сервиса в адрес.
Так как в декодированном адресе может отсутствовать имя протокола, телефон или коммутатор должны назначить протокол в соответствии с собственными правилами. Например, для,
bob@commandus.com
может быть назначен протокол SIP:
sip:bob@commandus.com
Хотя в номере сервиса может быть закодирован протокол, а также другая информация, рекомендуется по возможности сокращать длину строки адреса. Это позволит использовать один номер сервиса для нескольких протоколов:
sip:bob@commandus.com
mailto:bob@commandus.com
http://bob@commandus.com/
ftp://bob@commandus.com/
Соответствующее устройство может предлагать выбирать желаемые протоколы.
По умолчанию РЕКОМЕНДУЕТСЯ использовать протокол SIP.
7.2. Удаление расширения
Если в конце номера сервиса есть символы “9″, они удаляются.
7.3. Определение начала ключа
Декодирование начинается с определения начала ключа. Для этого надо начать искать с конца символ ‘8’ или ‘9’
26202666263870266 8 401511240610
Здесь используется то, что Ключ содержит только символы “0″ .. “7″.
Ключ:
8 401511240610
Символ начала Ключа ‘8’ удаляется.
Так как символ начала ключа был ‘8’, а не ‘9’, адрес не был предварительно инвертирован, поэтому выполняем инверсию адреса.
Выделяем в Хеше:
26202666263870266
символы “0″ (символы 0 также считаются хешами отдельных слов):
262 0 266626387 0 266
и копируем разделяемые ими слова в строку в обратном порядке:
266 0 266626387 0 262
Если бы символ начала ключа был ‘9’, адрес был предварительно инвертирован, и инвертировать адрес не надо было бы.
Определяем по младшим двум битам ключа количество дополнительных выравнивающих бит – 1. Сдвигаем вправо на 3 бита выравнивания ключ, удаляя один дополнительный и два бита длины выравнивания.
Теперь последовательно для каждого символа инвертированного хеша выделяем битовыми масками нужные биты ключа (количество бит дано в таблице 2), и по этой же таблице определяем символ. Получается:
com.commandus@bob
Теперь остается переставить слова еще один раз. Получается:
bob@commandus.com
Так как символ начала ключа был ‘8’, а не “9″, это был не предварительно инвертированный адрес, поэтому была нужна еще одна пересатновка.
8. Кодировки
8.1. Регистр букв адреса
Буквы адреса считаются находящимися в нижнем регистре. Если требуется вводить буквы в верхнем регистре, они должны быть закодированы, как специальные символы (пункт 8.3).
8.2. Национальные кодировки в адресе
Символы в кодировках, отличных от латиницы должны быть закодированы, как специальные символы (пункт 8.3).
8.3. Кодирование специальных символов
Адрес может содержать символы латиницы, не перечисленные в таблице 1, специальные символы и символы в Unicode. Такие символы ДОЛЖНЫ быть закодированы символами латиницы, как требует RFC 2396 [3], например:
%20 - символ пробела
%u20AC - знак евро
9. Поиск в адресных книгах
Поиск в адресных книгах имеет целью:
дополнить адрес (как в примере выше, добавить домен @commandus.com к alice), как показано в сценариях 1 и 2 (пункты 3.1 и 3.2);
устранить неоднозначность Хеша без ввода Ключа.
Поиск в адресных книгах является необязательным.
9.1. Приложения адресных книг
Адресными книгами могут быть процедуры, приложения и сетевые ресурсы, использующие следующие источники адресов:
директории LDAP сервера;
DNS серверы, в том числе реализующие получение доменных имен для телефонных номеров E.164, как регламентировано в RFC 3761 [5];
DNS кэш устройства или заданного компьютера;
Специальные приложения, например, использующие историю посещений веб страниц браузера Интернет, или собранные адреса SIP шлюза, e-mail почтовой клиентской или серверной программ, прокси серверов и шлюзов, или отображаемые в данный момент в приложении (браузере) SIP и другие Интернет адреса.
9.2. Иерархия адресных книг
Адресных книг может быть больше одного. Поиск осуществляется последовательно в адресных книгах в определенном порядке, задаваемым списком адресных книг. Устройство МОЖЕТ хранить у себя или во внешних сервисах несколько списков адресных книг, Пользователь или устройство автоматически условно или, безусловно, могут переключать списки.
Только один список может применяться в каждый данный момент времени.
Если ни в одной из адресных книг, перечисленных в списке, вхождения не найдены, это НЕ является условием переключения списков.
Рекомендуется по умолчанию начинать поиск в адресной книге самого устройства, затем во внешних адресных книгах.
Пользователь или устройство автоматически могут удалять и подключать новые адресные книги, и если нельзя определить иначе, по умолчанию новая адресная книга ДОЛЖНА подключаться к концу текущего списка адресных книг.
Устройство или приложение вычисляет хеш адресов из адресной книги, используя табл. 1, затем ищет вхождения введенного начала кода как подстроки в вычисленных хешах для записей адресной книги.
Если обнаружено одно вхождение введенного хеша с вычисленными хешами в одной адресной книге, Устройство ДОЛЖНО использовать адрес из адресной книги.
Если обнаружено несколько совпадений введенного Хеша с вычисленными хешами для одной адресной книги, Устройство ДОЛЖНО вычислить весовые коэффициенты для вхождений, отсортировать полученные адреса по весу, затем предложить выбрать из полученного списка Пользователю нужный адрес.
9.3. Запоминание новых Хешей и Ключей
Если хеш не найден ни в одной из адресных книг, Пользователь должен продолжить ввод – ввести ключ.
Адресная книга нижнего уровня должна запомнить хеш и ключ с тем, чтобы в следующий раз пользователь мог избежать ввода ключа. При этом должен быть реализован какой либо механизм удаления неиспользуемых Хешей и Ключей.
9.4. Коллизии хеша
В случае если Хеш в адресной книге одинаков для нескольких записей, Пользователю должно быть предложено выбрать из списка нужную запись, если этот список короче 10 записей. Если адресная книга содержит 10 или более записей с таким же Хешем, Пользователю МОЖЕТ быть предложено ввести ключ.
10. Безопасность
Нет требований по безопасности, указанных в пункте 7 RFC 2327.
11. Благодарности
Автор благодарит людей, оказавших помощь в создании документа.
12. Нормирующие документы
1.Bradner, S., “The Internet Standards Process — Revision 3″, BCP 9, RFC 2026, October 1996.
2.Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
3.Berners-Lee, T., Fielding, R.T. and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998. Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
4.Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002.
5.Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
6.Marc Spencer. Distributed Universal Number Discovery (DUNDi), October 2004.
7.Crocker, D. and Overell, P.(Editors), “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997.

Адрес автора
Andrei Ivanov
Commandus software development group
Petrovskogo street 2, Yakutsk, Republic Sakha, Russian Federation
email: support@commandus.com
http://commandus.com/

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

About Us | Site Map | Privacy Policy | Contact Us | Copyright © 2007-2011 Commandus software development group . All rights reserved. Powered by WordPress