I'd suggest you first send an email with the top 10 substantive changes to the 
list, e.g. which algorithms change from mandatory to optional or optional to 
mandatory etc, which processing rules you are relaxing, etc

this would take less time for you and be much clearer to all.


regards, Frederick

Frederick Hirsch

On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote:

> On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote:
>> Well, you started with a relatively ambiguous characterization of a need 
>> to eliminate "redundancies and inconsistencies" and now I see you think 
>> the spec as written has resulted in "willful violations of the spec" and 
>> of course those are quite different.
> Correct. But one really led to the other. The reality is that very few people 
> who implemented the spec really read the spec in detail. Most people seemed 
> to have been working from the examples. This is normal and to be expected. 
> Cleaning it up a bit should make it easier to follow. 
>> Since this spec is in the Candidate state (and as such, perhaps already 
>> deployed), I think it would be helpful if you would please flesh out all 
>> the changes and bug(s) you propose must be fixed ^1. Then we should be 
>> able to have a more informed discussion re "if it's OK to have a go at 
>> rewriting".
> I'm ok with that, but would prefer to do it like this: 
> 1. make a mirror copy of the spec. 
> 2. make all the edits I think need to be made. It's not many, as the spec is 
> relatively small (~14 pages). 
> 3. make a diff of the two documents to build the list of changes.
> 4. propose the complete list of changes to the group. 
> 5. let the group decide which changes they accept or reject or need further 
> discussion. If the new spec is take wholesale, then great. Otherwise, it's 
> easy to backtrack on proposed changes. 
> This is how I've done this kinds of changes in the past and it's always 
> worked out ok. 

Reply via email to