Re: xml schema dateTime vs timestamp -> was -> RE: PIDF - using xml schema

Keep in mind that if you allow mixed case then you might have a
security problem.  First, you may lose the original case of the
message (thereby invalidating signatures).  Second, the question of
whether the case is upper or lower could be used as a covert channel
(albeit a two-bit channel) to leak information.

-derek

Chris Newman <[email protected]> writes:

> Upper/lower case with protocol keywords (I'd say this case is
> basically the protocol keyword case) is a strange area for standards.
> By a fundamental design principle (avoid alternate represenatations),
> the right thing would be to pick one case and require that for all
> uses.  However, because humans test text protocols by typing, I'm of
> the opinion that if a case restriction is placed on a protocol it
> should be mandatory lower case so humans don't have to muck with
> shift/shift-lock.  However, the tradition of writing protocol keywords
> in upper case would suggest the opposite.  This conflict means no
> choice will make everyone happy.  The tradition of most languages that
> use the ASCII latin alphabet is to treat upper and lower case as
> equivalent in most cases, and the IETF follows this tradition as
> reflected in the ABNF spec's default case handling for protocol
> keywords.
> 
> However, when it comes right down to it, this is a pretty trivial
> issue and regardless of what we do in the spec, programmers will make
> it work.  I'd have no objections to aligning our date-time spec with
> the XML schema format by making upper-case mandatory.  It's probably
> the right thing to do for consistancy in this case.
> 
> I don't see much point to adding "RECOMMENDED" text or the equivalent
> because it doesn't have any impact on the parsing code.  I'd rather
> not have text saying "future standards may further restrict the syntax
> in this spec ..." because that's implicit in the standards process and
> this spec is already too verbose.
> 
> But none of the proposals I've heard are unacceptable.
> 
>                - Chris
> 
> begin  quotation by Graham Klyne on 2002/4/20 17:08 +0100:
> 
> > Not a bug, but a feature !-)
> >
> > More seriously, we were following ISO8601 which seemed the right thing to
> > do at the time.  Subsequent developments may suggest a more rigid
> > approach to be more appropriate.
> >
> > Unfortunately, this spec is now in the RFC editor queue, with other
> > queued documents dependent upon it, so it's late for a normative change.
> > I'd suggest, for now, that any specs that if we cite this (as opposed to
> > XML schema), and further specify that only uppercase 'Z' and 'T' be used.
> >
> ># g
> > --
> >
> > At 03:49 PM 4/19/02 -0400, Derek Atkins wrote:
> >> Datetime allows for mixed-case identifiers?  That sounds like a
> >> bug in Datetime..  It should be fixed-case.  Graham?
> >>
> >> -derek
> >>
> >> Jonathan Rosenberg <[email protected]> writes:
> >>
> >> > "Carr, Wayne" wrote:
> >> > >
> >> > > After a quick look at both now, it looks like there may be an
> >> > > difference that makes it so IMPP datetime isn't a subset of schema
> >> > > dateTime.  It looks
> >> > > like dateTime lets you use either 't' or 'T' and either 'z' or 'Z'
> >> > > and xml
> >> > > schema looks like it only lets you use 'Z' and 'T'.
> >> > >
> >> > > If IMPP dateTime isn't a subset of schema dateTime, we'd have to use
> >> > > string
> >> > > or create the correct type in the schema.  A quick fix is to make it
> >> > > string
> >> > > and which is all a DTD would do.
> >> >
> >> > I don't see the value in having a separate datetime which is *almost*
> >> > the same as schemas, but not quite, especially if the difference is
> >> > just syntactic. I would prefer to fix the impp date time spec to agree
> >> > with the schema format.
> >> >
> >> > -Jonathan R.
> >> >
> >> > --
> >> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> >> > Chief Scientist                         First Floor
> >> > dynamicsoft                             East Hanover, NJ 07936
> >> > [email protected]                 FAX: (973) 952-5050
> >> > http://www.jdrosen.net                  PH:  (973) 952-5000
> >> > http://www.dynamicsoft.com
> >> >
> >> >
> >> >   [reminder: [email protected] for non-technical discussions,
> >> >   please]
> >> >
> >>
> >> --
> >>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >>        Member, MIT Student Information Processing Board  (SIPB)
> >>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >>        [email protected]                        PGP key available
> >
> > -------------------
> > Graham Klyne
> > <[email protected]>
> >
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email protected]                        PGP key available


  [reminder: [email protected] for non-technical discussions, please]