Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

On Dec 18, 2011, at 8:49 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:

> On 12/18/11 2:31 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>> On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote:
>>> Undated references (what you are suggesting) has the MAJOR PROBLEM that
>>> it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that
>>> claims conformance to a standard ­ since it's impossible to determine
>>> which version of each undated reference they used.
>> 
>> That's a FEATURE, not a "problem". Makes it inexcusable not to keep up
>> with specs (same design built into HTML5, SVG, etc.).
> 
> "Keeping up with the specs" is a business decision NOT something that is
> tied to compliance with a standard.  

If it is in the spec, then it's a spec decision. 

> In fact, in some cases, it may be
> mandated (by law or commerce) that one does NOT keep up and instead relies
> on a specific version.  Use of undated resources prevents that.

Seem like that kind of practice is misguided. Law makers and govs are not know for understanding software development. Removing dates would stop such harmful practices.

> In what way do you believe that it is "built into" HTML5 or SVG?   Both of
> those W3C documents use dated references.

I only see one date at: 
http://dev.w3.org/html5/spec/Overview.html#references

... Because e doc is not online.

All references point to latest version. Where possible, edition info and version info has been removed (e.g., XML, Unicode, XML NS). 

SVG [1] used to serve 1.0, but now points to 1.1 ... And when 1.2 is done, [1] will be used.

http://www.w3.org/TR/SVG/

> 
>>> Additionally, it makes interoperability difficult/impossible since you
>>> can have multiple valid conforming implementations BUT they don't
>>> actually interoperate due to changes between revisions (and algo changes
>>> would be a good example of such an interoperability issue).
>> I don't see how that is possible: if your spec does not conform to
>> /latest/, then you are non-conforming.
> 
> That's one way to read it, mine is the other way.
> 
> 
>> If you were conforming yesterday, but a new version of the a spec comes
>> out tomorrow, then you update your software to conform to the latest
>> version. As an example, almost all Browsers are on a 6 week release cycle
>> now: 
> 
> Browsers are just one of MANY types of software in the world that may
> choose to adopt this standard.  Some of those other types may not be on
> such short cycles.  Some of those other types may not be ABLE to rev often
> (think hardware/firmware, medical devices, etc.).  Some of those other
> types may be operating in mandated environments (think government).

If its using widgets, then it's 99% chance it is using a browser. Not updating browsers every few months is known to be harmful... Like not updating Flash would be extremely dangerous, hence getting thankfully bugged about every few weeks on my windows machine. Now, I'm not asking that XML Sec WG stop with dated/versioned specs. I'm asking that a /latest/ version be provided for spec (such as mine) where dates and versions are irrelevant and seem as harmful. 

>> Pretending that slapping a date on spec means anything is unhelpful (and
>> actually harmful, because all specs contain bugs and hence must be
>> continuously maintained).
> 
> A "spec", probably true.
> 
> An international standard from a reputable SDO - EXACTLY THE OPPOSITE!  

Funny then that XML, for instance, is on its 5th Ed. And that C10N is now on 2.0, and that all Recs have to include a link to an errata page. So, pretending work stops or specs are stable when the reach Rec is simply not true. 

> It
> is a REQUIREMENT that standards issues by SDO's be dated and frozen at a
> given point in time in order for them to be implemented, validated and
> approved for use in mandated environments.

That's maybe true for nuts, bolts, and bottle caps... But at the w3c I see nothing but a continual effort to improve and refine specs long after Rec - a good thing. The only specs that get frozen are dead specs, because there is no interest in maintaining them. 

Also, the fact that there needs to be two interoperable implementations before you go to Rec undermines you argument: HTML 5 again is a good case in point. It's being implemented by many people long before it is done. 

> 
> But then the "living standard" argument continues to wage in many places
> and I don't see a need to continue it here.
> 
> Leonard
>

Received on Monday, 19 December 2011 03:10:20 UTC