3.2 O estabelecimento de protocolos de comunica¸c˜ ao
3.2.1 iCalendar
A especifica¸c˜ao iCalendar [22] define quatro componentes principais: events, to-dos, free-
busy time e journal entries. Para ser v´alido, um objeto iCalendar deve conter pelo menos um destes componentes. A extens˜ao padr˜ao para arquivos com dados iCalendar ´e .ics.
Todos os componentes de calend´ario s˜ao descritos com o uso de propriedades obri- gat´orias ou opcionais, que por sua vez podem ter parˆametros. Por exemplo, os componen-
tes do tipo event tˆem uma propriedade SUMMARY obrigat´oria que representa textualmente seu prop´osito.
O formato iCalendar n˜ao ´e baseado em XML ou qualquer outro padr˜ao de representa¸c˜ao de dados. Por isso, a especifica¸c˜ao define uma sintaxe pr´opria para representa¸c˜ao dos componentes de calend´ario, e diversas exigˆencias t´ecnicas n˜ao-triviais, como uma limita¸c˜ao de 75 octetos5 por linha.
Todo componente iCalendar ´e limitado por tags BEGIN:<nome> e END:<nome>. Suas propriedades s˜ao expressas na forma <nome>:<valor>. Parˆametros das propriedades s˜ao separados por ponto-e-v´ırgula (;) e s˜ao descritos na forma <nome>=<valor> antes dos dois pontos (:) que separam o nome e o valor da propriedade.
O exemplo da figura 3.3 mostra um objeto iCalendar que cont´em um evento “Defesa de mestrado” (propriedade SUMMARY), com in´ıcio `as 14h do dia 08/02/2008 (propriedade 2O Versit Consortium tamb´em foi respons´avel pela introdu¸c˜ao do formato vCard para cart˜oes de visita
eletrˆonicos, comumente anexados a emails e usados por aplica¸c˜oes de administra¸c˜ao de contatos.
3A RFC 3283 [49] explicita o relacionamento entre estas especifica¸c˜oes. 4Tamb´em conhecida como iCal.
5Um octeto equivale a 8 bits. Embora em padr˜oes de codifica¸c˜ao de caracteres como o US-ASCII cada
octeto corresponda a um caractere; em alguns padr˜oes, como o Unicode, s˜ao necess´arios mais de 8 bits para representar um caractere.
3.2. O estabelecimento de protocolos de comunica¸c˜ao 21 BEGIN:VCALENDAR PRODID:-//Unicamp//iScheduler//EN VERSION:2.0 BEGIN:VEVENT UID:[email protected] DTSTAMP:20080108T090000Z DTSTART:20080208T140000Z DURATION:PT1H30M SUMMARY:Defesa de mestrado END:VEVENT END:VCALENDAR
Figura 3.3: Exemplo de objeto iCalendar
DTSTART), e dura¸c˜ao de 1h30min (propriedade DURATION). Note ainda a presen¸ca das propriedades obrigat´orias de vers˜ao e identifica¸c˜ao do produto (respectivamente, VERSION, cujo valor fixo estabelecido pela RFC 2445 ´e 2.06, e PRODID, para o qual foi utilizado
um valor fantasia) no objeto. A propriedade UID permite uma identifica¸c˜ao ´unica do componente VEVENT, de fundamental importˆancia na sua utiliza¸c˜ao com o protocolo iTIP, como detalhado mais adiante.
Um mecanismo conhecido como X-tokens permite que componentes, propriedades e parˆametros n˜ao especificados no padr˜ao sejam utilizados no escopo de uma aplica¸c˜ao, exigindo que eles sejam da forma X-<identifica¸c~ao_do_produto>-<nome> para evi- tar incompatibilidades. Por exemplo, uma aplica¸c˜ao poderia definir uma propriedade X-ISCHED-TESTE para representar dados n˜ao previstos na especifica¸c˜ao iCalendar. Este mecanismo oferece flexibilidade adicional, ao especificar “um padr˜ao para se fazer coisas fora do padr˜ao” [20] que n˜ao ´e oneroso, pois desobriga outras aplica¸c˜oes de armazenar ou manter o conte´udo de X-tokens em mensagens de agendamento subseq¨uentes.
O componente VEVENT
Eventos (events) s˜ao representados pelo componente VEVENT. Eles constituem a principal entidade de calend´arios, sendo utilizados para todos os tipos de compromissos agend´aveis que ocupam tempo em uma agenda, como atividades, reuni˜oes e anivers´arios.
As propriedades mais importantes de um evento s˜ao sua data de in´ıcio (DTSTART) e t´ermino (DTEND) – ou dura¸c˜ao (DURATION) –, seu organizador (ORGANIZER), seus parti- cipantes (ATTENDEEs) e seu local (LOCATION), mas diversas outras informa¸c˜oes tamb´em podem ser especificadas.
O padr˜ao iCalendar ainda disp˜oe de um poderoso mecanismo que permite a descri¸c˜ao de eventos recorrentes, que se repitam com uma determinada freq¨uˆencia, atrav´es de regras de recorrˆencia expressas pela propriedade RRULE.
Os componentes VEVENT podem, ainda, conter um ou mais componentes VALARM, cujo prop´osito ´e descrever uma rotina de alarme para relembrar o usu´ario do evento.
BEGIN:VEVENT UID:[email protected] DTSTAMP:20071005T133225Z DTSTART:20071219T170000Z DTEND:20071219T180000Z SUMMARY:Consulta ORGANIZER;CN=Doutor:[email protected] ATTENDEE;CN=Doutor:[email protected] ATTENDEE;CN=Paciente:[email protected] LOCATION:Rua do Sorriso, 32 RRULE:FREQ=WEEKLY;BYDAY=WE;COUNT=10 BEGIN:VALARM TRIGGER:-PT30M REPEAT:2 DURATION:PT15M ACTION:DISPLAY DESCRIPTION:Lembrete! Dentista. END:VALARM END:VEVENT
Figura 3.4: Exemplo de evento recorrente
O exemplo da figura 3.4 mostra um evento recorrente com 10 instˆancias que ocorrem nas quartas-feiras `as 17h, a partir de 19/12/2007. Note tamb´em o uso do parˆametro CN (common name), nas propriedades ORGANIZER e ATTENDEE.
O componente VTODO
To-dos s˜ao usados para representar tarefas pendentes e seus status, e correspondem ao componente VTODO. A propriedade mais relevante de um to-do ´e seu prazo final (DUE). To-dos tamb´em podem conter componentes VALARM.
O exemplo da figura 3.5 mostra um to-do. A propriedade CATEGORIES ´e utilizada para classificar a tarefa, e o valor 5 para PRIORITY indica que ela tem prioridade m´edia, pois os valores permitidos v˜ao de 1 a 9. O valor da propriedade PERCENT-COMPLETE denota que metade da tarefa j´a foi cumprida.
3.2. O estabelecimento de protocolos de comunica¸c˜ao 23 BEGIN:VTODO
UID:[email protected] DTSTAMP:20080108T090000Z
SUMMARY:Declarar imposto de renda DUE:20080430T110000Z
CATEGORIES:BUSINESS PRIORITY:5
PERCENT-COMPLETE:50 END:VTODO
Figura 3.5: Exemplo de to-do
Alternativamente, um to-do pode conter o parˆametro DURATION, com sua dura¸c˜ao estimada, desde que n˜ao concomitantemente `a presen¸ca do parˆametro DUE.
O componente VFREEBUSY
O componente VFREEBUSY permite a representa¸c˜ao de per´ıodos de tempo livres e ocupados (free-busy time). Estes componentes s˜ao usados, por exemplo, para descrever per´ıodos de tempo n˜ao agendados que podem ser usados para guiar propostas de agendamento antes da negocia¸c˜ao de um evento. BEGIN:VFREEBUSY UID:[email protected] DTSTAMP:20080325T122800Z ATTENDEE;CN=B:mailto:[email protected] DTSTART:20080328T000000Z DTEND:20080330T235959Z FREEBUSY;FBTYPE=FREE:20080328T150000Z/PT3H FREEBUSY;FBTYPE=FREE:20080329T163000Z/PT1H30M FREEBUSY;FBTYPE=FREE:20080330T080000Z/PT6H END:VFREEBUSY
Figura 3.6: Exemplo de free-busy time
A figura 3.6 mostra um componente free-busy que descreve, entre os dias 28 e 30/03/08, os seguintes per´ıodos de tempo livre de um usu´ario fict´ıcio “B” atrav´es das propriedades FREEBUSY: das 15h `as 18h no dia 28, das 16h30min `as 18h no dia 29, e das 8h `as 14h no dia 30.
Caso o prop´osito do componente seja expressar per´ıodos de tempo ocupados, valores como BUSY-TENTATIVE, BUSY e BUSY-UNAVAILABLE podem ser utilizados no parˆametro FBTYPE da propriedade FREEBUSY.
O componente VJOURNAL
Os componentes de calend´ario VJOURNAL (journal entries) s˜ao os menos utilizados, e n˜ao tˆem um papel relevante em processos de agendamento. Como to-dos, journal entries n˜ao ocupam espa¸co em uma agenda. Seu prop´osito ´unico ´e organizar informa¸c˜oes dependentes de tempo (e.g., notas de um di´ario).
BEGIN:VJOURNAL
UID:[email protected] DTSTAMP:20080208T170000Z
SUMMARY:Minuta da reuni~ao DESCRIPTION:1. Abertura\n
2. Discuss~oes principais\n 3. Pend^encias\n
4. Conclus~ao END:VJOURNAL
Figura 3.7: Exemplo de journal entry
O exemplo da figura 3.7 mostra um componente journal que sumariza os assuntos tra- tados em uma reuni˜ao. Na pr´atica, journal entries s˜ao apenas parcialmente implementados na maioria dos sistemas que adotam o padr˜ao iCalendar [11].