IESG defers discussion of the format document for two weeks
Greetings again. So, it turns out that the IESG won't consider the Atom format document today, as we had hoped. As you can see at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11964rfc_flag=0, one of the Security Area Directors, Russ Housley, put a defer vote in. Procedurally, this means that he wants to wait for another telechat in order to think more about the document. Defer votes aren't common but aren't rare, and they can mean anything. And, a document can only be deferred once (that is, the IESG cannot use defer votes to keep ignoring a draft). As you can also see from the ID tracker, we have a bunch of no objection votes and a couple of discuss votes. We need to clear all the discuss votes before we are accepted as a standard, but so far, these are all reasonable things that RobJoe can do in the -10 draft. Other IESG members may have other discuss votes later on, and those can be more difficult, but we'll see when it happens. In other words, this isn't bad news, just a delay. Tim and I have already opened a line of communications with Russ and Sam about security issues, so if they want to ask questions or probe further before voting, they can. Stay tuned, and it won't be that long until we know for sure. --Paul Hoffman, Director --Internet Mail Consortium
Re: IESG defers discussion of the format document for two weeks
On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote: In other words, this isn't bad news, just a delay. Fully disagree. The world has many implementors eagerly awaiting the arrival of Atom so they can start using it. If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim
Re: IESG defers discussion of the format document for two weeks
In my previous post, I said RobJoe when I should have said Rob and Mark. Also, I said Russ and Sam when I should have said the two Security Area Directors, Russ Housley and Sam Hartman (that is, not our WG secretary, Sam Ruby). Also, I agree with Tim that waiting two weeks unnecessarily is a bummer for anxious implementers. I guess I'm just used to much worse things happening in the IESG in the past, like really long delays. --Paul Hoffman, Director --Internet Mail Consortium
Re: IESG defers discussion of the format document for two weeks
On 24/6/05 1:28 AM, Tim Bray [EMAIL PROTECTED] wrote: In other words, this isn't bad news, just a delay. Fully disagree. The world has many implementors eagerly awaiting the arrival of Atom so they can start using it. If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim we can start with these two... https://datatracker.ietf.org/public/pidtracker.cgi?command=view_commentid= 36536 https://datatracker.ietf.org/public/pidtracker.cgi?command=view_commentid= 36539 e.
Re: CVS branch merge conflicts
A couple of people pointed me to Eclipse for this, and it does indeed work well for this (thoug the quality of the diffs is not so good as IntelliJs). If it were not so complicated to transform a checked out CVS project into an eclipse project it would be perfect. Henry On 23 Jun 2005, at 12:36, Henry Story wrote: Hi, I am looking for a tool to make it pleasant to resolve merge conflicts between a branch and the HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone know a good tool that one could use for this? Henry Story
Re: CVS branch merge conflicts
Sorry, wrong list. :-/ Henry On 23 Jun 2005, at 18:22, Henry Story wrote: A couple of people pointed me to Eclipse for this, and it does indeed work well for this (thoug the quality of the diffs is not so good as IntelliJs). If it were not so complicated to transform a checked out CVS project into an eclipse project it would be perfect. Henry On 23 Jun 2005, at 12:36, Henry Story wrote: Hi, I am looking for a tool to make it pleasant to resolve merge conflicts between a branch and the HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone know a good tool that one could use for this? Henry Story
Re: More on Atom XML signatures and encryption
On Tue, 2005-06-21 at 17:13 -0700, James M Snell wrote: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. Given this language, the the spec only explicitly allows digital signing of the Atom Feed and Entry Documents. It does not explicitly allow for digitally signing individual entries within a Feed document. Makes sense to me James. Which bit of 'only explicitly' don't you grok? -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: IESG defers discussion of the format document for two weeks
On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote: If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim we can start with these two... https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36536 https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36539 Nope, these are non-controversial editorial improvements which need not slow us down, they can go into that last draft that we'd have to do anyhow to fix the errors that have been turned up and put in the contributors and so on. Specifically, they want us to make it clearer that yes, we do have two similar-looking instances of type= with different rules, and to make it clear that to dereference a IRI you have to turn it into a URI. The person who put the defer on didn't raise these issues. -Tim
