SML call 11/19

19 Nov 2007

See also: IRC log


Kirk, Valentina, Jordan, Kirk, MSM, johnarwe, Marv, pratul, Kumar
Sandy, Ginny, Jim


<scribe> scribe: Valentina

meeting minutes for 11/15


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

item 5 in the agenda

5. Review and attempt to reach consensus on the following bugs using Sandy's inter-document reference proposal


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


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


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


<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


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

Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/02/23 21:38:13 $