[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OpenDocuemnt TC Coordination Call Minutes 2006-12-04
Roll Call Ma Yue, IBM Helen Yue, IBM Patric Durusau Florian Reueter, Novell Michael Brauer, Sun Microsystems Lars Oppermann, Sun Microsystems Eike Rathke, Sun Microsystems Oliver Wittmann, Sun Microsystems Bruce D'Arcus, OpenDocument Foundation Gary Edwards, OpenDocument Foundation Minutes from last coordination call The attending TC members unanimously accepted the minutes from the last coordination call. Action items none from loast coordination call Discussion ISO update 22300 is now in 60.60 and available in ISO store OpenDocuemnt 1.1 OASIS Michael: currently preparing docuemnt - we need certification that the document schema is valid - I sent a draft to the email list - please give feedback - any disagreements to the current suggestion? no objection RESOLUTION: include the following language into OASIS standard submission: "The contained schemas and have been extensively tested, and the specification document itself was validated against the contained schema. Sample instance fragments and expressions were reviewed." Michael: regarding submission timing I await another certification in the next days. I f I don't get that by Wednesday, I will send a preview request for standard ballot to Mary so she can review it while we wait for the additional certification OpenDocuemnt 1.2 proposals... Michael: we already discussed version attribute in the work call, and I send out an updated proposal, making version attribute mandatory, only allowing the value 1.2. - Older specification can either specify version="1.1" or "1.0" or omit the version attribute. Dave Pawson suggested an extension to the language which I found reasonable. - Any objection to using this with the proposed update from Dave? - no objection RESOLUTION: Only allow version="1.2" for ODF 1.2 documents, allow other values as hint from older applications. Language Tags Eike: issue is about current language tags only define language and country. RFC 3066 ISO 639 1,2 ISO 3166... We have languages that want to use our office suite that are not encopassed by these standards RFC allows for much more languages - We encountered an obstacle with having different script types in the same language. I propose to develop a language tag mechanism, that enables us to refer any language that RFC4646 might come up with. Lars. can we just use the string format described in the RFC? Eike: Michael proposed to keep country and language attributes, however, the problem with that proposal seems to be, that this binds us to all the country codes of currently specified, but not any upcoming languages that will be registered with IANA Michael: for backwards compatibility, we should keep the fo:country and fo:langugae attributes. Lars: can we than specify a these attributes to reflect the values of the respective fields from the RFC4646 string? Michael: would it be more appropriate to reference ISO or RFC Patrick: it would be better to follow ISO, we should look into why there is this divergence between RFC/IANA and ISO ... if we have an available ISO standard, do we want to cite a work that does not have the same status like an ISO standard [...] Patrick: we could refer to ISO 639 and give kind of an escape hatch to fall back to RFC language code in the specification language Michael: refer to specific ISO standard, later versions of our standard might than refer to later ISO version Hashed passwords Michael: I propose to at least add to the specification, that the hashes are created with SHA-1 This is only for #write protected' paragraphs Lars: this does not have a security impact, I suggest we just write that this is SHA-1 Patrick: SHA1 is deprecated and although it is not really a security feature, mandating an deprecated hash function might lead to uncomfortable discussions Michael: than I would propose to use the algorithm attribute from the xml sig specification Patrick: that would also work for me Michael: than I will create a proposal for that Michael: and I will do the same for encrypted document, which in fact is a security related feature... List Styles: Michael: my understanding is that florian and oliver are more or less in agreement from what've seen on the mailing list Florian: which conversation/discussions are you referring to Michael: There was a discussion on the list between you and DavidF and Oliver. Florian: DavidF didn't comment to that right? Michael: no, so it would be fair to explicitly ask David of his opinion on this... Florian: I must admit that I am still only beginning to understand some of the complexities involved with lists, so I wouldn't want to discuss the details now,.. Next Meeting: Work TC Call on Monday, November the 11th, at 7am PT (3pm GMT). -- Lars Oppermann <lars.oppermann@sun.com> Sun Microsystems Software Engineer Nagelsweg 55 Phone: +49 40 23646 959 20097 Hamburg, Germany Fax: +49 40 23646 550 http://www.sun.com/staroffice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]