OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] Two JIRA Issues for discussion

I can take a shot at revising the language. I should be able to get to it in the next week or two.

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
Sent: Sunday, March 07, 2010 5:39 PM
To: Hanssens Bart
Cc: Bob Jolliffe; office@lists.oasis-open.org
Subject: RE: [office] Two JIRA Issues for discussion

OK.  If anyone wants a change to the current text, please enter a JIRA issue with the specifics.  We can track the details better that way.



Hanssens Bart <Bart.Hanssens@fedict.be> wrote on 03/05/2010 01:46:55 AM:
> my main point is that: currently XAdES support is a "may" in a "note".
> Now, I only know one ODF-office suite code base that actually
> implements XML-DSIG, but IIRC even this implementation uses its own
> ds:Object to indicate the signing time. So there already is a need for
> something more than just plain XML-DSIG...
> XML-DSIG is just fine for signing macro's etc, but when signing
> it's going to be hard _not_ to use XAdES if one is serious about it.
> > So I think this all boils down to this, I think:
> >
> > A) Do we want to mandate that consumers understand XAdES ?  I don't
> > so.  Remember, as currently writtem  a conforming consumer is not
> > to understand dsigs at all.
> I'd suggest a "should understand XAdES" if they understand XML-DSIG.
> Note that XAdES has various "forms" (or "levels"): ranging from a
> simple XAdES-BES to everything but the kitchen sink XAdES-A for
> archiving. I'll leave it up to the implementation to decide what level
> they'd like to
> > B) Do we want to require that consumers tolerate, i.e., degrade
> > in the presence of XAdES extensions if they don't understand them?
> > I think that is reasonable and covered by "need not interpret the
> > of all elements, attributes and attribute values".
> Degrading shouldn't be a problem, just ignore ds:Object and its
> > C) Do we want to ensure that XAdES are allowed in conforming packages?
> > only in extended packages?  I think the "extended" conformance class
> > meant for document types that went beyond the defines MIME content
> > for spreadsheets, text, presentations, etc.  There was the intent
> > that
> > core package conformance class would allow some extensions.
> IMHO, they should be allowed in conforming packages.
> > 2) Change PC1.1 to put some meat around how to degrade gracefully.
> > For example, what should a consumer do if they encounter extensions
> > that
> > do not understand?  I assume it is better to ignore them than to
> > give
> > error and halt.  We might want to echo the similar language we have
> > in Part 1 on foreign elements and attributes.
> Yes, we need that for foreign element, attributes (and actually
> alsofor
> ODF features, but that's another story)
> Best regards
> Bart

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]