ietf
[Top] [All Lists]

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

2009-08-18 18:33:12

On Aug 16, 2009, at 11:01 AM, Ned Freed wrote:

[...]

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'.

I think the confusion is that the text says very little one way or the other. You have assumptions in mind about the semantic knowledge of an editor that are not explicitly stated. A reader that was not privy to the process of creating this draft may come with a different set of assumptions, and may not draw the inferences you expect them to.

In my case, it seemed counter-intuitive that an implementer would be willing to implement sieve semantics but unwilling to deal with the syntax. Your "template" comment below illustrates a case where that makes more sense.


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.

That paragraph clarifies a lot. I think it would be helpful to include it in the draft.


...

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.

So am I understanding correctly that it's unreasonable to expect an editor to just leave metadata alone if it doesn't understand it, and it's also unreasonable to expect an editor to behave in a sane manner if its metadata gets stripped?

It seems like there are three choices here: You can expect editors to preserve metadata from other editors, you can allow stripping of metadata and expect editors to deal rationally with its loss, or you can expect that if a user uses more than one editor over the lifetime of a script, one or both of the editors is likely to fail in a non- graceful way.

Did the working group really choose the third option?


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 fail to understand why it is acceptable to put requirements on processors but not on editors. Certainly no one would expect an editor that does not implement this specification to be bound by any requirements in it. For that matter, you already have (admittedly weak) 2119 language referring to editors

But if you are unwilling to place normative requirements around this, it would still help quite a bit to have some non-normative guidance to the effect that, since there is no requirement for an editor to preserve metadata from another editor, an editor implementation can expect to have its metadata removed from any given script. It it does not handle this gracefully, bad user experiences are likely to result.



(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.

Okay, I can accept that.


>> 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.

It has been my experience that SHOULD level requirements that both significantly impact interoperability and offer no explicit guidance about the consequences of violation are some of the biggest sources of interoperability problems in existing specs.

I'm starting to think that the WG had very limited expectations of interoperability between implementations that use this format. I recall a sentence stating that you expected interoperability between editors and processors. I think an average reader would expect interoperability among multiple editor implementations and among multiple processor implementations. If the work group did not intend that degree of interop, it would be extremely helpful to have some sort of applicability statement to that effect.


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.

I think it's clear to me after reading your explanation. Am I correct in understanding that the point of that sentence was that any given namespace mayl have its own set of security considerations, and that is beyond the scope of this document? If that is a correct understanding, then I suggest replacing the last sentence with something to the effect of:

"Such facilities will come with their own sets of security considerations, which are beyond the scope of this document."


Also, you elided one of the questions from my previous email without responding:



-- Section 4.1, paragraph 11:  "Implementations MAY use this to
represent complex data
  about that sieve such as a natural language representation of sieve
  or a way to provide the sieve script directly."

I'm not sure I understand the last part  --are you saying this can be
used as an alternate encoding of the script?

Of course not. Since when do we have programs capalable of taking completely
arbitrary natural language statements and reliably encoding them into
programming language statements?

I see nothing unclear about this at all.

I get the part about representing a "natural language representation", but what did you intend by "... or a way to provide the script directly"?


Thanks!

Ben.


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