DR-16-0014 [review on the next call]

[caroline arms]

Folks,

I've been trying to get my head round this DR with some difficulty.
In the most recent message Murata-san is suggesting some changes, but
doesn't indicate whether he considers them to be a complete solution.

SUGGESTION 1
=============
On the first suggestion, I am not certain that the 4 vs 8 "digit"
issue needs addressing in exactly this way.

The confusion here is that each Hex "digit" is two characters long as
encoded in the val attribute.    A link to 17.18.50 ST_LongHexNumber
(Eight Digit Hexadecimal Value) might be useful.  There the phrase
"four octet (eight digit) hexadecimal number" is used, which might be
clearer.

Note that the val attribute table entry attempts to explain this in
>>>
Specifies a number value specified as a four digit hexadecimal
number), whose contents of this decimal number are interpreted based
on the context of the parent XML element.

[Example: Consider the following value for an attribute of simple type
ST_LongHexNumber: 00BE2C6C.
This value is permitted, as it contains four hexadecimal digits, each
an encoding of an octet of the actual decimal number value. It can
therefore be interpreted as desired in
the context of the parent XML element, end example]
>>>

I believe we need a change to the normative sentence here, whose
meaning seems unclear and has a spurious ) character.  Same change
(whatever we decide on) will be needed in 17.15.1.71.


SUGGESTION 2
=============
The 2nd suggestion seems problematic without a requirement for
uniqueness within the file, implicit in the clause Murata-san proposes
to drop.  I don't have a problem with dropping the "larger'
requirement.

SUGGESTION 3
=============
The third suggestion, although possibly clearer, could also possibly
be improved.
Rather than

"However, if two documents specify rsidRoot (§17.15.1.71) differently,
an identical rsid value between the two documents does not indicate
the same editing session."
I would say:

"However, if two documents have different values for rsidRoot
(§17.15.1.71),  an identical rsid value between the two documents does
not indicate the same editing session."

MORE THOUGHTS ON THE DR
==========================
I see the following in a response "from the experts"

"For the green stuff, I do not think we should make a code change in
Word. So, if that’s the correction the finder wants, the answer is
(politely) no. I don’t know what description of RSID generation
contains errors – we document here and here that the RSIDs are
random."

I see nothing in green and therefore don't know what change is being
declined, but it may be related to my musings below:

I was struck by one issue that I don't see as adequately addressed in
terms of explanation -- although it may not require changes

The 10/26 message in the DR from submitter Courtenay Inchbald says:

"Word does not follow the rule in the rsid definition, repeated in the
note at the end of the definition, that RSIDs are generated from the
date. It would be helpful to me to add this exception to MS-OE376. "

The 11/16 response from Aarti says:
"The other issue mentioned is already done- we already document that
we don’t follow the rules of rsid generation in MS-OI29500, and in
section 2.1.424 in MS-OE376. "  Those are the links at "here and here"
above.

However, what is said in those two locations says nothing about
whether RSIDs are generated from the date (or in fact time which is
what the standard says).  The wording is "Word generates a random
number for every rsid that is not necessarily larger than all earlier
ones in the same file."

17.15.1.70 rsid

says normatively, "Revision save IDs should be randomly generated
based on the current time (to minimize the chance that two disparate
editing sessions starting with the same immediate predecessor are
assigned the same revision save ID)"

and informatively in a note, "Although in practice it is possible for
two independent sessions to result in the same value, this outcome is
extremely rare as the values are based on the current time."

Question from me:  Is Courtenay correct in saying that RSIDs are not
based on the date/time?  If so she has a point.  But she may be
assuming that is not the case because she observes that RSIDs are not
larger than previously generated ones.  It is certainly possible to
use a randomization mechanism that includes incorporating a date/time
stamp in order to minimize the chance of generating the same one but
that doesn't enforce any ordering.  Can I assume that is what Word
does?  If so, we probably don't HAVE TO make any changes.

However, we could possibly change the second bullet in 17.15.1.70 to
something like:
"Revision save IDs should be randomly generated in a way that
minimizes the chance that two disparate editing sessions starting with
the same immediate predecessor document are assigned the same revision
save ID (perhaps by using the current time)."
and perhaps also make a small modification to the note that Murata-san
has already suggested a change to.


My apologies for all the words here.  I needed them for my own clarification.

    Caroline

On Thu, Dec 8, 2016 at 5:54 AM, MURATA Makoto <eb2m-mrt at asahi-net.or.jp> wrote:
> Folks,
>
> I would like to propose three changes.
>
> 1) In §17.15.1.70 and §17.15.1.71, replace "four-digit" by "eight-digit".
>
> Rationale: An obvious mistake.
>
> 2)  Section 17.15.1.70, rsid (Single Session Revision Save ID)
>
> In the first bullet, remove "that is larger than all earlier ones in
> the same file".
>
> Rationale: MS Office does not enforce this requirement, and thus
> existing OOXML documents are unlikely to satisfy it.
>
> MS-OI29500:
>
> 2.1.414 Part 1 Section 17.15.1.70, rsid (Single Session Revision Save ID)
>
> a. The standard states that the rsid should be randomly chosen and
> that every editing session shall be assigned an rsid that is larger
> than all earlier ones in the same file. If both are observed, the
> application would quickly run out of allowable rsid's.
>
> Word generates a random number for every rsid that is not necessarily
> larger than all earlier ones in the same file.
>
> 3) Replace
>
> "However, the meaning of two revision save IDs is not defined for
> documents with a different rsidRoot. Applications can use this
> information as desired."
>
> in 17.15.1.70
>
> by
>
> "However, if two documents specify rsidRoot (§17.15.1.71) differently,
> an identical rsid value between the two documents does not indicate
> the same editing session."
>
> Rationale: Clearer.
>
> Regards,
> Makoto
>
> 2016-12-07 7:21 GMT+09:00 Rex Jaeschke <rex at rexjaeschke.com>:
>>
>>
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto