Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
Robert Sayre schrieb: ... Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? ... Although I share Robert's concerns about how this spec became a Proposed Standard, I really have trouble to see the issue here. As a matter of fact, I'm using a purl.org URL in one of my (non-Atom related) drafts as well. What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. My (and I assume also James') assumption is that once the specification is out, the purl.org HTTP URL will be reconfigured so that it redirects to a URL identifying the actual RFC (preferably to readable HTML :-). All of this is only necessary because the IETF insists in not minting HTTP URLs themselves. I think the argument is that they can become unstable. Of course that depends on the organization minting them and maintaining the servers, not the actual type of URI... (note that even the BCP for usage of XML in IETF specs -- RFC3470 -- mentions that it would be good if the IETF would allow URLs from www.ietf.org for this purpose). Best regards, Julian
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
Although I share Robert's concerns about how this spec became a Proposed Standard, I really have trouble to see the issue here. As a matter of fact, I'm using a purl.org URL in one of my (non-Atom related) drafts as well. What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. My (and I assume also James') assumption is that once the specification is out, the purl.org HTTP URL will be reconfigured so that it redirects to a URL identifying the actual RFC (preferably to readable HTML :-). All of this is only necessary because the IETF insists in not minting HTTP URLs themselves. I think the argument is that they can become unstable. Of course that depends on the organization minting them and maintaining the servers, not the actual type of URI... (note that even the BCP for usage of XML in IETF specs -- RFC3470 -- mentions that it would be good if the IETF would allow URLs from www.ietf.org for this purpose). Just a thought like that but wouldn't it make sense for RFC 4287 to have specified that every standardised extension should follow the same namespace as RFC 4287? For instance RFC 4287 uses http://www.w3.org/2005/Atom Extensions should then be something like: http://www.w3.org/2005/Atom-FTE It's just a rough idea. - Sylvain
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
Sylvain Hellegouarch schrieb: ... Just a thought like that but wouldn't it make sense for RFC 4287 to have specified that every standardised extension should follow the same namespace as RFC 4287? For instance RFC 4287 uses http://www.w3.org/2005/Atom Extensions should then be something like: http://www.w3.org/2005/Atom-FTE It's just a rough idea. ... Well, that makes standardizing extensions much harder (you need the W3C assistance in getting a namespace URI) with no gain (at least, as far as I can tell). It's a *feature* that it is so easy to define a globally unique XML namespace name. Best regards, Julian
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/19/06, Julian Reschke [EMAIL PROTECTED] wrote: What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. It's irrelevant for the XML software, but not the implementer, which is why you want it to redirect to something. That's the problem I have with it. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
http://purl.org/syndication/thread/1.0 now redirects to the draft-12 spec. When the rfc is minted, it will redirect to the rfc. - James Julian Reschke wrote: Robert Sayre schrieb: ... Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? ... Although I share Robert's concerns about how this spec became a Proposed Standard, I really have trouble to see the issue here. As a matter of fact, I'm using a purl.org URL in one of my (non-Atom related) drafts as well. What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. My (and I assume also James') assumption is that once the specification is out, the purl.org HTTP URL will be reconfigured so that it redirects to a URL identifying the actual RFC (preferably to readable HTML :-). All of this is only necessary because the IETF insists in not minting HTTP URLs themselves. I think the argument is that they can become unstable. Of course that depends on the organization minting them and maintaining the servers, not the actual type of URI... (note that even the BCP for usage of XML in IETF specs -- RFC3470 -- mentions that it would be good if the IETF would allow URLs from www.ietf.org for this purpose). Best regards, Julian
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
I can't speak for all of the IESG, how closely they reviewed the document and how carefully they considered the appropriateness of the namespace. We don't have rules against such namespace choices. We could argue about whether or not we should have such rules, but the results of that argument would most likely affect future specs. To be clear about Sam's issue, Sam asked about change control for the document, and did not suggest changing the namespace or some other change. He said I want to confirm that we hae sufficient control over this specification that we have change control for the future. We do, so a simple Yes answer was the resolution that addressed Sam's concern. It's too bad if Sam's review raised a point that you would have preferred to consider in Last Call. At this point, it's very rare to pull a document or change something like this that would affect implementations. Often the remedy at this stage is to start working on the next revision of the RFC and/or to make a note to fix in the next revision. So the IETF change control over this document may answer your concern, one way or another, as well. Lisa On Jul 9, 2006, at 9:43 PM, Robert Sayre wrote: On 7/4/06, Lisa Dusseault [EMAIL PROTECTED] wrote: I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote: We don't have rules against such namespace choices. We could argue about whether or not we should have such rules, Well, there is a BCP about this. At this point, it's very rare to pull a document or change something like this that would affect implementations. Often the remedy at this stage is... I should hope that the IETF/IESG doesn't encounter this situation often, but that doesn't seem like a strong argument. How commonly are private namespaces used in IETF standards? The right argument to have is whether the namespace is a problem. Even the draft's author acknowledges that it is a valid concern, though he probably doesn't have the same solution in mind. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
At 10:43 06/07/10, Robert Sayre wrote: Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? I looked at that namespace shortly. It seems that it would be easy to change the owners to make clear that this is owned by the IETF. This can be done whenever it's needed. A purl namespace in and by itself isn't any better or worse than a W3C namespace. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/11/06, Martin Duerst [EMAIL PROTECTED] wrote: At 10:43 06/07/10, Robert Sayre wrote: Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? I looked at that namespace shortly. Thanks, but I don't see how you would be able to answer any of the questions I asked above. It seems that it would be easy to change the owners to make clear that this is owned by the IETF. This can be done whenever it's needed. Actually, mnot delegates that path. Can he take it away? He's warned us about the very same thing wrt to Atom 0.3. A purl namespace in and by itself isn't any better or worse than a W3C namespace. I don't see any factual basis for that statement. For instance, the IETF has a liason relationship with W3C. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
All I need to know is who to transfer it to. - James Martin Duerst wrote: At 10:43 06/07/10, Robert Sayre wrote: Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? I looked at that namespace shortly. It seems that it would be easy to change the owners to make clear that this is owned by the IETF. This can be done whenever it's needed. A purl namespace in and by itself isn't any better or worse than a W3C namespace. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/4/06, Lisa Dusseault [EMAIL PROTECTED] wrote: I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Lisa On Jun 26, 2006, at 7:23 PM, Robert Sayre wrote: On 6/26/06, Robert Sayre [EMAIL PROTECTED] wrote: On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. er, a little steamed here, that's not English. It's perfectly natural to question whether things that seem out of the ordinary are appropriate. Anyway, you don't seem to have accurate answers on the process when it doesn't match the outcome you're looking for. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Protocol Action: 'Atom Threading Extensions' to Proposed Standard
The IESG has approved the following document: - 'Atom Threading Extensions ' draft-snell-atompub-feed-thread-12.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt Technical Summary This draft proposes some extensions to the Atom Syntax specification so that the relationship of one Atom entry to another (for example, when one entry is a comment on a blog post which is another entry). Working Group Summary This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft was fairly lengthy, and resulted in a number of changes to the draft. Protocol Quality As of May 2006, Feed Thread support has several independent implementations andeven some interoperability testing. This document was reviewed for the IESG by Lisa Dusseault.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 6/26/06, The IESG [EMAIL PROTECTED] wrote: Working Group Summary This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft was fairly lengthy, and resulted in a number of changes to the draft. Who wrote this summary? Even Paul went on the record saying there was no consensus on several aspects of the document. This summary makes it sound like it underwent a number of friendly suggestions, rather than disapproval by at least half of the commenters, interupted only by incorrect readings of RFC2026 and obfuscation by the document author. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
At 8:35 PM -0400 6/26/06, Robert Sayre wrote: On 6/26/06, The IESG [EMAIL PROTECTED] wrote: Working Group Summary This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft was fairly lengthy, and resulted in a number of changes to the draft. Who wrote this summary? Probably Lisa. Even Paul went on the record saying there was no consensus on several aspects of the document. Right. The statement above doesn't say anything about consensus. This summary makes it sound like it underwent a number of friendly suggestions, rather than disapproval by at least half of the commenters, interupted only by incorrect readings of RFC2026 and obfuscation by the document author. Your reading might differ from others'. --Paul Hoffman, Director --Internet Mail Consortium
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. In the future, please save the oblique answers for someone who cares to hear them. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 6/26/06, Robert Sayre [EMAIL PROTECTED] wrote: On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. er, a little steamed here, that's not English. It's perfectly natural to question whether things that seem out of the ordinary are appropriate. Anyway, you don't seem to have accurate answers on the process when it doesn't match the outcome you're looking for. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
