- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 16 Sep 2009 16:55:00 +1000
- To: Anthony Bryan <anthonybryan@gmail.com>
- Cc: Nicolas Alvarez <nicolas.alvarez@gmail.com>, ietf-http-wg@w3.org
On 15/09/2009, at 1:59 PM, Anthony Bryan wrote: > On Mon, Sep 14, 2009 at 11:06 PM, Mark Nottingham <mnot@mnot.net> > wrote: >> >> On 08/09/2009, at 11:19 AM, Anthony Bryan wrote: >> >>> Here's what I have now. More inclusive is good but I think someone >>> else would be better at writing it than me. >>> >>> http://tools.ietf.org/html/draft-bryan-metalinkhttp >>> >>> Link Relation Type Registration: "duplicate" >>> >>> o Relation Name: duplicate >>> o Description: Refers to an identical resource that is a >>> byte-for-byte equivalence of representations. >> >> Does this imply that each resource has exactly the same set of >> representations, or that when two resources share representations, >> those >> representations are duplicates? > > The latter. > > Any suggestions for replacement text? Because what I have isn't > cutting it. Hm. Refers to a resource whose available representations are byte-for-byte identical with the corresponding representations of the context IRI. >>> Here's what it looks like: >>> >>> Link: <http://www2.example.com/example.ext>; rel="duplicate"; >>> Link: <ftp://ftp.example.com/example.ext>; rel="duplicate"; >>> Link: <http://example.com/example.ext.torrent>; rel="describedby"; >>> type="torrent"; >> >> Do torrents have media types yet? > > Not as far as I know. > > Which is also why in draft-bryan-metalink we have this: > > 4.2.10.2. The "type" Attribute > > metalink:metaurl elements MUST have a "type" attribute that > indicates > the MIME type 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. Overloading type like that is bad; register a media type (or get the appropriate people to do it). Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 16 September 2009 06:55:41 UTC