Hi, Alexey,
Thanks for your quick response. Your replies look mostly fine - I had two
that I wanted to follow up about:
- the suggested "MUST NOT send messages that the client knows are too big"
is OK, but I'm not sure how important it is to say anything - even changing
"SHOULD NOT" to "should not" would be fine. My comment was only that there
was a "SHOULD NOT" with no qualifying text. "SHOULD NOT, unless the client
is generating the message dynamically and doesn't know how big the message
will be" would also be fine.
- On UPDATE vs BURL/BDAT - I'm in over my head here, so please don't read
this as a technical comment - it's OK to define two ways of doing the same
thing, but the document says that UPDATE is the way to do it (in Section
2.1, and maybe even in Section 2.2), and doesn't mention BURL/BDAT until the
last paragraph in Section 2.4. Section 2.1 does mention "IMAP [URLAUTH]
extension" - is this the same thing as BURL/BDAT? If so, consistent terms
would help. I didn't read either Section 2.1 or Section 2.2 as saying,
"there are two ways of accomplishing this, and you have to support both of
them". And I didn't see any text that explained the "slightly different
applicability cases". I'm not questioning any of this, I'm just saying that
I didn't understand what you needed me to understand.
- as you point out, it's late in the game. Just for next time - some
protocol specifications split out examples into non-normative appendixes, or
even into Informational RFCs. Doing major surgery at this point, after WG
consensus, seems excessive.
Thanks,
Spencer
----- Original Message -----
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
