RE: [office] Two JIRA Issues for discussion

[Hanssens Bart <Bart.Hanssens@fedict.be>]

Rob,

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 documents,
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 think
> so.  Remember, as currently writtem  a conforming consumer is not required
> 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 support.


> B) Do we want to require that consumers tolerate, i.e., degrade gracefully
> in the presence of XAdES extensions if they don't understand them?  I
> think that is reasonable and covered by "need not interpret the semantics
> of all elements, attributes and attribute values".

Degrading shouldn't be a problem, just ignore ds:Object and its children.


> C) Do we want to ensure that XAdES are allowed in conforming packages?  or
> only in extended packages?  I think the "extended" conformance class was
> meant for document types that went beyond the defines MIME content types
> for spreadsheets, text, presentations, etc.  There was the intent that the
> 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 they
> do not understand?  I assume it is better to ignore them than to give an
> 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 also for other
ODF features, but that's another story)



Best regards

Bart