Subject: time period format incompatibility

From: John Schnizlein <[email-masked]>
Date: Mon, 13 Mar 2000 13:01:07 -0500

Looking for guidance from the Calendar WG.
John

}From: [email-masked]
}
}Let me explain what happened.
}
}Since there has been no suggestion that the current encodings
}for these fields don't work, the authors of the draft decided
}that their lack of alignment with the RFC 2445 encodings is a
}second-order problem.  If the WG as a whole thinks this
}alignment is important, we can certainly change the draft.
}But so far I haven't heard even one other person second your
}motion to make this change.
} ...
}To:   Robert Moore/Raleigh/IBM@IBMUS, [email-masked]
}Subject:  Re: Summary of changes in -04 draft of the PCIM
}
}Am I the only person who sees a problem in that the Policy Framework
}draft is proposing a format for time-dates and periods of them that is
}incompatible with Standard-track RFC 2445?
}
}I expected that my answers to Bob's questions last month regarding
}changing the draft would lead to compatibility. What is the compelling
}reason to introduce time format translations for any attempt to
}interoperate between Internet-standard scheduling and Policy?
}
}John
}
}draft-ietf-policy-core-info-model-04.txt
} 6.5.1. The Property "TimePeriod"
}
}   This property identifies an overall range of calendar dates and times
}   over which a policy rule is valid.  It is formatted as a string
}   consisting of a start date and time, then a colon (':'), and followed
}   by an end date and time.  The first date indicates the beginning of
}   the range, while the second date indicates the end.  Thus, the second
}   date and time must be later than the first.  Dates are expressed as
}   substrings of the form "yyyymmddhhmmss".  For example:
}
}     19990101080000:19990131120000
}
}
}RFC 2445:
}   The iCalendar format is suitable as an exchange format between
}   applications or systems. The format is defined in terms of a MIME
}   content type. This will enable the object to be exchanged using
}   several transports, including but not limited to SMTP, HTTP, ...
}
}4.3.4 Date
}   Example: The following represents July 14, 1997:
}     19970714
}4.3.5 Date-Time
}   For example, the following represents January 19, 1998, at 0700 UTC:
}     DTSTART:19980119T070000Z
}4.3.9 Period of Time
}   Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
}   ending at 07:00:00 UTC on January 2, 1997 would be:
}     19970101T180000Z/19970102T070000Z
}

---

From: [email-masked]
Date: Mon, 13 Mar 2000 15:58:09 -0500

John:
This just isn't a draft-ietf-policy-core-info-model-04.txt versus RFC 2445. The iCalendar format is based on an accepted 
International Standard, ISO 8601. 
There doesn't seem to be a good reason to intentionally do something 
different for a period format. 
Push back again!
-- Frank