ietf
[Top] [All Lists]

Re: Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05

2009-08-16 12:44:46
>> If so, can it generate illegal sieve scripts
>> from the XML? How can it avoid doing so if it doesn't have a semantic
>> knowledge of sieve?
>
> Nowhere does this document say or even imply that no semantic
> knowledge of
> Sieve is required to construct a Sieve from scratch using the XML
> representation. Such a claim would be absurd in any case - it is
> axiomatic that
> in order to construct a program you have to know what the elements
> in the
> language do!
>
> What the document does say (section 4.1, fourth paragraph) is that
> XML can be
> used to avoid the need for a client to understand sieve *grammar* or
> to have a
> full understanding of Sieve semantics. Syntax understanding is made
> unnecesary
> by substituting XML syntax, of course. As for semantics, a processor
> can be
> written (and many have been) that only look at the metadata elements
> (displayblock and so on) and treat all the Sieve stuff under those
> elements as
> a black box.

I inferred from that very paragraph imply that the "editor" was not
necessarily expected to understand sieve semantics.

Then I'm afraid you didn't read it very carefully. What is says is clients
don't necesarily need _complete_ knowledge. Again, it is axiomatic that *some*
knowledge of Sieve semantics is going to be necessary. But lots of editors
operate on the basis of templates containing sequences of Sieve commands. They
only have enough knowledge to stitch the templates together, and such
manipulations may be simpliified through the use of the XML format.

If that is not the intent,

It most certainly is the intent.

it would be helpful to have a sentence or two somewhere (maybe
in the intro) to explicitly say so. My confusion might be around the
meaning of the term "client" in this context.

No, I think your confusion is that you read a lot more into the text than it
actually says. There's a pretty big difference between "no semantic
understanding whatsoever" and "an incomplete semantic understanding'.

Is the expectation that
an "editor" must be semantically aware of sieve, but a processor does
not (beyond the list of "controls")?

The expectation is that the amount of semantic understanding an editor is going
to need will very much depend on the range of operations the editor is able to
perform. Simple template-based systems will only manipulate labelled blocks of
Sieve code without any understanding of what that code does. A more
sophisticated editor might need to have a detailed knowledge of how blocks in
Sieve work, or how to build conditional expressions, or even the details
sematics of various tests and actions.

...

Instead of round trip "conversion", I should have said round-trip
"editing". My concern is, if I create a script using Editor A, then
later edit it with Editor B, any metadata created by Editor A is
likely to be lost.

And that's a valid concern to have. Again, there are going to be cases where
one editor has no choice but to strip the information added by another. This is
simply how things are; there's nothing this or any other representation scheme
can do to eliminatte this possibility.

Is that the intent?

It's not a matter of intent. It is simply an unavoidable reality.

If so, it's probably worth
mentioning that an editor needs to be able to deal rationally with the
loss of its own metadata.

First, while it is certainly desireable for all editors to have this
characteristic, there are going to be cases where it cannot possibly
work this way. So this can't be a requirement.

Second, even if it were appropriate to make this a requirement, this document
isn't the place for it. All this document does is describe an XML
representation for Sieve. All of the requirements it imposes are directed at
the representation and the process of converting to or from that
representation.

But since there is no requirement that a Sieve editor use this XML
representation at all - and in practice most extant Sieve editors operate
directly on the native Sieve format - imposing requirements on editors here
makes little if any sense.

(I can think of reasonable use cases that would involve this--perhaps
I create the script with an editor on my laptop, but later need to
modify it using an editor on a smart phone...).

Again, there is absolutely no doubt that being able to use multiple editors on
the same sieve and have them all work happily together is desireable.
At a minimum I think it would be helpful to clarify that the
"inconvenience" is around preserving metadata that the editor does not
understand--i.e. metadata from a different metadata implementation.

I think this is already pretty clear.

>> Why not MUST? Wouldn't violation of this requirement introduce
>> interoperability problems between different implementations?
>
> It's a SHOULD because the WG believed that there may be some
> exception cases
> where an alternate format makes more sense.

Can you offer (in the text) some examples of those exceptional cases,
and the consequences thereof?

I see no need to.

My concern is that it seems like violating the should would pretty
much break interoperability between processors, wouldn't it?

Sure, which is why it's a SHOULD, not a MAY. Again, this is the compliance
level the WG decided was appropriate. Even if I agreed with you, this is not a
simple editorial nit that I can change on my own.

Or at
least cause encoded metadata to get lost if you convert from XML to
sieve using one processor, and back to xml with another?

That's the obvious case where such a loss would occur.

>
>> -- Security Considerations, last paragraph:
>
>> You mention that potentially executable content can be introduced via
>> other namespaces, and that "appropriate security precautions" should
>> be taken. I think this needs more discussion, as I am not sure an
>> implementor will understand what the authors considered appropriate.
>
> The point of Sieve namespaces is to allow multiple XML vocabularies
> to be used
> in a single document. This is a completely open ended mechanism and
> it is not
> our intent to label any particular use as inappropriate. As such,
> unless you
> have some specific text in mind, I for one fail to see what could be
> added here
> that would be useful.

Maybe an examples of the sorts of bad behavior that could be enabled
by this would help.

I think introducing another XML vocabulary into this document simply for
purposes of showing that you can put bad stuff in XML would be belaboring the
obvious.

Are you concerned that a scriptable editor that
stores scripts in metadata could be attacked by hand coding scripts
into structured comments in native Sieve?

For that to happen there would have to be a pretty serious bug in the
conversion process, so no, this is not the concern here at all.

Buffer overflow attacks on
conversion processors?

This would be another sort of conversion process bug and not relevant to the
concern at hand.

All this text is doing is point out the rather obvious fact that XML
namespaces allow you to mix vocabularies in a single document. As such, it
is possible to drag in some other vocabulary that has its own set of security
problems.

If this still isn't clear to you I'm sorry, but I'm at a loss as to how
to explain it further.

                                Ned

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf