The Metalink Download Description Format
draft-bryan-metalink-28

[Ballot discuss]
This is a "meta-discuss' to ask a couple of clarifying questions.

What is the purpose of the "metalink:os" element?  How would an entity use the "metalink:os" element?

The list at http://www.iana.org/assignments/operating-system-names was "last updated 2009-09-28".  Not a criticism, just curiosity - the list seems incomplete (Windows XP, Vista, 7; Linux 2.6 missing?), so I'm curious about the utility of the list utility.

A somewhat more philosophical question, triggered by "metalink:os": what constitutes the contents of a "file"?  For UNIX and related filesystems, we customarily think of a "file" as an undifferentiated linera array of bytes.  What about line terminators?  Other filesystems (please don't ask me to try to recall my knowledge IBM OS filesystem details from 25 years ago) may have internal structure information that is included in the "file" but is not really part of the "data".

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed.

1) The request for media type review was sent out to the ietf-types@ mailing list. After waiting for 2 weeks for review and confirming that there are no significant issues raised, I will clear this part of the DISCUSS.

[Ballot comment]
5.3.  Processing Foreign Markup

  Metalink Processors that encounter foreign markup in a location that
  is legal according to this specification MUST NOT stop processing or
  signal an error.

Are you saying that any foreign markup "MUST be ignored"?

  When unknown foreign markup is encountered in a Text Construct,
  software SHOULD ignore the markup and process any text content of
  foreign elements as though the surrounding markup were not present.

Can you give me an example here?

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed.

1) The request for media type review was sent out to the ietf-types@ mailing list. After waiting for 2 weeks for review and confirming that there are no significant issues raised, I will clear this part of the DISCUSS.

[Ballot comment]
5.3.  Processing Foreign Markup

  Metalink Processors that encounter foreign markup in a location that
  is legal according to this specification MUST NOT stop processing or
  signal an error.

Are you saying that any foreign markup "MUST be ignored"?

  When unknown foreign markup is encountered in a Text Construct,
  software SHOULD ignore the markup and process any text content of
  foreign elements as though the surrounding markup were not present.

Can you give me an example here?


Example in 4.2.13 - Informative reference to OpenPGP spec?

Is support for PGP signatures required?

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed.

1) The request for media type review was sent out to the ietf-types@ mailing list. After waiting for 2 weeks for review and confirming that there are no significant issues raised, I will clear this part of the DISCUSS.

[Ballot comment]
4.2.4.  The "metalink:hash" Element

  The "metalink:hash" element is a Text construct that conveys a hash,
  also known as a checksum, for a file.

Is this element Language-Sensitive?

4.2.6.  The "metalink:language" Element

  The "metalink:language" element is a Text construct that conveys a
  code for the language of a file, per [RFC5646].

  metalinkLanguage =
      element metalink:language {
        metalinkTextConstruct
      }

Is this element Language-Sensitive?

What does it mean to have multiple matalink:language elements for a file?

4.2.8.2.  The "type" Attribute

  metalink:metaurl elements MUST have a "type" attribute that indicates
  the MIME media type [RFC4288] of the metadata available at the IRI.
  In the case of BitTorrent as specified in [BITTORRENT], the value
  "torrent" is required.  Types without "/" are reserved.  Currently,
  "torrent" is the only reserved value.

I think it would have been better to use a different name for this attribute to avoid confusion with type
used in "hash" elements. But I understand that there are multiple implementations already and that that
might be difficult to change.

4.2.10.  The "metalink:os" Element

  The "metalink:os" element is a Text construct that conveys an
  Operating System for a file.  The IANA registry named "Operating
  System Names" defines values for OS types.

  metalinkOS =
      element metalink:os {
        metalinkTextConstruct
      }

Is this element Language-Sensitive as well?

4.2.13.  The "metalink:signature" Element

  The "metalink:signature" element is a Text construct that conveys a
  digital signature for a file described in a Metalink Document.
  Digital signatures verify that a file is from the entity that has
  signed it.

  metalinkSignature =
      element metalink:signature {
        attribute type { text },
        metalinkTextConstruct
      }

Is this element Language-Sensitive as well?


4.2.14.  The "metalink:size" Element

  The "metalink:size" element indicates the length of the linked
  content in octets; it is a hint about the content length of the
  representation returned when the IRI is mapped to a URI and
  dereferenced.

So this value doesn't have to be precise?

5.3.  Processing Foreign Markup

  Metalink Processors that encounter foreign markup in a location that
  is legal according to this specification MUST NOT stop processing or
  signal an error.

Are you saying that any foreign markup "MUST be ignored"?

  When unknown foreign markup is encountered in a Text Construct,
  software SHOULD ignore the markup and process any text content of
  foreign elements as though the surrounding markup were not present.

Can you give me an example here?


Example in 4.2.13 - Informative reference to OpenPGP spec?

Is support for PGP signatures required?

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed. I believe it would be easy to address them with some RFC Editor notes.

1) I don't think the document is very clear on which elements are Language Sensitive. Section 3.1 says:

3.1.  Text Constructs

  A Text construct contains human-readable text, usually short in
  length.  The content of Text constructs is Language-Sensitive.

Which I originally interpreted to mean that any element defined as
a "Text construct" is Language-Sensitive. But this doesn't seem to be the case (see the Comment section of this message).

I would recommend deleting text about all textual constructs being Language-Sensitive and explicitly listing all Language-Sensitive attributes instead.

2) Is any hash type mandatory to implement for metalink documents?
Section 7.4 says that documents SHOULD include "sha-256", but it doesn't quite say that all generators and consumers should support it.

3) 4.2.12.  The "metalink:publisher" Element

  The metalink:publisher element MAY have a "url" attribute whose value
  MUST be an IRI reference [RFC3987].  When dereferenced, the resulting
  URI (mapped from an IRI, if necessary) SHOULD produce a
  representation that is relevant to that agent.

what is the meaning of the last sentence (which agent?) and how can an implementation comply with the SHOULD?

4) The request for media type review was sent out to the ietf-types@ mailing list. After waiting for 2 weeks for review and confirming that there are no significant issues raised, I will clear this part of the DISCUSS.

[Ballot comment]
The kind of comments that are coming in indicate to me that this might have benefited going through a working group - at the least, I think it would have attracted more participation in its earlier review.

[Ballot comment]
I have a number of non-blocking comments:

1. For the readability of the document it would be useful if all acronyms were expanded at the occurence - IRI, DTD, etc.

2. section 4.1.1.1 - 'It is advisable that each metalink:file
  element contain a non-empty metalink:description element ...' - it looks like using 'it is RECOMMENDED ... ' is more appropriate

3. Section 4.1.2 - 'All metalink:url elements contained in each metalink:file element SHOULD lead to identical files.' - why SHOULD is used here and the rest of the paragraph and not MUST?

4. Section 4.2.8.2 - 'In the case of BitTorrent as specified in [BITTORRENT], the value "torrent" is required' - looks like capitalized REQUIRED is more appropriate.

[Ballot comment]
Section 4.2.4

While a hash and a checksum serve similar purposes, they are not equivalent.  I suggest the
following change:

OLD
  The "metalink:hash" element is a Text construct that conveys a hash,
  also known as a checksum, for a file.
NEW
  The "metalink:hash" element is a Text construct that conveys a
  cryptographic hash for a file.

[Ballot discuss]
As noted in Pasi's Discuss, the document does not contain sufficient information to result in
interoperabie digital signatures. Without specification of a mandatory to implement MIME
media type in 4.2.13.1, families of non-interoperable generators and processors seem
inevitable.

Even with a common media type, interoperability may fail due to the selected cryptographic algorithms.  Specifying mandatory to implement algorithms (e.g., RSA with SHA-256 for
signatures, SHA-256 for hashes) and reasonable key sizes (e.g., MUST support 2048 RSA
keys) would provide some basis for selecting algorithms where broad interoperability is
desired.

[Specification of one more SHOULDs in each case (media type, hash, and signature algorithms)
would be advantageous imho, but is not strictly necessary.  I would list this as a comment,
but it would be out of context!]

Discussion of how metalink processors handle (1) unrecognized media types or cryptographic
algorithms and (2) legacy/marginal algorithms or key sizes (i.e., MD5 or 512 bit RSA) s
needed as well.

[Ballot comment]
I agree with Ralph's discuss that the IANA "Operating System Names"
is unlikely to be very useful, since all the most common operating
systems are missing from it...

[Ballot discuss]
I have reviewed draft-bryan-metalink-25, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:

- Section 7 doesn't really contain sufficient information for
interoperable signing of metalink documents. RFC 4287 Section 5 has an
example what those details should look like.

- At least Sections 4.2.16 and 4.2.12 (and perhaps 4.2.8 and 4.2.9,
too) should explicitly remind the reader about xml:base.  Also, I
think it would be good to use xml:base in one of the examples --
otherwise, it's way too easy for implementors to miss that they can't
just e.g. pass the contents of  tag to their HTTP library (or
similar).

- The ABNF in 4.2.3 seems incomplete; "token" is not defined, and if
"token" can contain any characters, then the ABNF matches all possible
strings (so it's rather useless). Perhaps the intent was to use
the definition from RFC 2616, Section 2.2?

- Section 4.2.8.2 and 4.2.13.1: is this just the type/subtype, or can it
also contain parameters, like the MIME and HTTP Content-Type headers?

[Ballot discuss]
This is a "meta-discuss' to ask a couple of clarifying questions.

What is the purpose of the "metalink:os" element?  How would an entity use the "metalink:os" element?

The list at http://www.iana.org/assignments/operating-system-names was "last updated 2009-09-28".  Not a criticism, just curiosity - the list seems incomplete (Windows XP, Vista, 7; Linux 2.6 missing?), so I'm curious about the utility of the list utility.

A somewhat more philosophical question, triggered by "metalink:os": what constitutes the contents of a "file"?  For UNIX and related filesystems, we customarily think of a "file" as an undifferentiated linera array of bytes.  What about line terminators?  Other filesystems (please don't ask me to try to recall my knowledge IBM OS filesystem details from 25 years ago) may have internal structure information that is included in the "file" but is not really part of the "data".

[Ballot comment]
Section 3.2., paragraph 6:
>    Date values SHOULD be as accurate as possible.  For example, it would
>    be generally inappropriate for a publishing system to apply the same
>    timestamp to several Metalink Documents that were published during
>    the course of a single day.

  Can we say a bit more precisely how accurate is considered accurate
  enough?

[Ballot discuss]
Section 2., paragraph 11:
>    Metalink Documents that do not follow this specification are invalid,
>    and partially or wholly unusable to Metalink Processors.

  DISCUSS: How should invalid documents be handled? The safest/easiest
  approach is to say that they MUST NOT be used to retrieve the object
  and that an error should be thrown, but the "partially unusable"
  statement leads me to believe that this is not the intent here. So,
  something needs to be said about how implementations should deal with
  invalid documents.


Section 4.1.2., paragraph 2:
>    All metalink:url elements contained in each metalink:file element
>    SHOULD lead to identical files.  That is, each metalink:url element
>    should be an alternative location for the same file and each
>    metalink:metaurl element should provide metadata to retrieve the same
>    file in another way, such as a peer to peer network.

  DISCUSS: Why is this not a MUST? When is it ever useful to have these
  url elements point to different files?

[Ballot comment]
4.2.4.  The "metalink:hash" Element

  The "metalink:hash" element is a Text construct that conveys a hash,
  also known as a checksum, for a file.

Is this element Language-Sensitive?

4.2.6.  The "metalink:language" Element

  The "metalink:language" element is a Text construct that conveys a
  code for the language of a file, per [RFC5646].

  metalinkLanguage =
      element metalink:language {
        metalinkTextConstruct
      }

Is this element Language-Sensitive?

What does it mean to have multiple matalink:language elements for a file?

4.2.8.2.  The "type" Attribute

  metalink:metaurl elements MUST have a "type" attribute that indicates
  the MIME media type [RFC4288] of the metadata available at the IRI.
  In the case of BitTorrent as specified in [BITTORRENT], the value
  "torrent" is required.  Types without "/" are reserved.  Currently,
  "torrent" is the only reserved value.

I think it would have been better to use a different name for this attribute to avoid confusion with type
used in "hash" elements. But I understand that there are multiple implementations already and that that
might be difficult to change.

4.2.10.  The "metalink:os" Element

  The "metalink:os" element is a Text construct that conveys an
  Operating System for a file.  The IANA registry named "Operating
  System Names" defines values for OS types.

  metalinkOS =
      element metalink:os {
        metalinkTextConstruct
      }

Is this element Language-Sensitive as well?

4.2.13.  The "metalink:signature" Element

  The "metalink:signature" element is a Text construct that conveys a
  digital signature for a file described in a Metalink Document.
  Digital signatures verify that a file is from the entity that has
  signed it.

  metalinkSignature =
      element metalink:signature {
        attribute type { text },
        metalinkTextConstruct
      }

Is this element Language-Sensitive as well?


4.2.14.  The "metalink:size" Element

  The "metalink:size" element indicates the length of the linked
  content in octets; it is a hint about the content length of the
  representation returned when the IRI is mapped to a URI and
  dereferenced.

So this value doesn't have to be precise?

5.3.  Processing Foreign Markup

  Metalink Processors that encounter foreign markup in a location that
  is legal according to this specification MUST NOT stop processing or
  signal an error.

Are you saying that any foreign markup "MUST be ignored"?

  When unknown foreign markup is encountered in a Text Construct,
  software SHOULD ignore the markup and process any text content of
  foreign elements as though the surrounding markup were not present.

Can you give me an example here?


Example in 4.2.13 - Informative reference to OpenPGP spec?

Is support for PGP signatures required?

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed. I believe it would be easy to address them with some RFC Editor notes.

1) I don't think the document is very clear on which elements are Language Sensitive. Section 3.1 says:

3.1.  Text Constructs

  A Text construct contains human-readable text, usually short in
  length.  The content of Text constructs is Language-Sensitive.

Which I originally interpreted to mean that any element defined as
a "Text construct" is Language-Sensitive. But this doesn't seem to be the case (see the Comment section of this message).

I would recommend deleting text about all textual constructs being Language-Sensitive and explicitly listing all Language-Sensitive attributes instead.

2) Is any hash type mandatory to implement for metalink documents?
Section 7.4 says that documents SHOULD include "sha-256", but it doesn't quite say that all generators and consumers should support it.

3) 4.2.12.  The "metalink:publisher" Element

  The metalink:publisher element MAY have a "url" attribute whose value
  MUST be an IRI reference [RFC3987].  When dereferenced, the resulting
  URI (mapped from an IRI, if necessary) SHOULD produce a
  representation that is relevant to that agent.

what is the meaning of the last sentence (which agent?) and how can an implementation comply with the SHOULD?

4) I wanted to let Lisa hold a DISCUSS on Media type registration (was it submitted to the ietf-types@ mailing list?), but I am already holding a DISCUSS on other issues.

[Ballot comment]
4.2.4.  The "metalink:hash" Element

  The "metalink:hash" element is a Text construct that conveys a hash,
  also known as a checksum, for a file.

Is this element Language-Sensitive?

4.2.6.  The "metalink:language" Element

  The "metalink:language" element is a Text construct that conveys a
  code for the language of a file, per [RFC5646].

  metalinkLanguage =
      element metalink:language {
        metalinkTextConstruct
      }

Is this element Language-Sensitive?

What does it mean to have multiple matalink:language elements for a file?

4.2.8.2.  The "type" Attribute

  metalink:metaurl elements MUST have a "type" attribute that indicates
  the MIME media type [RFC4288] of the metadata available at the IRI.
  In the case of BitTorrent as specified in [BITTORRENT], the value
  "torrent" is required.  Types without "/" are reserved.  Currently,
  "torrent" is the only reserved value.

I think it would have been better to use a different name for this attribute to avoid confusion with type
used in "hash" elements. But I understand that there are multiple implementations already and that that
might be difficult to change.

[Ballot discuss]
I am very pleased to see this document in IESG review and I will be voting Yes once my relatively minor issues are addressed. I believe it would be easy to address them with some RFC Editor notes.

1) I don't think the document is very clear on which elements are Language Sensitive. Section 3.1 says:

3.1.  Text Constructs

  A Text construct contains human-readable text, usually short in
  length.  The content of Text constructs is Language-Sensitive.

Which I originally interpreted to mean that any element defined as
a "Text construct" is Language-Sensitive. But this doesn't seem to be the case (see the Comment section of this message).

I would recommend deleting text about all textual constructs being Language-Sensitive and explicitly listing all Language-Sensitive attributes instead.

2) Is any hash type mandatory to implement for metalink documents?
Section 7.4 says that documents SHOULD include "sha-256", but it doesn't quite say that all generators and consumers should support it.

3)

IANA comments:

Upon approval of this document, IANA will do the following:

ACTION 1:

A new assignment in the Namespace sub-registry of the "IETF XML
Registry" located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
-------- ------------------------------- --------------------- ---------
metalink urn:ietf:params:xml:ns:metalink
[RFC-bryan-metalink-24]


ACTION 2:

A new application media type at
http://www.iana.org/assignments/media-types/application/

metalink4+xml [RFC-bryan-metalink-24]