Централизованый формат снифов

[Konctantin]

Редакция от 31 июля 2011, 13:13, версия 3.1

• 1. RAW.
  • 1.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'RAW'.
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; 
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 1.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint sessionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

• 2. PKT.
  • 2.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'PKT'
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; // может быть заполнено нулями
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 2.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint sessionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

    , где
    - data включает в себя Opcode, выравненный до uint
    - dataLength равен размеру data
  
  
• 3. Имя файла.
  • 3.1. имя файла
    имя может быть произвольным и удобным каждому из разработчиков.
    
  • 3.2. расширение файла
    обязательно .raw или .pkt

Редакция от 25 июля 2010, 21:00, версия 3.0

• 1. RAW.
  • 1.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'RAW'.
      byte version[2]; // 0x00, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; 
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 1.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint unixTime;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

• 2. PKT.
  • 2.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'PKT'
      byte version[2]; // 0x00, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; // может быть заполнено нулями
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 2.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint unixTime;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

    , где
    - data включает в себя Opcode, выравненный до uint
    - dataLength равен размеру data

Предложения
SnifferID:

0 - Wad // 2005 и ранее
1 - Nomad // 2005 и ранее
2 - WoWCore // 2006
3 - Mangos (TOM_RUS) // 2006
4 - User456 // 2007
5 - Delfin // 2007
6 - Burlex // 2007
7 - WCell // 2008
8 - Kobold // 2009
9 - abdula123 // 2010
10 - Konctantin/LordJZ // 2010
11 - Йоха // 2010

[RomanRom2]

Сообщение от LordJZ

RomanRom2, только опкод все-равно форматируем до 32 бит, ага?

да, пусть будет.

помести пожалуйста в первое сообщение форматированный документ с описанием и с последними предложениями.

[Йоха]

коллеги, а для чего в снифе девелоперс дата ?

[LordJZ]

И так, на последний момент:


Заголовок файла:

byte signature[3]; // 'PKT' | 'RAW'.
word version; // == 0x0003 - для версии 3.0.
byte snifferID; // Распределить уникальные номера. — это надо решить.
uint build; // Номер сборки клиента, обратите внимание, тип uint (4 байта). — зачем 4 байта?
byte language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
byte sessionKey[40]; // Ключ сессии, для PKT не используется и может быть заполнен как угодно (лучше нулями).
byte OptionalHeaderLength;
byte optionalHeader[];

Заголовок пакета:

(byte)Direction; // 0xFF — серверный, 0xCC — клиентский
(uint)UnixTime
(uint)TickCount
(uint)OptionalHeader.Length
(uint)Data.Length
(byte[])OptionalHeader
(byte[])Data — предлагаю именно такой порядок: длина DD, длина данных, DD, данные.
            Данные включают в себя опкод, выравненный до 32 бит.

____________

коллеги, а для чего в снифе девелоперс дата ?

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

[VDm]

Предлагаю так же учесть доводы user456 насчет указания направления пакета, и расширить это поле с 1 до 4 байт, заодно, сделав размер заголовка чанка кратным 4:

struct ChunkHeader
{
  char direction[4]; // 'RECV' и 'SEND', либо 'SMSG' и 'CMSG', либо то, что вы предложите.
  uint unixTime;
  uint tickCount;
  uint optionalDataLength;
  uint dataLength;
};
// sizeof(ChunkHeader) == 4 + 4 + 4 + 4 + 4 = 20 байт (align == 1)

Сразу после ChunkHeader следуют optional-данные, затем данные пакета.

P.S. Подстроился с учетом мнения LordJZ о порядке следования данных.

[RomanRom2]

еще одно из доводов user456:
цитирую:
я бы выкинул из каждого пакета и UnixTime
есть стартовый и тиккаунты

[VDm]

Сообщение от LordJZ

И так, на последний момент:
зачем 4 байта?

Конечно, сомнительно, что номера сборок превысят 65 535, но я увидел uint в описании у RomanRom2.

[Йоха]

по поводу byte SnifferID - иожет сделать не 1 байт, а немного длинней, и хранить там символьное представление, например "wcore"
Просто придумывать номера ID - это еще 1 стандарт, кто его будет поддерживать ? а так каждый сниферописатель придумает какое-нибудь символьное сокращение для своего детища

[RomanRom2]

Сообщение от VDm

Предлагаю так же учесть доводы user456 насчет указания направления пакета, и расширить это поле с 1 до 4 байт, заодно, сделав размер заголовка чанка кратным 4:

struct ChunkHeader
{
  char direction[4]; // 'RECV' и 'SEND', либо 'SMSG' и 'CMSG', либо то, что вы предложите.

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

Сообщение от VDm

Конечно, сомнительно, что номера сборок превысят 65 535, но я увидел uint в описании у RomanRom2.

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

Сообщение от Йоха

по поводу byte SnifferID - иожет сделать не 1 байт, а немного длинней, и хранить там символьное представление

а это ничего не меняет. какая то сигнатура будет вместо 1 байта. а кто будет поддерживать эти сигнатуры? точно так же их надо будет описывать где то.

Сообщение от LordJZ

И так, на последний момент:
— предлагаю именно такой порядок: длина DD, длина данных, DD, данные.
Данные включают в себя опкод, выравненный до 32 бит.

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

[user456]

Сообщение от RomanRom2

господа, поступило шикарное предложение по формату чанка:

(byte)Direction;
(uint)UnixTime
(uint)TickCount
(uint)Data.Length
(uint)DD.Length
(byte[])Data
(byte[])DD

Да, если слишком кратко излагать - не доходит. Развернуто:
struct main_hdr{
int sign;
uint pkt_hdr_offset;
uint pkt_hdr_len;
uint data_offset;
...
}

struct pkt_hdr_node{
int len;
char [50] name;
}

потом с адреса pkt_hdr_offset забиваеш массив и получаеш свои типы, можно по name разбор делать или добавить константы типа. Получится структура велосипеда, который давно изобрели в каком-нибудь DBase.
Один фиг через год станет понятно что UnixTime в каждом пакете это мусор (достаточно тиккаунтов на четверо суток в миллисекундах и даты создания файла или одного time в хедере)

[VDm]

Сообщение от user456

Да, если слишком кратко излагать - не доходит.

Сложно, если это кому-то потребуется, пусть задает optionalData, а там - что угодно и сколько угодно.

[VDm]

По историческим соображениям, описанным здесь: http://www.gotwow.ic.cz/
Пытаемся составить список SnifferID (SnifferID получается так же при конвертации данных от команды, не имеющей совместимости с данным форматом):

0x00 - Wad // 2005 и ранее
0x01 - Nomad // 2005 и ранее
0x02 - WoWCore // 2005
0x03 - Mangos (TOM_RUS) // 2005, намеренно не отделяю по времени TOM_RUS от Mangos
0x04 - User456 // 2006
0x05 - Delfin // 2006
0x06 - Burlex // Хотя начинал он явно раньше, я точно не знаю, когда.
0x07 - WCell
0x08 - LordJZ
0x09 - Йоха // 2010
0x0A - abdula123 // 2010

Если кого-то забыл или не туда записал, отпишитесь.

[user456]

Сообщение от VDm

Если кого-то забыл или не туда записал, отпишитесь.

Да просто поле символов 25 оставь и все. А там уже WoWCore v 3.xx внутри или типа того.

P.S. бурлеха еще забыл.

[RomanRom2]

позволил себе обновить первый пост в связи с последними изменениями.

Сообщение от user456

P.S. бурлеха еще забыл.

я думаю что бурлекс меньше всего будет этому придерживаться и что ему глубоко фиолетово на все это.

[LordJZ]

Сообщение от VDm

По историческим соображениям, описанным здесь: http://www.gotwow.ic.cz/
Пытаемся составить список SnifferID (SnifferID получается так же при конвертации данных от команды, не имеющей совместимости с данным форматом):

0x00 - Wad // 2005 и ранее
0x01 - Nomad // 2005 и ранее
0x02 - WoWCore // 2005
0x03 - Mangos (TOM_RUS) // 2005, намеренно не отделяю по времени TOM_RUS от Mangos
0x04 - User456 // 2006
0x05 - Delfin // 2006
0x06 - Burlex // Хотя начинал он явно раньше, я точно не знаю, когда.
0x07 - WCell
0x08 - LordJZ
0x09 - Йоха // 2010
0x0A - abdula123 // 2010

Если кого-то забыл или не туда записал, отпишитесь.

WowCore вроде-бы 6-ку и использует (со слов RomanRom2)

[VDm]

Сообщение от LordJZ

WowCore вроде-бы 6-ку и использует (со слов RomanRom2)

Мы посчитали, что использовать в качестве SnifferID - номер командры разработчиков, а не номер их программы (у одной команды может быть несколько разных программ), будет более правильно.

[RomanRom2]

Сообщение от LordJZ

WowCore вроде-бы 6-ку и использует (со слов RomanRom2)

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

[user456]

Ну а признак что сниф не левый с эмулей? А то мы с ромкой в аське вроде со своими мыслями согласились...
И вопрос, обсуждаемый между собой, но не вошедший сюда:
1. снифами скорее всего делиться никто не будет, не только от жадности но и чтобы не получать баны
2. отсюда мы вроде как согласились что если что и шарить, то сразу пакеты респонсов и подобного
3. откуда следует что инфа должна быть заранее обработана и обсуждение формата пакетов raw вроде бури в стакане воды

Итого: смысл обсуждать? Только в случае одинаковых на всех обработчиков сниффов. У нас с ним по-любому будут разные. Он заряжает тулзу, которая буквами выводит "ну ты и крут, еще 500 айтемов". Я если тащу, так вытаскиваю всю нужную именно мне инфу (последовательно обрабатывая можно много чего еще вытащить). Даже не юзаю тиккаунты потому что в каждом пятом пакете они есть.

[RomanRom2]

вовк, на самом деле ситуация немного проще:

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

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

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

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

так что респонсы и всякие А9 (заселенку) можно легко и смело шарить. т.е. писать такой тул, которому скармливается снифф и который оставляет вот эти пакеты. т.е. пакеты, которые явно не спалят аккаунт, пакеты, в которых отсуствует гуид перса, его имя и т.п. в этом нам нужно соревноваться, я считаю. т.е. КАК СДЕЛАНО, а не СКОЛЬКО.

но шаринг снифов - это всего лишь вопрос времени, мне кажется. рано или поздно все поймут, что от того что у тебя прямо сейчас есть в базе итем 77777 или стоит моб в какой то локации, а у меня нет - не делает твой сервер "круче", назовем это так. но это все конечно возможно не случится никогда

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

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

так что буря в стакане возможно и выглядет утопичной, но возьми например jpeg, или там mp3. все по своему и по разному их "обрабатывают". paint по проще, photoshop по круче. ну и что. так что я считаю все равно это создаст некоторое удобство. время покажет, какое именно.

[Konctantin]

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

А так, он совершенно бесполезен (пример, wdb-cache, на данный момент мало кто его может прочитать).

[RomanRom2]

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

[Konctantin]

а сейчас тему видно? отпишитесь кто нибудь...

[Fmut]

а смысл этого всего если не выкладывать снифы тоннами в паблик? да и желательно сам снифер давать в паблик, иначе тонн снифов небудет.

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

[RomanRom2]

Сообщение от Fmut

а смысл этого всего если не выкладывать снифы тоннами в паблик? да и желательно сам снифер давать в паблик, иначе тонн снифов небудет.

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

Сообщение от Fmut

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

хмм... и обработчик второго соединения нашел? у нас что то не получилось. наш инжектор видит только первую сессию.

[Konctantin]

смысл есть всегда, давайте простой пример:
идет обсуждение чего-то, надо пример сниффа с оффа, вы выкладываете этот снифф, и все, кому надо смогут прочитать его, и можно на основании конкретных данных вести конструктивную беседу.

[Fmut]

Как Ромка уже и сказал, в снифах самое ценное данные для респонзов и заселения.

И насчет общего вклада в единое целое, раз уж так опасно выкладывать снифы, можно выкладывать данные.
Сделать единую базу с официальными данными без custom-полей и привязки к конкретному проекту.
И парсилку этой базы со снифов можно написать и централизованно.

А мелкие снифы определенных механик особо и не нужно выкладывать в паблик, каждый сам может отснифать, да и устаревают они быстро.

А как насчет англоязычного коммунити? До них эту идею донесли или они сами по себе как обычно?

[Dereka]

Сообщение от munche

А как насчет англоязычного коммунити? До них эту идею донесли или они сами по себе как обычно?

сейчас из этого комьюнити только wcell и trinity
и если, как говорит Авен, "сделать единую базу с официальными данными без custom-полей и привязки к конкретному проекту" они всё равно узнают про эту базу, им будет выгодно делать такой же формат снифов.. правда нужно будет формат задокументировать на англицком

кстати забыли в этом списке про кобольд

0x00 - Wad // 2005 и ранее
0x01 - Nomad // 2005 и ранее
0x02 - WoWCore // 2005
0x03 - Mangos (TOM_RUS) // 2005, намеренно не отделяю по времени TOM_RUS от Mangos
0x04 - User456 // 2006
0x05 - Delfin // 2006
0x06 - Burlex // Хотя начинал он явно раньше, я точно не знаю, когда.
0x07 - WCell
0x08 - LordJZ
0x09 - Йоха // 2010
0x0A - abdula123 // 2010

[Nomad]

Сообщение от RomanRom2

у тебя есть CMSG_AUTH_SESSION с именем аккунта

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

[RomanRom2]

Сообщение от Dereka

сейчас из этого комьюнити только wcell и trinity
они всё равно узнают про эту базу, им будет выгодно делать такой же формат снифов..

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

Сообщение от Dereka

кстати забыли в этом списке про кобольд

мы разве исторический список эмуляторов составляем? в таком случае, что мангос, что тринити, что кобольд, что вовд, что штормкрафт - одна фигня. а еще забыли какого нить wowwow, да много кого

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

на самом деле это не важно, список чистая формальность. главное - формат разработали. и лично мне он очень даже нравится. и как прется с него WoWCore Team - тоже не пересказать )) и самое главное - мы его ВМЕСТЕ сделали. и что ж - кажется можно считать, что обсуждение закончено, кажется добавить уже нечего. можно ускорить процесс - можно считать что документ разработан и начать его ревью. скажем до конца месяца, до 31 июля.

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

[LordJZ]

Они же другие форматы используют (sqlite, xml)


P.S. Может действительно использовать использовать не один байт на идентификатор сниффера, а несколько, или может вообще строку?

[RomanRom2]

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

Сообщение от LordJZ

P.S. Может действительно использовать использовать не один байт на идентификатор сниффера, а несколько, или может вообще строку?

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

[Dereka]

Сообщение от RomanRom2

мы разве исторический список эмуляторов составляем? в таком случае, что мангос, что тринити, что кобольд, что вовд, что штормкрафт - одна фигня. а еще забыли какого нить wowwow, да много кого

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

не так меня понял..
у кобольдов свой формат снифов это 100%.. и снифер вроде свой был.
Месяца полтора к ним не заходил, не знаю как у них сейчас обстоят дела))

[LordJZ]

В таком случае дополнений/предложений не имею.

[Konctantin]

кеп, голос отдан вам - "ДА".

[VDm]

Сообщение от Dereka

не так меня понял..
у кобольдов свой формат снифов это 100%.. и снифер вроде свой был.
Месяца полтора к ним не заходил, не знаю как у них сейчас обстоят дела))

В таком случае, ничто не мешает и им присвоить snifferID.
До тех пор, пока формат окончательно не утвержден, в списке могут быть подвижки (с поправкой на "давность" команды), после утверждения данный список может быть увеличен только путем добавления номера в конец.

[zergtmn]

PHP код:

struct MainHeader
{
  char signature***91;3***93;; // 'RAW'.
  word version; // 0x0003
  byte snifferID; 
  uint build; 
  char language***91;4***93;; // Язык клиента: 'ruRU', 'enGB' и т.д.
  byte sessionKey***91;40***93;; 
  uint optionalHeaderLength; 
}; 


Зачем так экономить байты в хидере? Можно до dword'ов округлить все поля, вдруг захочется хранить версию или snifferID немного по другому, но не теряя совместимости? До 64 байт очень хорошо округляется

[VDm]

Сообщение от zergtmn

Зачем так экономить байты в хидере? Можно до dword'ов округлить все поля, вдруг захочется хранить версию или snifferID немного по другому, но не теряя совместимости? До 64 байт очень хорошо округляется

Это не совсем так, дело в том, что формат не просто так имеет версию 3, есть, например, версии 2.0, 2.1. В них первые пять байт - это сигнатура(3) + версия(2), эти поля менять точно нельзя, иначе существующие программные решения не смогут понять о какой версии идет речь.
На фоне этого, смысл расширять snifferID теряется. Мы уже говорили, что практическое значение snifferID крайне невелико, каждая команда разработчиков имеет полную свободу самовыражения в optionalHeader и optionalData.

Сообщение от Dereka

не так меня понял..
у кобольдов свой формат снифов это 100%.. и снифер вроде свой был.
Месяца полтора к ним не заходил, не знаю как у них сейчас обстоят дела))

Спасибо, Дерека. Я в тебе не сомневался )) Ты один из тех немногих, которых я уважаю как людей. Ну да ладно...
Тут в чем дело.. К нам именно по этому сабжу никаких предложений не поступало. Да и нужно ли это им? )
Эта тема для Мангос и Ко или же для всего эму коммунити? Я думаю все же первое..

[Йоха]

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

[Konctantin]

Эта тема для Мангос и Ко или же для всего эму коммунити? Я думаю все же первое..

нет, это не первое, это для всех...

Главное во всем этом то, что люди будут придерживаться некоего единого стандарта, а уж какой там сам стандарт - это не столь важно

придерживаться будут, если все будет устраивать, как раз в этом смысл всей этой дискуссии...

Перенес список ревьюверов в первый пост.