[rohc] SigComp issues - LEJO

["Lars-Erik Jonsson (EPL)" <[e-mail]>]

I've separated my comments on SigComp in two mails, and these are the more 
technical issues, although some of them might be close to editorial.

Rgds,
/L-E



lejo-1) In section 3.1 (page 9), it is written that SigComp usage is indicated
        by using different port numbers. Did we not agree that this is one
        option, but not necessary the way it is done. SigComp messages are now
        self-identifiable.

lejo-2) Use of static dictionaries, how is that envisioned? First of all, I
        assume it should be mentioned and explained, e.g. when per-message
        compression is defined. Further, 6.3.3 may be interpreted as if static
        dictionary usage is about announcing certain pre-defined states. Is
        that a good approach? Should one not define a static dictionary for
        each SigComp application, e.g. SIP, that must be used as a minimum? 

lejo-3) We must standardize how SigComp is used for e.g. SIP (at least). This
        includes default values for all application parameters, the mechanism
        used to separate SigComp/SIP from normal SIP messages, and maybe a
        mandatory static dictionary.

lejo-4) In terminology and section 6.1, second paragraph, dynamic compression
        is mentioned as an important mechanism for improved compression 
        efficiency, but not at all explained how to implement. We all know
        why, but for a reader this is strange. Should we clearly refer to
        the document that explains how to implement this and other useful
        enhancements?

lejo-5) In section 3.2, "Initial State": What does the last sentence mean?
        "Each item of initial state can be made mandatory for every instance
        of the application, or it can be optional." First, "each" indicates
        a limited set, should it be "any"? Further, "can be made mandatory",
        by who? In which context, for e.g. all SigComp SIP usage, or? 

lejo-6) State deletion, discussed in 6.1 and 6.2. First, I get a feeling that
        something is missing after the first (continued) sentence on page 17.
        An obvious question from a reader is "how can the state handler
        determine that?", which is not answered. Further, when section 6.2
        describes how to save and delete state, this becomes confusing. 
        * Why should a decompressor save state? Answer: Dynamic compression.
        * Is it possible for a compressor to know what has been saved by
          the decompressor? Answer: Yes, if acks are used.
        * Can a decompressor decide what to delete if states has been 
          acknowledged for use by the compressor? Answer: No, then the
          decompressor must know that the state will not be used again by
          the compressor.

lejo-7) In section 5.1, some things are confusing.
        * 2) is not sufficient for dynamic compression usage, since the
          compressor do not know what a decompressor saves. Not everything
          is saved, right?
        * 3) talks about pre-defined, who defines that? Further, available
          pre-defined state must then also be announced by the decompressor.
          These pre-defined states require a state-identifier space to be
          defined for registration of state-identifiers.

lejo-8) In section 6.1, third paragraph, the application->state handler
        interface is explained, but unclear. If an application does not
        validate a state, nothing is provided. Should it not be clearer
        if the handler (for each state) is provided with the following
        from the application: [Identity, State-ID], where Identity
        may have an error value indicating an invalid (and useless) State.

lejo-9) The IANA section must be clearer, if we want a SigComp pre-defined
        state-identifier space to be set up for reservation of values to
        use in state-announcements. 

lejo-10) Extended operations: To support e.g. explicit acks is an 
         implementation issue. However, as SigComp is now defined, this
         is about having it implemented at both "sides" to get the
         functionality. What I mean is that to use dynamic compression
         between compressor1 and decompressor2, compressor2 must provide
         acks for decompressor2 states. Is this a nice solution? Would it
         not be possible to define SigComp so that compressor1 could
         implement this by using the right UDVM instructions to force
         "state acks" for saved state from decompressor2? As it is now, both
         sides must explicitly implement this to get any benefits, and that 
         is not a nice way of having an implementation option.

lejo-11) If we define an IANA number space according to lejo-9 above,
         should we define identifiers for the "extended operations"
         mechanisms, to be able to announce support of those?

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc