Subject: [APPS-REVIEW] [Fwd: Review of metalink I-D]

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Oct 2009 10:28:12 -0600

Thanks, Mark!

I notice that you sent this to apps-discuss. Indeed, that might be a
better place to send reviews than apps-review, because apps-discuss has
broader distribution and anyone can subscribe (although it is always
best to cc the authors).

Are there any objections to making that team policy? We would retain
apps-review for team discussions (requesting reviews, complaints about
the team leads, etc.).

/psa

- -------- Original Message --------
Subject: Review of metalink I-D
Date: Thu, 29 Oct 2009 21:46:23 -0300
From: Mark Baker <[email-masked]>
To: [email-masked]

This is my review of draft-bryan-metalink-21.

- - sec 3, last paragraph, it is mentioned that some kinds of white
space can produce an "invalid" document, yet no where is it defined
what that means

- - sec 4.1.2.1.  not sure why "name" is a MUST.  I'm sure metalink
agents can pick a reasonable one, or ask the user, but if it was
required then they might not include this logic.

- - sec 4.2.3.  If metalink:dynamic is intended to be a cue to agents to
redownload the file periodically, you probably also want to give them
an indication of how often to do so.  HTTP caching could be used to do
that.

- - sec 4.2.6, the Openoffice example confused me briefly.  You need to
make sure it's seen to be an example, and also that "OpenOffice.org"
isn't the only possible value.  Perhaps change to;

   The "metalink:identity" element is a Text construct that conveys a
   human-readable name for a file.  For example, the identity of
OpenOffice.org
   3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0".

- - sec 4.2.10.2.  do we really need to use a special "torrent" type
when "application/x-bittorrent" could be used?  I'd prefer to stick
just to media type syntax and get rid of the reserved syntax.  You
should also call them "media types" instead of (or as well as if you
prefer) MIME types, and include a reference to BCP 13.

- - in sec 6.3, it's not within the authority of a protocol
specification to tell agents that they "MUST NOT stop processing" or
"MUST NOT change their behaviour".  They might have their own
perfectly good reasons for, say, halting if some XHTML with Javascript
were included.  I agree with what you're trying to accomplish, but
that should be specified by saying, for example, that extensions can
be ignored.

Overall, a decent spec.  It's nice to see extensibility given
considerable attention for a change.

Mark.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Mark Baker <[email-masked]>
Date: Fri, 30 Oct 2009 14:26:41 -0300

On Fri, Oct 30, 2009 at 1:28 PM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks, Mark!
>

I sent my review to apps-discuss primarily because I assumed that was
already the case, but agree it would make for a good policy.

Agreed about CCing the authors too.

Mark.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Oct 2009 11:36:15 -0600

> Agreed about CCing the authors too.

OK, we have rough consensus. ;-)

http://www.apps.ietf.org/content/applications-area-review-team has been
updated accordingly.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Oct 2009 16:04:03 -0400

> http://www.apps.ietf.org/content/applications-area-review-team has been
...
> Reviewers: Please send all reviews to the apps-discuss list and make
> sure to cc the author(s) of the specification you are reviewing!

I think we should also CC the working-group chairs, for documents that
belong to WGs, and the document shepherd, if the document has a
shepherd and that shepherd is not one of the chairs.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Oct 2009 14:21:53 -0600

> shepherd and that shepherd is not one of the chairs.

Is there a straightforward way to discover the document shepherd? I
don't see that information listed in the datatracker, but I might be
missing something.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Fri, 30 Oct 2009 14:09:27 -0700

>don't see that information listed in the datatracker, but I might be

You can use https://datatracker.ietf.org/idtracker/  I'll use Lisa's 
I-D as an 
example. 
https://datatracker.ietf.org/idtracker/draft-dusseault-http-patch/ 
mentions the responsible I-D and the Document Shepherd.

An I-D may not have been assigned to an AD or have a Document 
Shepherd yet.  Should the team review such an I-D?  I'll say maybe if 
it helps the Apps Area ADs decide whether to sponsor the I-D.  But 
you may be reviewing the document too early then (see Alexey's 
message about the intent).

The bottom line is whether to use the process to determine the 
acceptable level of quality for an I-D to be reviewed.

Regards,
S. Moonesamy

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Oct 2009 15:17:59 -0600

On 10/30/09 3:09 PM, SM wrote:
> You can use https://datatracker.ietf.org/idtracker/  I'll use Lisa's I-D
> as an example.

Aha, I had ended up at
https://datatracker.ietf.org/drafts/draft-dusseault-http-patch/ instead
of https://datatracker.ietf.org/idtracker/draft-dusseault-http-patch/

> An I-D may not have been assigned to an AD or have a Document Shepherd
> yet.  Should the team review such an I-D?  I'll say maybe if it helps
> the Apps Area ADs decide whether to sponsor the I-D.  But you may be
> reviewing the document too early then (see Alexey's message about the
> intent).

In general we will be reviewing documents in IETF Last Call, so they
will have at least an AD and perhaps a shepherd. We will complete early
reviews if requested, but I think that will be exceptional.

> acceptable level of quality for an I-D to be reviewed.

Yes.

Peter

- --
Peter Saint-Andre
https://stpeter.im/