Does anybody have feedback on the suggestions/questions below?
If I don't get any feedback on the ABNF or validity discussions, I'll proceed as outlined. I think there needs to be *some* feedback regarding the link relation registry; I'm proposing substantial changes there (my preferred approach is to change it so that IETF Consensus, rather than IESG approval, is required to register a link relation). Anybody have thoughts?
On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote:
Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt instead
of RFC 2234 and confirm that everything that was valid before is still
valid. The IESG approved this document as a Draft Standard last week.
Rob/Mark?
Hmm. As far as I can tell, the *only* place where we actually define a rule is 4.2.9.2, and that's just combining two rules by reference. I wonder if we can save complexity here (and remove one normative reference) by just doing this in prose; the text is currently:
[[[
ABNF for the "rel" attribute:
rel_attribute = isegment-nz-nc / IRI
The value of "rel" MUST be string that is non-empty, does not contain
any colon (":") characters, and matches the "isegment-nz-nc" or "IRI"
ABNF forms in [RFC3987].
]]]
So it seems like the ABNF is extraneous here, and if we dropped it, we could also drop the reference.
(Just a suggestion, I'm also happy to change the reference.)
Section 2 describes a requirement for well-formedness, but it doesn't
mention validity. I suspect that validity isn't a requirement given that
the RELAX NG schema is informative, but it would be better if a specific
statement were included to note that validity is not a requirement.
Hmm, I would say that validity isn't a requirement because the syntactic constraints are (we think) fully given in the text. The group consciously decided not to make the schema normative, for that reason. We do currently say that the schema is non-normative; having said that, a statement that there is no DTD and no validity requirement couldn't hurt. Rob/Mark?
Suggest adding the following after "Atom Documents MUST be well-formed XML.";
[[[This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML).]]]
Section 7.1: what process is the IESG supposed to use to review registration
requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms that might
be used and please specify one in the document.
Hmm. Looking over this, I wonder why IESG approval was the path chosen, given that URIs can also be used. It seems like the natural bar for getting something into the registry would be IETF consensus; can someone comment as to why this was chosen (I didn't participate in the discussions surrounding this registry)?
If we remain on an IESG approval path, such text would probably look something like; "Registered link relations SHOULD be widely implemented, since they effectively serve as shortcuts for URIs; as such, proposals need to demonstrate that there is community value in minting such a shortcut."
Also, it may be good to replace the list of suggested topics with a registration template, to get more uniformity and make IANA's life easier (sorry I didn't notice this earlier).
Finally, has someone doubled-checked with IANA that the "http://www.iana.org/assignments/relation/"; URI is available and appropriate?
-- Mark Nottingham http://www.mnot.net/
