Перевод timeMarker.org на английский

Опять же, возникает микс терминов. По-русски вы часто можете сказать как "метка времени", так и "штамп времени". Различие между ними должно быть объяснено в тексте. Лично мне кажется, что нужно оставить только устояшийся timestump и не плодить сущностей.

Timestump? Timestamp.

SATtva, спасибо за перевод.

Опять же, возникает микс терминов. По-русски вы часто можете сказать как "метка времени", так и "штамп времени"

Насколько правильно будет писать везде где можно не Timestamp а TimeMarker?

Насколько правильно будет писать везде где можно не Timestamp а TimeMarker?

Насколько, насколько будет писать везде где можно не "штамп", а "маркировщик".
[offtop]Насколько правильно будет, владея "печатным станком" (матрицей, однако) писать везде где можно о том, как это хорошо – владеть "деньгами"?[/offtop]

А причем "штамп" – реч идет о "метка"
Marker – ориентировочный знак, метка, зарубка

Timestamp — устоявшийся термин. Mark в данном контексте это скорее "маркировка", но никак не "метка". TimeMarker сойдёт для названия сервиса, но подменять общепринятую терминологию не следует.

Предлагаю сразу учесть важный аспект локализации: в разных странах принят разный порядок записания дня и номера месяца (в частности, в США номер месяца идёт вначале: ММ. ДД. ГГ). Лучше всего сразу принять конкретный формат и предлагать указывать дату согласно нему: Enter dates range in format DD. MM. YYYY. Также, если сервис станет популярен, то может начать выдавать десятки меток в день; тогда желательно обеспечить возможность указания не только даты, но и времени, метки с которого должны быть включены в цепочку.

Формат даты зависит от локализации. Я думаю будет разумно оставить его именно таким. Каждая страна вводит даты так как в ней принято (в данном случае Россия и Великобритания).
Тогда можно использовать стандартные проверки на ввод даты, которые учитывают что в году не больше 12 месяцев и т.п.

На счет указания времени – сделать такой поиск не составит труда, вся сложность проверить ввод. Придется писать здоровое регулярное выражение, учитывающее и сколько дней в определенном месяце и високосный год, и сколько секунд в минуте.
Думаю что пока такая возможность не так уж нужна, точный поиск можно производить по номерам.


Еще не решены следующие задачи:
– переносы строк в Unix стиле,
– API доступа к сервису, что бы можно было делать системы запрашивающие метки времени автоматически.
Например, можно заверять меткой времени хеши файлов, для контроля их целостности – тогда даже собственному админу будет затруднительно подсунуть измененный файл.
– сгрины страниц Интернета заверенные с помощью метки времени (отдаленное будущее).

Формат даты зависит от локализации. Я думаю будет разумно оставить его именно таким.

Я не предлагал менять формат с ДД.ММ на ММ.ДД, а только явно указать в пояснении, какой формат пользователь должен применять.

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

Не прокатит: 02.04.2008 — это второе апреля или четвёртое февраля? Предлагаю всё же просто указать формат ввода в пояснении к веб-форме. Если пользователь накосячил — это уже его проблема.

Еще не решены следующие задачи ... переносы строк в Unix стиле

Это как раз OpenPGP Text Mode. Разве в BCPG нет поддержки канонического текста?

Это как раз OpenPGP Text Mode. Разве в BCPG нет поддержки канонического текста?

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

Если я правильно понял, то нужно определить операционную систему пользователя и при формировании документа вставлять нужные символы переноса строк.


OpenPGP Text Mode позволяет использовать при подписании одни переносы строк, а при проверке подписи эти символы могут быть заменены на любые другие?

OpenPGP Text Mode позволяет использовать при подписании одни переносы строк, а при проверке подписи эти символы могут быть заменены на любые другие?

Именно так. OpenPGP-программа пользователя подставит те символы переноса, которые характерны для его ОС. Поэтому не суть важно, как переносы будут оформлены в заверенных метках.

Все равно не очень понимаю. Человек под unix загрузил документ и открывает его аналогом виндовского блокнота — он увидит неверные переносы строк, т.е. те которые поставлены при формировании.

Может просто заменить все "\n\t" на "\n" windows вроде нормально реагирует на таки переносы.

В unix он, кстати, и не заметит разницы — тот же less понимает и \n, и \r\n (о браузерах вообще молчу). При простом открытии метки из скачанного файла пользователь получит именно те переносы, которые были проставлены сервером. Но когда он сверит подпись, OpenPGP программа заменит исходные переносы на нативные для данной ОС (OpenPGP пакет канонического текста говорит программе именно о том, что она может переоформить символы переноса строк, если они не соответствуют стандарту данной ОС, подробнее здесь).

Сейчас этого с полученными метками не происходит?

При создании подписи я указываю в качестве одного из параметров PgpSignature. CanonicalTextDocument, что наверня означает как раз то о чем вы говорите.


Сейчас под unix пожно проверять метки?

В Линуксе, к сожалению, не удаётся распаковать архив с метками, получаю ошибку "need PK compat. v4.5 (can do v2.1)".

Но при получении собственной метки процесс проходит на "ура":

$ cat Marker40.pgp -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timestamp-version: ver1.0 Description: timestamp Signed-by: URL Timestamp: Wed, 23 Apr 2008 09:24:11 GMT Number: 40 Ref-Hash-SHA512: 20c37ec776e7e8e198865ceb67f2030792e13acd4cd0071adebb05c7e10f57e73e6f1d7f161bd18775ffa6912e0476463bfcd78d5a8249036db1643a8796aa55 Ref-Hash-RIPEMD160: 0c7dcc2c15c48d47b0405b6dedda14866980049e Hash-SHA512: ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff Hash-RIPEMD160: 5e52fee47e6b070565f74372468cdc699de89107 ############## Timestamped data follows ############### test -----BEGIN PGP SIGNATURE----- Version: BCPG v1.32 iEYEARECAAYFAkgPADwACgkQwHdhZboxozN7KgCdGEi+/dU3LvPeZGlDd7H4WmA1 Hp8An1fPE132Lc4MPj+9HbKIRC/5C3uz=VbeX -----END PGP SIGNATURE----- $ gpg -d Marker40.pgp Hash: SHA1 gpg: armor header: Version: BCPG v1.32 gpg: armor header: gpg: original file name='' Timestamp-version: ver1.0 Description: timestamp Signed-by: URL Timestamp: Wed, 23 Apr 2008 09:24:11 GMT Number: 40 Ref-Hash-SHA512: 20c37ec776e7e8e198865ceb67f2030792e13acd4cd0071adebb05c7e10f57e73e6f1d7f161bd18775ffa6912e0476463bfcd78d5a8249036db1643a8796aa55 Ref-Hash-RIPEMD160: 0c7dcc2c15c48d47b0405b6dedda14866980049e Hash-SHA512: ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff Hash-RIPEMD160: 5e52fee47e6b070565f74372468cdc699de89107 ############## Timestamped data follows ############### test gpg: Signature made Срд 23 Апр 2008 16:24:12 NOVST using DSA key ID BA31A333 gpg: Good signature from "TestStamperKey2 (Test time-stamper key) <t@t.tt>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E400 44ED B961 9F24 05E7 ABDD C077 6165 BA31 A333 gpg: textmode signature, digest algorithm SHA1

gpg: textmode signature в конце говорит о том, что данные были подписаны как канонический текст. Всё правильно.

В Линуксе, к сожалению, не удаётся распаковать архив с метками, получаю ошибку "need PK compat. v4.5 (can do v2.1)".

Попробуйте пожалуйста теперь – я поправил, должно быть в порядке.