time period format incompatibility

[John Schnizlein <jschnizl@xxxxxxxxx>]

Looking for guidance from the Calendar WG.
John

}From: remoore@xxxxxxxxxx
}
}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, policy@xxxxxxxxxxxxxxx
}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
}