Subject: [Gen-art] Gen-ART review of draft-ietf-lemonade-profile-07

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 27 Jan 2006 15:49:21 -0600

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

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?")

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.

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.

I am slightly confused about the target of Proposed Standard for profiles, 
but let's not even go there.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Jan 2006 00:18:13 +0000

Spencer Dawkins wrote:

> I was selected as General Area Review Team reviewer for this 
> specification (for background on Gen-ART, please see 
> 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.

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

> 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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 31 Jan 2006 07:06:50 -0600

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:

Review Comments:

Right, clients can always choose to use a subset of available extensions. So 
I've changed that to:

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

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.

Regards,
Alexey