XML Signature WG
XML Signature WGNot sure what is meant. When URI=#X, what is the namespace context that is also be transferred? One application may do something, another may do something else.
Extraction needs to dump all the namespaces of the original document into the transformed one.
Boyer: are we in control of how the fragment is resolved? Reagle: The MIMEType defines what it means, but we can define what the meaning means for our application.
LaMachia: concerned about efficiency, how many times will I have to do c14n?
Eastlake: you don't have to do all of it, you could just proprogate the namespaces in the resulting octects/xml.
Boyer: Transforms that can take an octect stream as input, and those that take an nodeset.
LaMachia: two types of transforms: (1) c14n for nodeset to octects (2) parser for octects to nodeset.
Reagle: they are different, in that in the xml transform, you might have your original xml parsing context.
Boyer: can't run the enveloped transform as the fourth.
Reagle: so this is what we are looking at, for each of the URI and/or transform you sign:
Merlin: what about going back to the clean-URI and not permitting #xpointer in the URI?
Boyer: we already considered that ... but we didn't have our processing model as clean, so it is an option.
Reagle: However, this would probably counter are changes that addressed Dan and Martin's comments and isn't necessary. Introducing the fact that there might be two types of transforms doesn't necessitate moving to clean-URIs, but it re-opens the possibility.
Eastlake: if we know its XML because of a null URL with a fragment "#bar" that implies one transform which is canonicalization.
LaMachia: Don, you are saying, "if a barename XPointer is present ("#bar") and there are no other transforms, then there is an implicit c14n transform"?
[some disgreement]
Eastlake: I'm saying, if we require explicit c14n, why not a parse transform then?
Reagle: ok, whether we return to barenames, or whether there's implicit-explicit parse/serialize transforms is orthogonal to the idea that there are two types. Action Boyer: Let's let John write up a proposal, then discuss these issues further then.
Why not remove encoding and just stick transforms in there? Action Eatlake: propose this to the list.
if we can include the idea of xml processing, this may be solved. postponed.