Hi Carsten: Since we seem to agree that what we need to define is the interface to the context as opposed to the context content or management, let me propose this change:
2.1.2. Context Identifier Extension This specification expects that an abstract set of states called contexts is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables to transport an opaque index that is used to lookup the abstract context database. The index in encoded with 4 bits enabling to address up to 16 contexts. This specification requires that services associated to the abstract context database implement an interface to the 6LoWPAN compressor to help compress and uncompress an address based on the parameters passed by the compressor and the information in the abstract context database. The interface MUST provide the methods to lookup a context ID from a prefix and a prefix length for encoding, and reversely lookup a prefix and a prefix length from a context ID for decoding. How the contexts are shared and maintained is out of scope. The actual context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The interface might be extended to allow for further stateful compression, for instance for SAC = 11, additional context information might be used to store the full IPv6 address using the Link layer Address as an additional index. What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[EMAIL PROTECTED] >Sent: mercredi 26 novembre 2008 10:37 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] context information > >>> Second, "What the context information is is out of scope" will only >>> work insofar as HC is not concerned. >>> HC needs 16 byte strings, indexed by a number from 0 to 15. This >>> clearly defines "What the context information is" to a certain >>> extent. >> >> I disagree that the specification can only extract 16 values. The >> specification can only pass 16 context IDs but the parameters in >> interface do not have to be limited to the context ID. >> We have short addresses, long addresses, network interface ID, etc... > >OK, let's try to put this slightly more precisely: > >My view: > >The context provides a function > > f(CID: 0..15) -> byte-string(0..16) > >Your view: > >The context provides a function > > f(CID: 0..15, unspecified stuff) -> byte-string(0..16) > >While this sure can be made to work, my "interoperability nightmare" >bell just went on. > >But in any case, there *is* a defined interface, except that your >version has this additional set of unspecified parameters. >Can you explain what you would use it for? >How do you make sure "unspecified stuff" is the same at compressor and >decompressor? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
