RE: Atom syndication schema
-Original Message- From: Norman Walsh [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 1:08 PM To: Atom Syntax Subject: Atom syndication schema I recall a thread not too long ago about changes to the Atom schema and Uche has pointed out some deficiencies http://copia.ogbuji.net/blog/2006-02-06/Small_fix_ I'd be happy to tweak the schema and try to address these bugs, but does the group have any desire to see a WG endorsed set of fixes published? And if it does, where should they be published? Errors in RFCs can be captured as errata by sending a note to the RFC Editor: http://www.rfc-editor.org/errata.html The idea is that they should eventually get taken care of by an update to the RFC. -Scott-
RE: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
-Original Message- From: Andreas Sewe [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 25, 2006 11:37 AM To: Atom Publishing Protocol Cc: Atom Syntax Subject: Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations] Regarding the following four link relations there seem to be some inconsistencies with (or maybe only within) the APP 0.7 draft (but hopefully the editors of 0.8 have caught those already ;-): Attribute Value: previous Attribute Value: next Attribute Value: first Attribute Value: last In section 9.1 of draft-ietf-atompub-protocol-07 it is first stated that an '[..] Atom feed document MAY contain link elements with rel attribute values of next, previous, start and end [...]'. There is a mismatch between the last two values and the ones proposed for registration: first and last. Two paragraphs further down section 9.1 starts using prev throughout -- instead of previous, as proposed to the IANA. These inconsistencies should be resolved, IMHO, ideally by using prev, next, start, and end, since at least the first three values mimic their functionally similar HTML counterparts. And APP should follow the rule of least astonishment here. There's one minor problem with the suggestion above: the IESG just approved the registration requests for previous, first, and last that were supposedly discussed and agreed-to within the working group. That decision can be revisited, but if you all decide to make a change the IESG will have to remove or otherwise obsolete the just-approved values. You'll then need to go through the approval process again. -Scott-
RE: spec bug: can we fix for draft-11?
-Original Message- From: Tim Bray [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 1:58 AM To: Sam Ruby Cc: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: Tim Bray wrote: I'm getting increasingly grumpy and just fail is looking better and better. The current normative text, The element's content MUST be an IRI, is clear and simple and supported by other well-understood normative text, supported by lots of interoperable software, that make the meanings of element, content, and IRI not really open to intelligent dispute. I claim that text enjoyed strong, not rough, consensus support from the WG. I believe that the term content is open to intelligent dispute. Apparently the authors of RFC3470/BCP70 believe so too. Could you reference that? It seems to me that the guidance we should take from 3470 is from section 4.16, which seems to me to make it clear that *we* should make it clear that id http://example.com/foo /id is an error and nothing but an error. -Tim That's my interpretation of what we (the authors of 3470) wrote, too. Knowing that white space is significant, you guys need to explain what to do with it. -Scott-
FW: RFC 2119 problem in Atom syndication format
FYI. This can be addressed post-IESG evaluation. -Scott- -Original Message- From: Mark Baker [mailto:[EMAIL PROTECTED] Sent: Thursday, June 16, 2005 11:07 AM To: iesg@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RFC 2119 problem in Atom syndication format Section 4.1.3.2 of draft-ietf-atompub-format-09, the src attribute, includes a common RFC 2119 mistake, MAY NOT. I expect that SHOULD NOT was intended. This was new to -09 AFAICT. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
RE: draft-ietf-atompub-format-09.txt is ready for IESG review
I will schedule the document for IESG review during the 23 June telechat. Thanks for the notes. -Scott- -Original Message- From: Paul Hoffman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 10:35 AM To: Hollenbeck, Scott Cc: Tim Bray; Atom WG Subject: draft-ietf-atompub-format-09.txt is ready for IESG review Greetings again. As the shepherd for this document, I would like to ask you to bring it to the IESG for final review. The WG has worked hard on this document after IETF Last Call, and made many changes that incorporate the WG rough consensus on issues that were brought up during and after IETF Last Call. Some members of the Working Group remain unenthusiastic about some sections of the document, but we strongly believe that there is rough (or better) consensus in support of the document as a whole. For some of the parts with the most contention, there cannot be more than very rough consensus due to basic differences in the way people would design parts of the format, particularly given that we have many models in existence with the different flavors of RSS. For some parts of the document, there is contention about whether or not a particular item should or should not be in the Atom core versus being an extension. For some parts, there is contention whether there should be MUST/SHOULD/MAY leeway for content creators in the presence or absence of an element, or the semantic content of an element; we really pushed RFC 2119 around during the past few months. The length of the mailing list archive is anomalous in the IETF, but so is the large number of regular active contributors and the breadth of parts of the document to which they contributed. This huge amount of input has caused the document to be more seriously reviewed, by more eyes, than a typical IETF document, but it has also caused more opportunity for disagreement along the way. Yet we still ended up with a format that meets the goals of the charter and the general agreement of most of the participants in the Working Group. Please let us know how if the IESG has any concerns with the document during their review. --Paul Hoffman, Director --Internet Mail Consortium
RE: Last Call: 'The Atom Syndication Format' to Proposed Standard
A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. Paul described text that's in the document to describe what MAY be done. I would argue that the existing text is evidence of the thought that has gone into understanding the issue and the alleged problem. -Scott-
RE: Autodiscovery
-Original Message- From: Bill de hÓra [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 1:18 PM To: atom-syntax Syntax' Subject: Re: Autodiscovery Tim Bray wrote: Assuming no errors, or rather that any errors we turn up are fixed, are there any objections to us submitting this I-D as a product of the Atompub WG? -Tim How do we manage a WG product produced and edited by a non-WG member? I've privately asked Tim and Paul the same question. Though section 6.3 of RFC 2418 doesn't specifically say that a document editor MUST be a member of the working group, the situation appears so obvious that it shouldn't need to be stated. -Scott-
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/
FW: XML Directorate Reviewer Comments
Here are some more -07 review comments from one member of the XML Directorate. We already know about #1. It's OK to ask questions about the reviewer's questions, just please cc him directly if you wish to start a dialog. -Scott- -Original Message- From: Andrew Newton [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 6:25 PM To: Scott Hollenbeck Cc: [EMAIL PROTECTED] Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for IETF last call A very good document overall. I found just a few items, all minor. 1) Section 1.2. The atom prefix uses a namespace URI not under change control of the IETF. See BCP 81. Also, purl.org is not listed in 2606. 2) Section 4.1.3.3 Item 2 The text: for example, br as lt;br. Is this right? Should it be: for example, br as lt;brgt;. Also, should the must in The HTML markup must be escaped be a MUST? Should rule 2 have the same note regarding the DIV element as rule 3? What happens if the type is html and the content is all within lt;divgt; lt;/divgt; ? 3) Section 4.2.4 Is the atom:copyright also meant to convey an applicable distribution license? -andy
AD Review Comments and Questions: draft-ietf-atompub-format-07
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 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. 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/
RE: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07)
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 PROTECTED] Sent: Tuesday, April 05, 2005 12:05 PM To: Scott Hollenbeck Cc: atom-syntax@imc.org Subject: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07) Scott Hollenbeck wrote: 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.) 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
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
-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: PaceChangeProtocolCharter
I understand that. It would also be acceptable for us to decide to make it compatible, without changing the charter, correct? As long as that goal doesn't conflict with other chartered work items, yes. Much like we could've guaranteed questions from our A.D. about date formats [0], I would also expect our A.D. to ask some questions if we reinvent several features already found in WebDAV. Why? WebDAV reuse isn't currently a required part of what this group is supposed to be doing. Sure, I might ask questions if it looks like there's overlap and reuse of existing work might save something, but if it's not a requirement (and it currently isn't) it won't necessarily be a significant issue if reasonable alternatives are described instead. -Scott-
RE: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339)
Having written the datetime support for Apache Axis (a webservice implementation based on XSD schema and having hosted a number of SOAP interop facilities, I am +1 on the regular expression limitation, believe that all dates that that conform to this limitation are valid RFC 3339 and xsd:dateTime values, and believe that it will interop with all of the existing XSD implementations. I'm not sure that I understand why some folks seem to think that this has to be an either-or situation. As Sam noted, it's quite possible to specify date-time syntax that conform to both RFC 3339 and XML Schema Part 2. Here's what I did in RFC 3731: 2.4. Dates and Times Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case T and Z characters defined in [RFC3339] MUST be used to represent date-time values as XML Schema does not support truncated date-time forms or lower case T and Z characters. I then used the xsd:dateTime data type in my schema (with an appropriate reference to Part 2), and all is well. The normative text eliminates some of the 3339 possibilities that don't work or play well with XML Schema. -Scott-
RE: PaceFormatSecurity
Given the two choices, I actually prefer security-by-reference because it points out the similarity of what we are doing to other protocols. I agree. It's also a good practice to have only one authoritative source that talks about a topic, especially when that source has already been through the RFC approval process. -Scott-
RE: Comment on process
No-one gains anything from overly protracted discussion. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Is there something related to the (still unexplained) deadline mentioned in Tim's recent post? I'm not sure that I understand why you believe the deadline is unexplained. Take a look at the charter for this working group: http://www.ietf.org/html.charters/atompub-charter.html There are goals and milestones identified with due dates. The working group chairs have an obligation to keep the working group on track to meet those milestones. They can set interim goals for smaller tasks if they feel it's necessary. Given that the goals and milestones were agreed upon as part of the creation of this working group, what's not clear? -Scott- (atompub area advisor)
