Spencer Dawkins wrote:
I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Summary: This document is on the right track for publication as a
Proposed Standard. Most of my comments involve SHOULD requirements.
Review Comments:
In Section 3, "Lemonade clients SHOULD take advantage of these
features." doesn't look like a normative/2119 "SHOULD".
Right, clients can always choose to use a subset of available
extensions. So I've changed that to:
Lemonade clients should take advantage of these features as appropriate.
In section 3.3, I suppose the SHOULD NOT in
A LEMONADE compliant client SHOULD use message size declaration. In
particular it SHOULD NOT send a message to a mail submission server,
if the client knows that the message exceeds the maximal message size
advertised by the submission server.
is OK, but is this required? ("When is it OK to send a message that
exceeds the maximal message size advertised by the submission server?")
Generally it is not Ok for the client to send a message that exceeds the
maximal message size advertised by the submission server.
But let me try to explain what this sentence is trying to say and why.
The whole "SHOULD NOT" part is conditional on "if the client knows".
When I wrote this sentence I was thinking about a client that generates
message on the fly and doesn't know in advance how big the message is
going to be (for example this is a cell phone that sends a message with
attachment, the attachment in generated/downloaded on the fly).
Thinking more about this, I think SHOULD NOT should be changed to MUST
NOT. Does everybody agree?
Thanks,
Spencer Dawkins
Other Comments for Editors:
I'm somewhat surprised to see two methods of "forward without
download" described in Section 2.4 (extended APPEND and BURL/BDAT),
because I would have thought that profiles were trying to prevent this
kind of duplication, but the WG should know best.
The working group was originally doing extended APPEND, but later on
realized that BURL/BDAT can also be used. Both method have slightly
different applicability cases, so the WG decided to document both.
A significant portion of the document (Section 2.4) is an example that
might make a good appendix - I'm not sure if it is (or needs to be)
normative text for a Proposed Standard.
Obviously examples can't be normative, but they are the meat of the
document, explaining how all pieces fit together. There are many
requirements in referenced documents and some of them are easy to
overlook, so complete examples highlight such requirements.
I would rather not move examples to the appendix at this late stage.
I am slightly confused about the target of Proposed Standard for
profiles, but let's not even go there.
Ok :-).
Regards,
Alexey
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
