Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sat, 10 Nov 2001 10:05:52 -0500

> -----Original Message-----
> From: Doug Royer [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 6:36 PM
> 
> The iCalendar date-time format is restricted to exactly one
> representation of date-time (not optional spaces, dashes, ...).
> There was a large debate on this before rfc2445 came out.
> We decided on ONE format for date time based on ISO-8601
> 
> 	YYYYMMDDTHHMMSS [+/- ...]
> 
> If the intent is to be human readable - both loose.
> If the intent is to be machine readable - why another similar format?

One possible issue involves incompatibility with standard formats defined by
other organizations, such as the W3C.  XML Schema (for example) defines a
date-time format [1] per ISO-8601's extended form; the shorter format
described in RFC2445 and ISO-8601 is invalid per XML Schema.  If the IETF
were to "require" RFC2445-compliant date-time values in protocols we'd be
imposing a format that restricts use of XML Schema (and who knows what else)
in protocol design.  The formats specified in this new document provide some
flexibility that may be useful in varied date-time specification contexts.

-Scott-

[1] http://www.w3.org/TR/xmlschema-2/#dateTime

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sat, 10 Nov 2001 14:14:24 -0500

> From: Dawson Frank (NMP/Irving) [mailto:[email-masked]]
> Sent: Saturday, November 10, 2001 12:39 PM
> To: 'ext Hollenbeck, Scott'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call: Date and Time on the Internet: Timestamps to
> Proposed Standard
> 
> 
> 
> So, the RFC2445 isn't "invalid per XML schema". Rather the opposite is
> true.

Perhaps, but the point I was trying to make isn't about the W3C ignoring
IETF work or vice-versa.  A "one size fits all" specification isn't likely
to meet everyone's needs, and the situation with 2445 and XML Schema is just
one example of a situation where the given size didn't fit someone for some
reason.  The point I was trying to make is that the timestamps document
seems to provide a reasonable compromise between being too restrictive and
too permissive.

-Scott-

---

From: "Dawson Frank (NMP/Irving)" <[email-masked]>
Date: Sat, 10 Nov 2001 11:39:12 -0600

> flexibility that may be useful in varied date-time

The W3C Schema work just ignored the previously published IETF iCalendar
work effort. The issue is not that iCalendar is different than this
yet-to-be-proven XML Schema data type for date time, but rather that the
W3C work ignored the recommendations of the "time lords" in the IETF. In
addition, the XML Schema date/time data type includes a UTC offset. This
mixes time zone specification with date/time data types. Such coupling
was found to be inappropriate for a data type that is used for
calendaring and scheduling applications or other date/time dependent
applications.

---

From: "Dawson Frank (NMP/Irving)" <[email-masked]>
Date: Sat, 10 Nov 2001 13:29:37 -0600

"One size fits all"? This isn't about haberdashery.

The point of a standard format is exactly that there needs to be a
single precise format. If you are going to use an Internet date/time
standard, then it ought to be same or at least an isomer (ie, iCalendar
date/time format).

Especially, when it comes to basic data types like date/time.

-- Frank

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 14 Nov 2001 18:41:34 -0500

> From: Doug Royer [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 4:14 PM
> To: Hollenbeck, Scott
> Cc: 'Dawson Frank (NMP/Irving)'; [email-masked]; [email-masked]
> Subject: Re: Last Call: Date and Time on the Internet: Timestamps to
> Proposed Standard
> 
> 
> 
> 
> "Hollenbeck, Scott" wrote:
> . ...
> > 
> > Yes, we should have a standard, but that standard should be 
> usable across
> > the IETF.  In the provreg WG, we're using XML Schema to 
> specify a protocol
> > because XML and XML Schema provide needed extensibility 
> features.  I can't
> > use 2445-compliant date-time format because XML Schema 
> won't accept it.
> 
> Now I am confused, one of the formats in that draft is without
> dashes and spaces - then it is EXACTLY like RFC2445.
> So how can XML Schema handle them then? It looks like the draft
> is saying "this is the proposed standard including a version
> that XML can not use".

True, the draft specifies a format that is exactly like the 2445 format.
That's good, it doesn't preclude the earlier work.  It also specifies
another format (the "extended" format) that _does_ work with XML Schema.  I
believe that's good as well.

> So I would agree that there are different needs. That point
> does not seem to persuade me that a 3rd format should also be 
> documented.
> 
> > We can debate the merits (or detriments) of using non-IETF specified
> > technologies for IETF work, but that's not the issue at hand.  The
> > Timestamps draft describes formats that can be used where 
> 2445-format can't,
> > and at least in the case of the provreg WG that flexibility 
> is needed.
> 
> I also don't care if it is IETF or W3C work. I just don't see the
> need to create a proposed standard this is mostly like ISO, kind
> of like 2445, and you think would work with a (not yet?) recommended
> W3C proposal. My point is - what's the point?

XML Schema is a W3C Recommendation as of 2 May 2001 (reference provided in
three parts below).  It's being used in other IETF work.  In that other work
I currently have to cite an ISO document as the normative date-time format
reference.  I can cite the Timestamps draft if it becomes an RFC.  I can't
cite 2445.  Maybe citing an ISO document isn't a big deal, but I'd rather
cite a freely available RFC if I could.

-Scott-

[1] http://www.w3.org/TR/xmlschema-0/

[2] http://www.w3.org/TR/xmlschema-1/

[3] http://www.w3.org/TR/xmlschema-2/