FreeBusy URIs require start and end date

Summary

Linking to iCalendar documents for free busy should either specify a start and minimum, viable duration for the freebusy or preferrably leave it up to implementations. (e.g. if I want to do an appointment 4 years from now, a published FB document may not extend so far out. Likewise, a FB document may be recent but just refer to last month's schedule)

The issue

A free busy document describes free or busy slots within a range. CSD assumes the published range starts 'now', that it is in the future and extends far out enough to be useful. Thus it would be possible as currently described for someone to conform to the spec and still not be able to enact the use cases.

Recommendations

Make it explicit that the FreeBusy linked to by the FreeBusy URIs is a valid FreeBusy object but may be not useful as the sart/end dates published may not match the expected range.
Have narrative recommending ranges for free/busy that would be useful for use cases (don't make them mandatory as different calendaring services may provide different options)

At present, the description for FreeBusy in the spec reads as follows:

FreeBusy FreeBusy data may be optionally available for FacilityService and Provider entities. This data, which uses the widely-implemented iCalendar standard, lists all the free or “schedulable” time slots of a specified duration (e.g. 30 minutes) for a Provider or for a FacilityService entity within a specified timeframe (e.g. some time within the next 90 days). FreeBusy query results, where they are returned as part of a CSD query, are in the iCalendar result format. This plain-text format adheres to the IETF RFC 5545 iCalendar standard. An example is shown below:

       BEGIN:VFREEBUSY
       UID:19970901T095957Z-76A912@CSDservice.com
       ORGANIZER:mailto:CSD_manager@CSDservice.com
       ATTENDEE:mailto:dr_black@doctoroffice.com
       DTSTAMP:19970901T100000Z
       FREEBUSY; FBTYPE=FREE: 19971015T050000Z/PT8H30M,
        19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
       END:VFREEBUSY

The XSD defines the FreeBusy "data model" as follows:

  <xs:element name="FreeBusyService">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="freeBusyResult"
                            minOccurs="0"
                            maxOccurs="unbounded">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="facilityID"
                                        type="xs:ID" />
                            <xs:element name="serviceID"
                                        type="xs:ID" />
                            <xs:element name="providerID"
                                        type="xs:ID"
                                        minOccurs="0" />
                            <xs:element name="DTSTART"
                                        type="xs:string" />
                            <xs:element name="DTEND"
                                        type="xs:string"
                                        minOccurs="0" />
                            <xs:element name="DURATION"
                                        type="xs:string" />
                            <xs:element name="FREEBUSY"
                                        type="xs:string" />
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
      </xs:element>

*NOTE: this XML snippet doesn't appear to be displaying correctly... is there a formatting convention I should be using??

Addressing the original comment, it should be noted that the DTSTART is mandatory but DTEND is not (since it is valid to specify a startdate plus a duration). The DURATION is also mandatory since it is required to indicate the size of the time slot in order to return FREE (as opposed to BUSY) data.

The mechanism for executing a FreeBusy query to return "free" time slots is described in the rfc 5545 document. Since it may not be clear that there is no alteration being made by the CSD profile in its use of the rfc, the action item is to clarify and make more explicit the reference to this rfc regarding how the query should be expressed.

-- edited to include xml format block (three grave accents with xml right after) ~ej

facilityregistry / ihe