Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Data-UUID CPAN distribution.

Report information
The Basics
Id: 64758
Status: rejected
Priority: 0/
Queue: Data-UUID
People
Owner: Nobody in particular
Requestors:
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Jan 13 19:08:33 2011 MichaelRWolf [...] att.net - Ticket created
Subject: Hex "a" through "f" should be output as lower case
On July 2005, http://www.ietf.org/rfc/rfc4122.txt said: The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
  Thu Jan 13 19:10:59 2011 rjbs [...] cpan.org - Correspondence added
It's a shame this wasn't right from the start, but I think too much code now relies on the current behavior, and am loath to change it. Sorry. -- rjbs
  Thu Jan 13 19:10:59 2011 The RT System itself - Status changed from 'new' to 'open'
  Thu Jan 13 19:11:00 2011 rjbs [...] cpan.org - Status changed from 'open' to 'rejected'
  Fri Jan 14 01:45:42 2011 MichaelRWolf [...] att.net - Correspondence added
On Thu Jan 13 19:10:59 2011, RJBS wrote: Show quoted text
> It's a shame this wasn't right from the start, but I think too much > code now relies on the current > behavior, and am loath to change it. Sorry.
Ricardo, I completely understand about backward compatability. I really do. I can believe how much code can break. Heck, the reason I noticed it was a failed test of my own. How 'bout a middle ground that preserves backward compatibility, but encourages standards compliance? 1. Document the difference between the module behavior and the RFC, possibly in a "BUGS" or "ISSUES" section in the POD. 2. Add a module-level call like Data::UUID->conform_to_RFC_lowercase_requirement() 3. Add an import flag that encourages it. use Data::UUID (:lower_case); Thanks for the rapid turn-around on the reply... Michael
  Fri Jan 14 01:45:43 2011 The RT System itself - Status changed from 'rejected' to 'open'
  Fri Jan 14 01:45:44 2011 MichaelRWolf [...] att.net - Correspondence added
On Thu Jan 13 19:10:59 2011, RJBS wrote: Show quoted text
> It's a shame this wasn't right from the start, but I think too much > code now relies on the current > behavior, and am loath to change it. Sorry.
Ricardo, I completely understand about backward compatability. I really do. I can believe how much code can break. Heck, the reason I noticed it was a failed test of my own. How 'bout a middle ground that preserves backward compatibility, but encourages standards compliance? 1. Document the difference between the module behavior and the RFC, possibly in a "BUGS" or "ISSUES" section in the POD. 2. Add a module-level call like Data::UUID->conform_to_RFC_lowercase_requirement() 3. Add an import flag that encourages it. use Data::UUID (:lower_case); Thanks for the rapid turn-around on the reply... Michael
  Fri Nov 30 19:59:42 2012 BKATZUNG [...] cpan.org - Correspondence added
I second this request, and agree with the suggestions (especially 1 and 3).
  Sat Jul 06 22:23:25 2013 rjbs [...] cpan.org - Correspondence added
Attaching it to the class will pollute other uses. It should be attached to the generator. $ug = Data::UUID->new( lc => 1 ); Alternately, add: $ug->create_lc_str ...but at that point: lc $ug->create_str So either this goes into the generator constructor or it isn't worth doing. -- rjbs
  Sat Jul 06 22:23:46 2013 rjbs [...] cpan.org - Severity Wishlist added
  Sat Jul 06 22:54:48 2013 rjbs [...] cpan.org - Status changed from 'open' to 'stalled'
  Sat Aug 01 18:40:34 2015 rjbs [...] cpan.org - Status changed from 'stalled' to 'rejected'
  Mon Aug 03 15:01:33 2015 SREZIC [...] cpan.org - Correspondence added
On 2013-07-06 22:23:25, RJBS wrote: Show quoted text
> Attaching it to the class will pollute other uses. It should be > attached to the generator. > > $ug = Data::UUID->new( lc => 1 ); > > Alternately, add: > > $ug->create_lc_str > > ...but at that point: > > lc $ug->create_str > > So either this goes into the generator constructor or it isn't worth > doing.
While there's probably no point in creating another method or option for lowercase operation, some words about the issue could be added to the Pod (e.g. explicitly stating that uppercase hex digits are generated, a link to the rfc, maybe a note about interoperability if this is an issue...).
  Mon Aug 10 08:36:38 2015 rjbs [...] cpan.org - Correspondence added
On 2015-08-03 15:01:33, SREZIC wrote: Show quoted text
> While there's probably no point in creating another method or option > for lowercase operation, some words about the issue could be added to > the Pod (e.g. explicitly stating that uppercase hex digits are > generated, a link to the rfc, maybe a note about interoperability if > this is an issue...).
A comment about using uc instead of lc was added on August 1. This is in addition to a previous comment about uc/lc added January 16. That earlier comment mentions the RFC and that the behavior is contrary to RFC. These changes were not yet in a released version, as no code has changed. I'll make a new release today, anyway. -- rjbs