Re: draft-shemsedinov-usp-05.txt

DC> Given that that they are seeking Informational, rather than standards track,
DC> I assume that an IETF review should focus on whether the specification has
DC> misrepresentations and whether it conflicts in dangerous ways with any IETF
DC> effort. I assume that the IETF should NOT offer any standards-oriented
DC> language, such as "this looks like a useful protocol".

We have chosen Informational, because it describes that is already developed.
If we shall see such necessity and if this protocol will be useful, it is
possible to advance it up to standards track. In this case, it is necessary
to apply a set of RFC published standards for improvement of the protocol,
especially solving security problems.

DC> So, my own reading is:
DC> This is a thoughtful effort that discusses related efforts. It states what
DC> problem it is trying to solve and it states its reasons for its technical
DC> choices.
DC> I am not aware of any conflicts or misrepresentations from this work.
DC> For work of this sort done now, it is surprising that the specification
DC> invents a new syntax, rather than using XML. However is nothing "dangerous"
DC> or otherwise inappropriate in the syntax choice they have made.

There are enough reasons to invent a new syntax instead of use XML.
You can see in practice, how big and heavy the XML-based RPC calls looks
like (XMLRPC and SOAP). I believe that XML has all possibilities for
a complex data structure definition, however it does not provide sufficient
possibilities, fixed at a syntax level, for the object definition.
It is possible to describe objects, but there is some freedom degree
in the invention of ways to do it. Have you noticed that there are many
XML-based technologies, however they are incompatible with each other.
XML does not provide node types in hierarchical structures, however
nodes can represent either object or property or container for other
objects. USP gives three levels of node classification:
  1. node essence (part, object, member, folder)
  2. node data type (plain, multipart, table, file, array)
  3. node class
I could give examples demonstrating advantages such syntax, its
representational abilities and definition size reduction.
But I believe that RFC publication is not a right place for such
discourse.


Best regards,
Timur
mailto:Timur@niist.ntu-kpi.kiev.ua

Received on Wednesday, 6 November 2002 08:20:54 UTC