This concept was introduced to FBP by Eric Lawton of IBM, who described an IIP as a chunk of data, defined in the network definition, which turns into an InformationPacket (IP) when the component it is attached to does a receive. This removes the distinction, required by most languages, between parameters and input data. This means that, in FBP, an IIP or a data stream can be attached to a port, without the component needing to know which is which. Typically such ports are used for parametrization, although the IIP does not have to be a parameter - it could just be a piece of constant data being used as a report title, for instance.
Under FBP scheduling rules, a component will be reinvoked as long as one connection input port is not drained, so a "parameter" connection port will have to be drained to avoid having the component be continuously reactivated. The component must close this kind of port to make sure that if an upstream component sends additional IPs, a FlowError.Complain will be generated. A check will be added to the scheduler to make sure that an IIP port has been closed before deactivation.
In the current JavaFBP implementation, a copy of an IIP is presented to a component on every activation: Eric and other people feel that this copying process is counter-intuitive, and that the IIP should only be presented once, making it the component's responsibility to save it, or its contents, somewhere where it can be accessed over more than one activation, e.g. in an instance variable. Any additional receives of the IIP should return null.