Yes, that's explicitly allowed.

Cheers,


On 01/12/2008, at 4:55 PM, Alan Ruttenberg wrote:


OK.
If in a link header, do you imagine that relative URI for the target
would be acceptable?
-Alan

On Mon, Dec 1, 2008 at 12:31 AM, Mark Nottingham <[EMAIL PROTECTED]> wrote:
That's true, but it's an example, not a specification; furthermore, the head
section is shown complete (i.e., there is a close tag) without a base
element...

It's important to differentiate between relative references in the relation type (e..g, rel) and the target URI. The text about not using in- document
base URIs only applies to the relation type, not the target URI.

Cheers,


On 01/12/2008, at 2:19 PM, Alan Ruttenberg wrote:


Hello Mark,

One minor comment concerning the conversion the profile to link. In
that example, a relative URI is used as the target of the link.
Correct me if I am wrong, but couldn't the html document in which the
original link was embedded have had an explicit <base> element?
Elsewhere you point out that the document <base> elements can't be
used to resolve relative URIs in Link headers. Therefore in some cases
the example, if copied literally, would lead to errors.

-Alan


On Sun, Nov 30, 2008 at 8:11 PM, Mark Nottingham <[EMAIL PROTECTED]> wrote:

This is a fairly substantial rewrite of the spec, based upon the
observation
that the link header really isn't the central concept here; it's link
relations themselves.

Changelog:

o  Inverted focus from Link headers to link relations.
o  Specified was a link relation type is.
o  Based on discussion, re-added 'rev'.
o Changed IESG Approval to IETF Consensus for relation registrations
(i.e., require a document).
o  Updated RFC2434 reference to RFC5226.
o  Registered relations SHOULD conform to sgml-name.
o  Cautioned against confusing relation types with media types.

I'm particularly interested in feedback regarding registration
requirements,
as I think that's the biggest remaining sticking point. Note that it was previously "IESG Approval"; I've changed it to "IETF Review" (nee "IETF Consensus") so that a document is required. Also, I believe this still accommodates other standards orgs (like the W3C) using their processes to
publish documents that register entries, just as with media types.

Assuming this is acceptable and no serious shortcomings are found in this
draft, I think this document is ready to progress; i.e., I believe
(speaking
as an individual) there is consensus within the Atom community to make
the
registry modifications, and the feedback I've heard from the HTML
community
is that it's not necessary to have a tight integration with HTML4 or
HTML5.

Regards,


Begin forwarded message:

From: IETF I-D Submission Tool <[EMAIL PROTECTED]>
Date: 1 December 2008 12:03:54 PM
To: [EMAIL PROTECTED]
Subject: New Version Notification for
draft-nottingham-http-link-header-03


A new version of I-D, draft-nottingham-http-link-header-03.txt has been
successfuly submitted by Mark Nottingham and posted to the IETF
repository.

Filename:        draft-nottingham-http-link-header
Revision:        03
Title:           Link Relations and HTTP Header Linking
Creation_date:   2008-12-01
WG ID:           Independent Submission
Number_of_pages: 15

Abstract:
This document specifies relation types for Web links, and defines a
registry for them.  It also defines how to send such links in HTTP
headers with the Link header-field.



The IETF Secretariat.




--
Mark Nottingham     http://www.mnot.net/






--
Mark Nottingham     http://www.mnot.net/





--
Mark Nottingham     http://www.mnot.net/

Reply via email to