Re: AD Review Comments and Questions: draft-ietf-atompub-format-07
Oops; I meant draft-freed-media-type-reg. On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote: 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? Rob/Mark? 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. -- Mark Nottingham http://www.mnot.net/
RE: AD Review Comments and Questions: draft-ietf-atompub-format-07
One is an alias for the other. They're currently interchangeable from a sending perspective. -Scott- -Original Message- From: Mark Nottingham [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 11:43 PM To: Scott Hollenbeck Cc: atom-syntax@imc.org Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 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)? On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: The MIME media type registration template included in section 7 MUST be submitted to the ietf-types list ([EMAIL PROTECTED]) 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. -- Mark Nottingham http://www.mnot.net/
Re: AD Review Comments and Questions: draft-ietf-atompub-format-07
On Apr 5, 2005, at 9:26 AM, Tim Bray 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.) 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 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 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? Rob/Mark? 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. 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/
Re: AD Review Comments and Questions: draft-ietf-atompub-format-07
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)? On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: The MIME media type registration template included in section 7 MUST be submitted to the ietf-types list ([EMAIL PROTECTED]) 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. -- Mark Nottingham http://www.mnot.net/
RE: AD Review Comments and Questions: draft-ietf-atompub-format-07
-Original Message- From: Tim Bray [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 12:26 PM To: Scott Hollenbeck Cc: atom-syntax@imc.org Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: [snip] 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? 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? 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] The MIME media type registration template included in section 7 MUST be submitted to the ietf-types list ([EMAIL PROTECTED]) 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. Scott, what's the scheduling on that? Do we launch that right now, independent of the rest of the document review process? 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-
Re: AD Review Comments and Questions: draft-ietf-atompub-format-07
At 9:26 AM -0700 4/5/05, Tim Bray wrote: 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. 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. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: 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*, 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. 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
RE: AD Review Comments and Questions: draft-ietf-atompub-format-07
-Original Message- From: Paul Hoffman [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 2:07 PM To: Tim Bray; Scott Hollenbeck Cc: atom-syntax@imc.org Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 At 9:26 AM -0700 4/5/05, Tim Bray wrote: 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. 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. 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. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: 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*, 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. 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)? 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.
RE: AD Review Comments and Questions: draft-ietf-atompub-format-07
At 2:25 PM -0400 4/5/05, Scott Hollenbeck wrote: As described in 2434, IESG Approval, though the IESG has discretion to request documents or other supporting materials on a case-by-case basis. Right. 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. 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. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: 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*, 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. 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)? 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. 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? 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 fine with that. And, yes, I was modelling this process after than one. 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. 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 --Internet Mail Consortium
