See also: IRC log
<scribe> scribe: Valentina
resolution: minutes approved
pratul: minutes not ready for Nov 12
pratul: comments based on Valentina investigation is to remove this section
... do we have agreement ?
Resolution: will be marked as editorial, take out this section from the spec
5. Review and attempt to reach consensus on the following bugs using Sandy's inter-document reference proposal
http://lists.w3.org/Archives/Public/public-sml/2007Nov/att-0204/sml-if-idr-V1.html
pratul: before we go forward, are there any comments with Sandy's proposal ?
... no comments, so assume there are no issues with the proposal
pratul first bug on the list covered by the proposal is 4777
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4777
Kumar: makes sense based on the proposal
pratul: other comments for this bug ?
Resolution: mark this bug editorial and fix as per Sandy's proposal
next bug covered by Sandy's proposal is 5120
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5120
pratul: seems to be similar with 4777
Kumar: this is more about specific text in the spec, the other was about the principle
Resolution: mark this editorial, fix per Sandy's proposal
next bug covered by Sandy's proposal is 5171
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5171
<MSM> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5181
Resolution: close 5171 as a dup 5181
next bug covered by Sandy's proposal is 5201
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5201
Kumar: based on Sandy's proposal, I agree how this is addressed
Resolution: mark this editorial, fix as per Sandy's proposal
Kumar: will follow up with Valentina on this
... proposes looking into 4746
Kumar: reviews the proposal presented in defect, under comment #3
<scribe> chair: Pratul
MSM: The group defining the signature does not expect the document to be invariant with respect to canonicalization
John: Paraphrasing MSM... many discussions were had on this when digital signatures were defined. They netted out to a recognition that in order to verify a signature, the recipient would canonicalize an internal copy of the document, remove the sender's signature, sign it, and see if its newly generated signature matched the asserted signature. Since the recipient always goes through canonicalization itself, there is no need to actually transfer the document in canonicalized form. Doing so really doesn't save the recipient any work.
Pratul: proposes to remove this text
Resolution: mark this editorial, remove this text from the spec
Kumar: proposes to discuss 4992
Kumar: Sandy's proposal makes sense to him, as commented in defect, under comment #9
... Sandy's proposal is under comment #5
... there are three classes to consider when looking at object identity
Pratul: so the proposal is to define the objects as identical if they are identified by the same URI
Kumar: if the URI is not identical , it is implementation dependent if they are treated as equal or not
Resolution: mark as editorial, fix as per comment #5
Pratul: please take a look at the needsReview bugs
Kumar: bug 5272
Kumar: agree that we should clarify that only one document can be created under a data element
Pratul: propose to mark editorial
Resolution: mark editorial, a data element can have at most one document
Kumar: proposes to mark bug 4776 after LC
Pratul: this was discussed in the f2f
... there is divergence in opinion on how this bug should be fixed; probably saying nothing about it should work better
... which is mark the bug as won't fix
Resolution: mark 4776 as won't fix