Hi Carsten: The way I see it, the f(CID: 0..15, unspecified stuff) -> byte-string(0..16) must be specified somewhere and used homogeneously within an environment.
But HC does not have to imply what f is. There can be RFC f1, RFC f2 etc... and HC will work for them all. A given deployment will have to select which fx is used. 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
