Subject: RE: [rohc] SigComp user guide - a few comments

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 14 Jul 2005 10:20:47 +0100

Hi All,

I haven't had any feedback on this email and the deadline for the draft is getting close.  I'll assume from the silence that the minor changes below are ok.  However, I do need some feedback on the shared compression issue as it's more than a minor change.

There are options:

1) 	leave it as it is 
2) 	change section 5.5 as suggested below to refer to 5.2 and 5.4 and update 5.4 accordingly.
3) 	remove the section altogether

I really don't like 1) because I think the bytecode is overcomplicated and am not sure that it works.  My vote is for 2) but 3)'s ok too.

Best regards,

Abbie

> -----Original Message-----
> From: Surtees, Abigail 
> Sent: Thursday, June 30, 2005 3:04 PM
> To: [email-masked]
> Subject: [rohc] SigComp user guide - a few comments
> 
> 
> Hi All,
> 
> I've read through the user guide prior to updating it and 
> have a few comments.  There are two other issues 
> (clarification of '!' and moving EPIC) for which I'll propose 
> some text separately.
> 
> Section 5.5 Shared compression.
> 
> Has anyone run the bytecode presented in this section?  We 
> haven't and the way it is currently written seems to 
> overcomplicate the issue.  If no-one has verified that this 
> bytecode works, then my suggestion is the following:
> 
> In section '5.4 Announcing additional resources' augment the 
> description to include advertising state ids
> In section 5.5 simply say that shared state has to be 
> advertised as in section 5.4 and can be accessed in the same 
> way as a piece of dictionary state see section 5.2.
> 
> What do you think?
> 
> Minor comments:
> 
> Page 4, end of section 2:
> 
> I suggest the addition of the following text:
> 
> "The algorithms, techniques and assembly code presented in 
> this document are examples and can be modified, extended as 
> the implementer sees fit."
> 
> Page 6, comments to BNF for operand:
> 
> "  ; Operands can be left black if they can
>                               ; be automatically inferred by the
>                               ; compiler, e.g. a literal (#) operand
>                               ; that specifies the total number of
>                               ; operands for the instruction.
>                               ; When "$" is prepended to an operand,
>                               ; the corresponding integer is an
>                               ; address rather than the actual operand
>                               ; value. This symbol is mandatory for
>                               ; reference operands ($), optional for
>                               ; multitypes (%) and addresses (@), and
>                               ; disallowed for literals (#)."
> 
> I suggest removal of the bracketed symbols (#), ($), (%), and 
> (@) because they are not part of the BNF and not referred to 
> anywhere else in the document.  I found their inclusion 
> confusing because it led me to try to fit them into the BNF.
> 
> Please let me know what you think so that we can get the 
> document updated.
> 
> Best regards,
> 
> Abbie
> 
> Abbie Surtees
> Senior Engineer
> Roke Manor Research Ltd
> Old Salisbury Lane
> Romsey, SO51 0ZN
> Tel:   +44 (0) 1794 833131
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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