FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
FIPA
ACL Message Representation in
Bit-Efficient Encoding Specification
|
Document title |
FIPA ACL Message Representation in Bit-Efficient Encoding Specification |
||
|
Document number |
XC00069F |
Document source |
FIPA TC Agent Management |
|
Document status |
Experimental |
Date of this status |
2002/11/01 |
|
Supersedes |
FIPA00024 |
||
|
Contact |
fab@fipa.org |
||
|
Change history |
See Informative Annex A — ChangeLog |
||
©
1996-2002 Foundation for Intelligent Physical Agents
http://www.fipa.org/
Geneva, Switzerland
|
Notice |
|
Use of the technologies described in this specification may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of this specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This specification is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of this specification. |
Foreword
The Foundation for Intelligent Physical Agents (FIPA) is an international organization that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. This occurs through open collaboration among its member organizations, which are companies and universities that are active in the field of agents. FIPA makes the results of its activities available to all interested parties and intends to contribute its results to the appropriate formal standards bodies where appropriate.
The members of FIPA are individually and collectively committed to open competition in the development of agent-based applications, services and equipment. Membership in FIPA is open to any corporation and individual firm, partnership, governmental body or international organization without restriction. In particular, members are not bound to implement or use specific agent-based standards, recommendations and FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through direct involvement of the FIPA membership. The status of a specification can be either Preliminary, Experimental, Standard, Deprecated or Obsolete. More detail about the process of specification may be found in the FIPA Document Policy [f-out-00000] and the FIPA Specifications Policy [f-out-00003]. A complete overview of the FIPA specifications and their current status may be found on the FIPA Web site.
FIPA is a non-profit association registered in Geneva, Switzerland. As of June 2002, the 56 members of FIPA represented many countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found on the FIPA Web site at http://www.fipa.org/.
Contents
2 Bit-Efficient ACL Representation
2.4 Notes on the Grammar Rules
This document deals with message transportation between inter-operating agents and also forms part of the FIPA Agent Management Specification [FIPA00023]. It contains specifications for:
· Syntactic representation of ACL in a bit-efficient form.
This section defines the message transport syntax for a bit-efficient encoding which is expressed in standard EBNF format[1] (see Table 1).
|
Grammar rule component |
Example |
|
Terminal tokens are enclosed in double quotes |
"(" |
|
Non-terminals are written as capitalised identifiers |
Expression |
|
Square brackets denote an optional construct |
[ "," OptionalArg ] |
|
Vertical bars denote an alternative between choices |
Integer | Float |
|
Asterisk denotes zero or more repetitions of the preceding expression |
Digit* |
|
Plus denotes one or more repetitions of the preceding expression |
Alpha+ |
|
Parentheses are used to group expansions |
( A | B )* |
|
Productions are written with the non-terminal name on the left-hand side, expansion on the right-hand side and terminated by a full stop |
ANonTerminal = "terminal". |
|
0x?? is a hexadecimal byte |
0x00 |
Table 1: EBNF Rules
The name assigned to this component is:
fipa.acl.rep.bitefficient.std
ACLCommunicativeAct = Message.
Message = Header MessageType MessageParameter* EndofMsg.
Header = MessageId Version.
MessageId = 0xFA
| 0xFB
| 0xFC. /* See comment 1 below */
Version = Byte. /* See comment 2 below */
EndofMsg = EndOfCollection.
EndOfCollection = 0x01.
MessageType = PredefinedMsgType
| UserDefinedMsgType. /* See comment 3 below */
UserDefinedMsgType = 0x00 MsgTypeName.
MsgTypeName = BinWord.
MessageParameter = PredefinedParam
| UserDefinedMsgParam. /* See comment 4 below */
UserDefinedMsgParam = 0x00 ParameterName ParameterValue.
ParameterName = BinWord.
ParamterValue = BinExpression.
PredefinedMsgType = 0x01 /* accept-proposal */
| 0x02 /* agree */
| 0x03 /* cancel */
| 0x04 /* cfp */
| 0x05 /* confirm */
| 0x06 /* disconfirm */
| 0x07 /* failure */
| 0x08 /* inform */
| 0x09 /* inform-if */
| 0x0a /* inform-ref */
| 0x0b /* not-understood */
| 0x0c /* propagate */
| 0x0d /* propose */
| 0x0e /* proxy */
| 0x0f /* query-if */
| 0x10 /* query-ref */
| 0x11 /* refuse */
| 0x12 /* reject-proposal */
| 0x13 /* request */
| 0x14 /* request-when */
| 0x15 /* request-whenever */
| 0x16. /* subscribe */
PredefinedMsgParam = 0x02 AgentIdentifier /* sender */
| 0x03 RecipientExpr /* receiver */
| 0x04 MsgContent /* content */
| 0x05 ReplyWithParam /* reply-with */
| 0x06 ReplyByParam /* reply-by */
| 0x07 InReplyToParam /* in-reply-to */
| 0x08 ReplyToParam /* reply-to */
| 0x09 Language /* language */
| 0x0a Encoding /* encoding */
| 0x0b Ontology /* ontology */
| 0x0c Protocol /* protocol */
| 0x0d ConversationID. /* conversation-id */
AgentIdentifier = 0x02 AgentName
[Addresses]
[Resolvers]
(UserDefinedParameter)*
EndOfCollection.
AgentName = BinWord.
Addresses = 0x02 UrlCollection.
Resolvers = 0x03 AgentIdentifierCollection.
UserDefinedParameter = 0x04 BinWord BinExpression.
UrlCollection = (Url)* EndofCollection.
Url = BinWord.
AgentIdentifierCollection
= (AgentIdentifier)* EndOfCollection.
RecipientExpr = AgentIdentifierCollection.
MsgContent = BinString.
ReplyWithParam = BinExpression.
ReplyByParam = BinDateTimeToken.
InReplyToParam = BinExpression.
ReplyToParam = RecipientExpr.
Language = BinExpression.
Encoding = BinExpression.
Ontology = BinExpression.
Protocol = BinWord.
ConversationID = BinExpression.
BinWord = 0x10 Word 0x00
| 0x11 Index.
BinNumber = 0x12 Digits /* Decimal number */
| 0x13 Digits. /* Hexadecimal number */
Digits = CodedNumber+.
BinString = 0x14 String 0x00 /* New string literal */
| 0x15 Index /* String literal from code table */
| 0x16 Len8 ByteSeq /* New ByteLengthEncoded string */
| 0x17 Len16 ByteSeq /* New ByteLengthEncoded string */
| 0x18 Index /* ByteLengthEncoded from code table */
| 0x19 Len32 ByteSeq. /* New ByteLengthEncoded string */
BinDateTimeToken = 0x20 BinDate /* Absolute time */
| 0x21 BinDate /* Relative time (+) */
| 0x22 BinDate /* Relative time (-) */
| 0x24 BinDate TypeDesignator /* Absolute time */
| 0x25 BinDate TypeDesignator /* Relative time (+) */
| 0x26 BinDate TypeDesignator. /* Relative time (-) */
BinDate = Year Month Day Hour Minute Second Millisecond.
/* See comment 8 below */
BinExpression = BinExpr
| 0xFF BinString. /* See comment 9 below */
BinExpr = BinWord
| BinString
| BinNumber
| ExprStart BinExpr* ExprEnd.
ExprStart =i 0x60 /* Level down (i.e. ‘(’ –character) */
| 0x70 Word 0x00 /* Level down, new word follows */
| 0x71 Index /* Level down, word code follows */
| 0x72 Digits /* Level down, number follows */
| 0x73 Digits /* Level down, hex number follows */
| 0x74 String 0x00 /* Level down, new string follows */
| 0x75 Index /* Level down, string code follows */
| 0x76 Len8 String /* Level down, new byte string (1 byte) */
| 0x77 Len16 String /* Level down, new byte string (2 byte) */
| 0x78 Len32 String /* Level down, new byte string (4 byte) */
| 0x79 Index. /* Level down, byte string code follows */
ExprEnd = 0x40 /* Level up (i.e. ‘)’ –character) */
| 0x50 Word 0x00 /* Level up, new word follows */
| 0x51 Index /* Level up, word code follows */
| 0x52 Digits /* Level up, number follows */
| 0x53 Digits /* Level up, hexadecimal number follows */
| 0x54 String 0x00 /* Level up, new string follows */
| 0x55 Index /* Level up, string code follows */
| 0x56 Len8 String /* Level up, new byte string (1 byte) */
| 0x57 Len16 String /* Level up, new byte string (2 byte) */
| 0x58 Len32 String /* Level up, new byte string (4 byte) */
| 0x59 Index. /* Level up, byte string code follows */
ByteSeq = Byte*.
Index = Byte
| Short. /* See comment 6 below */
Len8 = Byte. /* See comment 7 below */
Len16 = Short. /* See comment 7 below */
Len32 = Long. /* See comment 7 below */
Year = Byte Byte.
Month = Byte.
Day = Byte.
Hour = Byte.
Minute = Byte.
Second = Byte.
Millisecond = Byte Byte.
Word = /* as in [FIPA00070] */
String = /* as in [FIPA00070] */
CodedNumber = /* See comment 5 below */
TypeDesignator = /* as in [FIPA00070] */
The transport syntax can be used with or without dynamic code table. Using dynamic code tables is an optional feature, which gives more compact output but might not be appropriate if communicating peers does not have sufficient memory (for example, in case of low-end PDAs or smart phones).
To use dynamic code tables the encoder inserts new entries (for example, Word, String, etc.) into a code table while constructing bit-efficient representation for ACL message. The code table is initially empty and whenever a new entry is added to the code table, the smallest available code number is allocated to it. There is no need to transfer these index codes explicitly over the communication channel. Once the code table becomes full and a new code needs to be added, the sender first removes size>>3[2] entries from the code table using a Least Recently Used (LRU) algorithm and then adds a new entry to code table. For example, should the code table size be 512 entries, 64 entries are removed. Correspondingly the decoder removes entries from the code table when it receives a new entry from the encoder.
The size of the code table, if used, is between 256 (28) and 65536 (216) entries. The output of this code table is always one or two bytes (one byte only when the code table size is 28). Using two-byte output code wastes some bits, but allows for much faster parsing of messages. The code table is unidirectional, that is, if sender A adds something to the code table when sending a message to B, then B cannot use this code table entry when sending a message back to A.
Both peers must agree the code table size before its usage; this process is not part of this specification. Furthermore, having more compact output, one code table should be applied to more than one message; the method of mapping messages to appropriate code table is not part of this specification.
1. The first byte defines the message identifier. The identifier byte can be used to separate bit-efficient ACL messages from (for example) string-based messages and separate different coding schemes. The value 0xFA defines a bit-efficient coding scheme without dynamic code tables and the value 0xFB defines a bit-efficient coding scheme with dynamic code tables. The message identifier 0xFC is used when dynamic code tables are being used, but the sender does not want to update code tables (even if message contains strings that should be added to code table).
4. All message parameters defined in this specification have a predefined code. If a message contains a user defined message parameter, an extension mechanism is used (byte 0x00) and new entry is added to code table (if code table is used).
If the ASCII presentation of a number contains odd number characters, the last four bits of the coded number are set to zero (the Padding token), otherwise an additional 0x00 byte is added to end of coded number. If the number to be coded is integer, decimal number, or octal number, the identifier byte 0x12 is used. For hexadecimal numbers, the identifier byte 0x13 is used. Hexadecimal numbers are converted to integers before coding (the coding scheme does not allow characters from a through f to appear in number form).
Numbers are never added to a dynamic code table.
|
Token |
Code |
|
Token |
Code |
|
Padding |
0000 |
|
7 |
1000 |
|
0 |
0001 |
8 |
1001 |
|
|
1 |
0010 |
9 |
1010 |
|
|
2 |
0011 |
+ |
1100 |
|
|
3 |
0100 |
E |
1101 |
|
|
4 |
0101 |
- |
1110 |
|
|
5 |
0110 |
. |
1111 |
|
|
6 |
0111 |
|
|
Table 1: Binary Representation of Number Tokens
7. Byte is a one-byte code word, Short is a short integer (two bytes, network byte order) and Long is a long integer (four bytes, network byte order).
9. None of the actual content of the message (the information contained in the content parameter of the ACL message) is coded nor are any of its components are added to a code table.
[FIPA00023] FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/
[FIPA00067] FIPA Agent Message Transport Service Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00067/
[FIPA00070] FIPA ACL Message
Representation in String Specification. Foundation
for Intelligent Physical Agents, 2000.
http://www.fipa.org/specs/fipa00070/
[FIPA00075] FIPA Agent Message
Transport Protocol for IIOP Specification. Foundation
for Intelligent Physical Agents, 2000.
http://www.fipa.org/specs/fipa00075/
Page 2, line 56: Removed sentence on compatibility issue with FIPA00075
Page 4, line 158: MsgContent value changed from BinExpression to BinString
Page 4, line 193: Added signs to BinDateTimeToken