Nicolas provided review for this ID, well done! ID submission is down til the end of the month, so I'd appreciate it if everyone could go over our ID if possible.
the most current versions is in svn: http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/draft-bryan-metalink-10.txt ---------- Forwarded message ---------- From: Mark Nottingham <[email protected]> Date: 2009/7/16 Subject: Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard To: Nicolás Alvarez <[email protected]> Cc: [email protected], [email protected] Hi Nicolás, Thanks for reviewing; responses inline. On 17/07/2009, at 5:45 AM, Nicolás Alvarez wrote: > > Section 4 says: "As such, relation types are not format-specific, and MUST NOT > specify a particular format or media type that they are to be used with." > > Does this refer to the format or media type of the context or the target? > I think there are reasonable use cases for a relation type to specify what the > target format is supposed to be. For example, an application-specific > extension relation type to link http://example.com to an API endpoint > (whatever that means) could say the target must be (or should be) > application/x-example-format+xml. Or a relation type could say the target > must be a subtype of the image/ mime type. That's an interesting question; although that requirement has been discussed extensively, this aspect has not yet come up. The intent was that it apply to the target, the reason being that the relation type and media type are orthoganal (if the type of the relation needs to be contrained for a particular application, it can be done by that application, not in the definition of the relation type itself). I think it's equally applicable to the context (and this is already alluded to in separate text about not specifying the context in the relation type, although it doesn't mention the context's type specifically). All of that said, it's pretty clear that despite good practice and separation of concerns, people are going to want to do this whether we like it or not. Therefore, I'm inclined to loosen this requirement to SHOULD NOT (or even degrade it to a non-normative recommendation against) making extension (NOT registered) relation types format-specific. The benefit here is that doing this encourages application-specific relation types to be defined as extensions, which is their nominated purpose. > In the ABNF in section 5, enc2231-string refers to extended-value in section 7 > of RFC2231. However, "extended-value" isn't explicitly defined anywhere in > RFC. The strange thing is that it's *used* in other ABNF constructions of > RFC2231, like extended-parameter; but I don't see it in the left hand side of > any ":=" Ack. > Below the ABNF in section 5, it says: > "If the URI-Reference is relative, it MUST be resolved as per [RFC3986], > Section 5." > > Does this mean that if a client parsing a Link header finds a relative URI > reference, it MUST resolve it to an absolute URI; or does it mean a server > MUST resolve relative URIs to absolute URIs before sending the Link header to > a client? > > I think it should be clarified what side (client or server) that MUST applies > to. > Same for "If the anchor parameter's value is a relative URI[...]" in the > paragraph that follows. They're both parsing requirements; the syntax is unambiguous about what's allowed when produced. However, I'll try to tweak the text to make this more obvious. > Editorial issue: the last line of page 5 (second paragraph after ABNF in > section 5) should be moved to the beginning of page 6 for better readability. > (this is known as an "orphan line") Ack. > Apologies in advance if any of these issues were raised already (I'm not on > the mailing list myself), or if I'm posting to the wrong list for this topic. > > Since I'm not subscribed to the list (and I'm having technical problems to > access gmane.org), I'd appreciate if you Cc: me in any replies. Thank very much for the feedback! -- Mark Nottingham http://www.mnot.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
