Subject: AD Review Comments and Questions: draft-ietf-atompub-format-07

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 5 Apr 2005 11:39:47 -0400

Your working group chairs have asked me to shepherd
draft-ietf-atompub-format-07 through IETF last call.  As part of that
process, I have an obligation to review the document myself.  I've completed
my review and I'd like to share my comments and a few questions with the
group.

A new version of the document is probably needed before I can submit the
last call request.  I don't think I found any major problems, but I'd prefer
to close known issues before asking the community for input -- especially
since this working group has never met at a face-to-face IETF meeting.

I intend to ask the XML Directorate to review the document during the last
call period.  Anything they find can be dealt with along with any other last
call comments.

Comments/Questions:

The document includes an informative RELAX NG schema and several examples.
What has been done to confirm that the schema is free of errors and that all
of the examples given in the document are valid according to the schema?  (I
could check an XML Schema myself, but I don't have the tools I need to check
RELAX NG.)

Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming XML
namespaces.  Why are namespace URIs (such as http://purl.org) that don't
conform to this practice being used?

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.

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.

Section 4: RFC 2045 is referenced.  2045 is on its way to being obsoleted by
draft-freed-mime-p4 (in the RFC Editor queue) and draft-freed-media-type-reg
(in last call).  Can the more recent documents be referenced instead of
2045?

The MIME media type registration template included in section 7 MUST be
submitted to the ietf-types list ([email-masked]) for review.  A
two-week review period is standard for requests to register new types in the
standards tree.  Please see the list archives [1] for samples if help is
needed in crafting a review request and please send the request ASAP.

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.

-Scott-

[1]
http://eikenes.alvestrand.no/pipermail/ietf-types/

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Apr 2005 12:04:56 -0400

> could check an XML Schema myself, but I don't have the tools I need to check

The draft is generated from an RFC2629 XML file which contains no schema 
fragments or examples. The schema fragments are generated from the full 
schema. To create the text version, the schema, fragments, and examples 
are inserted in a SAX pipeline, and xml2rfc.tcl generates the draft from 
the resulting document. Since the schema and examples are stored in 
separate files, it's easy to check them with a command-line validator. I 
use James Clark's Jing[0].

Robert Sayre

[0] http://www.thaiopensource.com/relaxng/jing.html

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Apr 2005 12:20:32 -0400

Robert Sayre wrote:
> 
> Scott Hollenbeck wrote:
>> that all
>> of the examples given in the document are valid according to the 
>> schema? 

Oh, you said *all*. The document fragments haven't been automatically 
checked, and I just spotted one mistake. The link element in 4.2.9.2 is 
broken.

I'm not sure what we can do to ensure the small document fragments are 
valid, other than read them closely.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Apr 2005 09:26:22 -0700

> call period.  Anything they find can be dealt with along with any 

For the WG's info: The Directorate is a volunteer group of alleged "XML 
experts" that reviews I-D's that use XML; I'm one of them, BTW.

> schema?  (I

Norm/Rob/Mark?

> conform to this practice being used?

Our plan, as we discussed with you & Ted. last year, is to use a W3C 
namespace.  The current value is a placeholder.  Should we note this in 
-08?

> valid.  The IESG approved this document as a Draft Standard last week.

Rob/Mark?

> 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?

> (in last call).  Can the more recent documents be referenced instead of

Rob/Mark?

> needed in crafting a review request and please send the request ASAP.

Scott, what's the scheduling on that?  Do we launch that right now, 
independent of the rest of the document review process?

> be used and please specify one in the document.

Paul, care to take the lead on this?  -Tim

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Apr 2005 18:37:54 +0200

>namespace.  The current value is a placeholder.  Should we note this in 

Do you have a pointer to this?

>> [draft-freed-media-type-reg]
>
>Rob/Mark?

(Note that this is also a matter of reviewing the draft
and checking that we took all differences into account).

>> submitted to the ietf-types list ([email-masked]) for 
>> review.

>independent of the rest of the document review process?

We should announce this to [email-masked] aswell.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 5 Apr 2005 12:56:56 -0400

Robert,

Thanks, but you didn't answer all of my question.  Has someone (you?)
confirmed that the schema and examples are consistent?  I really don't have
the time to double-check something that the working group should have done
itself if that means installing and getting familiar with a new software
package.

I saw your follow-up; thanks.

-Scott-

> -----Original Message-----
> From: Robert Sayre [mailto:[email-masked]] 
> Sent: Tuesday, April 05, 2005 12:05 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: RNG and examples (was: AD Review Comments and 
> Questions: draft-ietf-atompub-format-07)
> 
> 
> Scott Hollenbeck wrote:
>

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 5 Apr 2005 13:04:04 -0400

> From: Tim Bray [mailto:[email-masked]] 
> Sent: Tuesday, April 05, 2005 12:26 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: AD Review Comments and Questions: 
> draft-ietf-atompub-format-07
> 
> 

[snip]

> > Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice 
> for naming 
> > XML

There needs to be both text explaining why IETF practice isn't being used
and there needs to be an identified URI.  We don't need the URI *right now*,
but I want it in the document BEFORE I bring the document to the IESG for
review.  Explanatory text will suffice for last call purposes.

[snip]

> > review.  A
> > two-week review period is standard for requests to register 
> new types 
> > in the
> > standards tree.  Please see the list archives [1] for 
> samples if help 
> > is

Start it now.  It can run concurrent with or before the last call.  If you
wait until after the last call starts it becomes the gating factor to having
the document ready for IESG review.

-Scott-

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Apr 2005 13:02:59 -0400

Scott Hollenbeck wrote:

> confirmed that the schema and examples are consistent?  

OK, I'm probably not the best person to check the examples. Volunteers?

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2005 11:06:40 -0700

>Paul, care to take the lead on this?  -Tim

Nope. Scott: can you be more specific about your question? Section 
7.1 seems pretty clear to me, but I'm possibly missing something.

>There needs to be both text explaining why IETF practice isn't being used

Good.

>and there needs to be an identified URI.

Bad.

>   We don't need the URI *right now*,

Just to be clear: you are asking us to get the final URI for the 
namespace *before* the IESG has approved of the document. That means 
that it is really, really likely that some implementers will write 
and deploy code based on the draft that is going to the IESG, not 
waiting to see if the IESG demands changes for the wire protocol or 
the MUSTs and SHOULDs.

Do you really want that (he asks pejoratively)?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 5 Apr 2005 14:25:03 -0400

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Tuesday, April 05, 2005 2:07 PM
> To: Tim Bray; Scott Hollenbeck
> Cc: [email-masked]

As described in 2434, "IESG Approval", "though the IESG has discretion to
request documents or other supporting materials on a case-by-case basis".
I'd really like to see some guidance in the document to describe what the
IESG should look for.  We're not atom experts, so it's going to be hard to
determine what we should and shouldn't approve.  Another paragraph will help
future IESGs understand what they need to consider when reviewing requests.

> Do you really want that (he asks pejoratively)?

Hmm.  Part of the problem is that there is no "normal" editing opportunity
once the document is in the hands of the IESG.  The editors can make changes
as a result of IESG review, or in auth48, but those changes are supposed to
be directed.  Auth48 changes are supposed to be editorial only.  This is
clearly a normative situation.

The other part of the problem is that you're asking the IESG to review a
specification that is incomplete without that little detail, and what's in
there now looks very obviously non-standard.  If you want to pursue a course
of action that is similar to what was done with the IDN prefix [1] you're
going to have to be a bit more clear about why the spec is incomplete.  I'm
OK with that, but please add text to the document to explain what needs to
be done, who will do it, and when it needs to be done.  Include a note that
says "this paragraph to be removed by the RFC Editor" if appropriate.  If
this all means that the URI will be provided to the RFC Editor when they ask
for it to finish the document, fine -- just say so.

-Scott-

[1]
I'll let Paul explain this reference if anyone asks.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2005 11:38:34 -0700

>request documents or other supporting materials on a case-by-case basis".

Right.

>future IESGs understand what they need to consider when reviewing requests.

Sounds reasonable. (I was erring on the side of not micro-managing 
the IESG.) Rob/Mark: please take a shot at some guidance for them.

>clearly a normative situation.

Correct. I was assuming that, once everything else got approved, you 
would put a DISCUSS vote on the document because of the lack of final 
namespace. We then ask the W3C for it, get it, tell you, and make the 
change to the n+1 version of the document (along with the editorial 
comments that often come out of an IESG review). Does that sound 
doable?

>going to have to be a bit more clear about why the spec is incomplete.

I'm fine with that. And, yes, I was modelling this process after than one.

>   I'm

My preference is that the namespace be minted and included between 
the time that all other issues are cleared and when it is sent to the 
RFC Editor. In retrospect, we could have done that for the IDN spec 
as well. Does that work for you?

--Paul Hoffman, Director

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 5 Apr 2005 14:44:30 -0400

> comments that often come out of an IESG review). Does that sound 

Yes, we can do it this way.  Just please add some text so that so that IESG
reviewers understand that this is a known issue that we have a plan to
address.

-Scott-

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 05 Apr 2005 21:28:48 +0100

> OK, I'm probably not the best person to check the examples. Volunteers?

Me. Will be back to you in 24h.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Apr 2005 17:13:38 -0700

>> valid.  The IESG approved this document as a Draft Standard last week.

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.)

Also, looking into this popped up a few more small editorial issues;
   - 3.2.3 mentions BNF in relation to 2822, but RFC2822 uses ABNF
   - 4.2.9.2 nominates rules by surrounding them with "quotation marks"; 
they are bare elsewhere in the spec

> 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).]]]

>> (in last call).  Can the more recent documents be referenced instead 

I think all of the references would go to draft-freed-mime-p4.

As an aside -- it appears we may reference a few documents that are in 
the RFC editor queue, or about to be there. It might be good to set 
expectations within the WG as to what that means for our publication 
schedule.

>> 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/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Apr 2005 20:43:20 -0700

Done;  
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ 
000676.html

Just curious; when/how does the ietf-types list switch over to  
@iana.org (as per draft-freed-media-type-reg)?

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 7 Apr 2005 07:46:17 -0400

One is an alias for the other.  They're currently interchangeable from a
sending perspective.

-Scott-

> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Wednesday, April 06, 2005 11:43 PM
> To: Scott Hollenbeck
> Cc: [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Apr 2005 12:19:12 -0700

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?

> 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)?
>

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Apr 2005 21:07:37 +0100

>> (Just a suggestion, I'm also happy to change the reference.)

I commented on this and felt it could be dropped as could an ABNF ref in 
in 3 (3.3?)

>> hence does not require them to be valid (in the sense used by XML).]]]

+1

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Apr 2005 22:31:17 -0700

Oops; I meant draft-freed-media-type-reg.