Re:... replacement for 14.4 and C6.2 (interchange encodings)
Michel, Dmitry
On 2014 Jun 25, at 02:31, Dmitry Nadezhin wrote:
> Michel,
>
> I guess that you are discussing now the "Proposed replacement for 14.4 and C6.2 (interchange encodings)"
> with some group members...
> Particularly, I'm curious about your decision about the following topics.
>
> 1) Where will be a place to define mapping to octets ?
> A) It is level 5.
> Level 3 is a pair or tripple of Level 2 floating-point datum and an abstract decoration;
> Level 4 is a bit string;
> Level 5 is a sequence of octets.
> B) It is level 4.
> Level 3 is a pair or tripple of Level 2 floating-point datum and an abstract decoration;
> Level 4 is a sequence of octets.
I don't know enough to have a strong opinion, but I tend towards (A), if A.4 means the conceptual bit string we had before which is independent of machine architecture.
> 2) What is a name for a sequence of octets ?
> Level 3 is called representation;
> Level A.4 is called encoding;
> Whare is the name of A.5 or B.4 ?
> I think that "mapping" is too general word.
Is "octet-encoding" OK?
> 3) Is A.5/B.4 required, recommended or annex ?
Good question. I would say required. Why spend all this time stressing out at the last minute, if the result of our effort is something implementers can ignore?
> 4) Is signature an ascii string or an octet sequence or a structure of C language ?
It needs to be language-independent. IMO, it should be convenient for humans to read. That indicates ASCII string.
> 5) Do we try to define representation, encoding and mapping for compressed intervals ?
Try to make the design consistent with the future possibility of a signature for encodings of compressed intervals, but they are optional. Put ZERO (or epsilon) effort into this. We haven't time.
John Pryce