Re: Query regarding Additional Mode transition logic for IR & IR-Dyn Packets (Interoperabilty)

Pradeep, Ghyslain, L-E,

Even though it is confusing with the references to packet types (IR &
IR-DYN), I believe the mode transfer logic/cancel still works in RFC.

All references are refer to the mode field or the "mode field" & "packet
type" tuple. The text is very clear that the mode field needed
acknowledge Mode Transitions/Cancel. There are no mode fields in the IR
and IR-DYN packets. Mode Transfer/Mode Cancel can only be done with
UOR2-Ext3.

Best Regards,

Carl Knutsson

Chaitanya Pradeep wrote:
> Dear RoHC ers,
>  
>      I am facing ambiguity regarding handling of Mode Cancellation for
> IR & IR-Dyn Packets in Profile -0x0004 (RFC 3843).
>      RFC 3843 says:       
>     
>         The Mode parameter for  the value mode = 0 (packet types UOR-2,
> IR and IR-DYN) is redefined 
>         to allow the compressor to decline a mode transition requested
> by the decompressor:
>  
>         Mode: Compression mode. 0 = (C)ancel Mode Transition  
>  
>      Upon receiving the Mode parameter set to '0', the decompressor MUST
> stay in its current mode of operation and
>        SHOULD refrain from sending  further mode transition requests for
> the declined mode for a certain amount of time.
> Q.1) How do we communicate mode parameter (i.e, '0' for Mode
> cancellation)  to Decompressor for IR & IR-Dyn Packets?
>  
>        RFC 3095/ 3843 has not defined any field indicating 'Mode' in IR
> /IR-Dyn Packet formats for Profile-0x0004.
>        But UOR-2 Packet can communicate mode value in the form of
> Extension-3.
>  
> Q.2) Is this interpretation correct?
>         
>       Can we define a field for mode parameter in Dynamic chain (in IR &
> IR-Dyn packets) and communicate the mode value
>       to De-compressor, by indicating it as '0' for handling of Mode
> Cancellation.
>  
>       Will the above implementation give any impact in Interoperabilty?
>  
>   Pls share your valuble thoughts regarding the same.
>  
> Thanks,
> Pradeep.
>