- #Compressor 4.2.2 system requirements how to#
- #Compressor 4.2.2 system requirements full#
- #Compressor 4.2.2 system requirements software#
#Compressor 4.2.2 system requirements how to#
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisĭocument are to be interpreted as described in RFC-2119.Ī ROHC profile is a description of how to compress a certain The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Internet-Draft ROHC Formal Notation Requirements July 2003 2. IETF-56 was the place where a necessity for "Formal notation (ROHC-FN)", which served the role of template text for Sanįrancisco IETF-56 formal notation discussions. This work resulted in "Formal Notation for Robust Header Compression Official ROHC starting point for formal notation development. Uncompressed header structure definition isīased on ROHC WG discussions improved version of, the "ProtocolĮnabled BNF-Based Language (PEBBLE)" is published to be the Simultaneously, alternative "Generic Header Compression Notationįor ROHC" was proposed with its hierarchical header extension This way, particular field processing can be postponed Postponed field value is stored in a variable defined by LABEL The authors of EPIC introduced "A Formal Notation for HeaderĬompression" where explicit stack manipulations are avoided
Pushing its value to the "control stack". In a two stack model, particular field processing is postponed by Induced lot of discussion because of its stack oriented functionality. The profile refinement and specification clarity wereĪchieved by implementing changes in English text.Īlternative solution for profile specification was introduced inĮfficient Protocol Independent Compression (EPIC-Lite) on theīasis of Bachus-Naur form (BNF). Machine and profile are specified using "RFC box notation", actuallyĪ simple graphical representation with additional English explanation The ROHC working group effort to provide robust header compressionįramework resulted in several documents. Internet-Draft ROHC Formal Notation Requirements July 2003 1. Notation with random access fields and read on demand. Field postponement and separate specification. Field postponement and simultaneous specification. Notation with field processing postponement. Some freedom on input and one degree of freedom on output11Ĥ.2.2. One degree of freedom on input with advance read. One degree of freedom on input with read on demand. Profile specification degrees of freedom. To contribute to formal notation development effort.ġ. To encourage discussion regarding the formal notationĢ.
#Compressor 4.2.2 system requirements software#
Refinement to achieve maximal compression ratio possible, as wellĪs in the phase of software implementation to provide unambiguous The role of formal notation is to provide a simple method for ROHC It is builtĪround an extensible core framework that can be tailored toĬompress new protocol stacks by adding additional ROHC profiles. The RObust Header Compression (ROHC) scheme is designed toĬompress packet headers over error prone channels. This draft describes requirements expected to be achieved with Internet-Draft ROHC Formal Notation Requirements July 2003 This Internet-Draft will expire on August 28, 2003.Ĭopyright (C) The Internet Society (2003). The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at Material or to cite them other than as "work in progress." It is inappropriate to use Internet-Drafts as reference Internet-Drafts are draft documents valid for a maximum of six monthsĪnd may be updated, replaced, or obsoleted by other documents at any Other groups may also distribute working documents as Internet. Task Force (IETF), its areas, and its working groups. Internet-Drafts are working documents of the Internet Engineering
#Compressor 4.2.2 system requirements full#
This document is an Internet-Draft and is in full conformance with Draft-ozegovic-rohc-fn-requirements-00.txt
0 kommentar(er)
