Subject: [Tools-discuss] A simple tool...

From: Baker Fred <[email-masked]>
Date: Tue, 22 Mar 2005 13:02:30 -0800

What would it take for the secretariat to post the agenda in (among 
other things) CalSched (aka Outlook/iCal) format? many of us are using 
a CalSched-based calendaring tool. It would be nice if we could 
share/import that data...

I have put together a simple prototype. If you look at
     ftp://ftpeng.cisco.com/fred/ietf-agenda

you will find the agenda for IETF 62 extracted from agenda_62.txt using 
a simple awk script and recast as if it were the agenda of IETF 63. The 
files at that site include a shell script, an awk script, the agenda 
for IETF 62, and the calendars (.ics files) the meetings associated 
with specific areas, the "other" things like breaks, receptions, and 
plenaries, and a calendar incorporating them all.

My thought is that whatever tool generates agenda_N.txt could run my 
script or something like it and produce a calendar from it, or if 
someone wanted such a calendar could be generated and then used to 
schedule the meetings.

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 22 Mar 2005 22:36:00 +0100

> someone wanted such a calendar could be generated and then used to 

Very nice.  We could certainly start by making this available as a
prototype on tools.ietf.org, for IETF-63.  (How we migrate tools from
there to the production environment is not clear yet, but we should
be able to work that out once IASA is up and running, and we have
contracts in place.)

Somebody posted an .ics file for IETF-62 ahead of the meeting too,
but that one lacked timezone information.  I notice that you've
included that, which is very nice.  The same goes for the place of
each meeting.

One thing I would consider adding when putting this up as a prototype
is an option to make individual extracts from the total calendar, by
indicating which working group acronyms were of interest in a web
form, and have an individually tailored .ics file delivered.  

	Henrik

---

From: "Brett Thorson" <[email-masked]>
Date: Tue, 22 Mar 2005 16:51:08 -0500 (EST)

Hi Mr. Baker,

Sorry to answer your question with a question but; What about a place that
houses tools that can be used against IETF data, but doesn't get run by
the IETF or make the IETF responsible for them?  I suggest this for the
following reason.

After hours & e-mails of negotiations, we finally get the secretariat to
run this script for us, it will then become part of the required
operations performed by the secretariat and require that it be maintained
by the secretariat.

This script is used for two or three years and then maybe the format isn't
as popular anymore.  Now how do we terminate this tool?  It took "X"
amount of effort to get the secretariat to accept and run this script now
it will take "X*5" amount of effort to see if anyone is using it, find out
if we should keep it around, then judge to see if those people can
convince the secretariat that it is a dire and needed service and should
not be terminated (possibly at the expense of other utilities that would
benefit more people, but aren't in the scope of these 5 people who really
want this calendar making script).

The TEXT file might never go out of date, and it is an easily modifiable
format.  However, the Outlook/iCal format, well who knows if that is going
to be around and popular in 5 years.

The problem comes about that if even 5 people seem to use the iCal format
after 5 years, it makes it difficult to cut them off (see discussions
about the MAILSERV facilities).

If however, the tool is made available to the community at will, it then
becomes more of an open source model, where by if there are people who are
using it, and depending upon it, let them support it.  If it comes down to
5 people who have the strength to vocally support it's continued use but
not sit down and support it with code and modifications, then the answer
is clear, defined and easy.

In the end, it allows the secretariat to focus on something with a longer
term goal, with a wider audience.  Maybe making it a .CSV file with
defined fields for example or publishing it in XML.  That way anyone can
write tools to modify that data into their desired format, and the IETF
isn't supporting one protocol over another or one company's format over
another.

If you support the script, and run the code for each meeting, that would
be great.  If you get sick of maintaining the code, you can quit.  If you
want to pass the torch, you can.  If you quit, and nobody says anything,
you tombstone the project.  For the IETF/Secretariat to take quick and
decisive measures to terminate these tools might be a significantly larger
undertaking simply due to the nature and consistency of the community that
it supports.

Mind you this is not the fault of the IETF or the secretariat, more over
it is the difficulty that is inherent in the model where there is
1.  scarcity of resources
2.  A very heterogenous base of users
3.  A base of users with a focused view of their needs and how they are
most productive
4.  An inability to possibly judge the cost/benefit of their request
against the greater good (scarcity of global knowledge i.e. what else
could the secretariat be working on).

Regards,

--Brett

> What would it take for the secretariat to post the agenda in (among
other things) CalSched (aka Outlook/iCal) format? many of us are using a
CalSched-based calendaring tool. It would be nice if we could
a simple awk script and recast as if it were the agenda of IETF 63. The
files at that site include a shell script, an awk script, the agenda for
IETF 62, and the calendars (.ics files) the meetings associated with
specific areas, the "other" things like breaks, receptions, and
plenaries, and a calendar incorporating them all.

---

From: Baker Fred <[email-masked]>
Date: Tue, 22 Mar 2005 14:04:14 -0800

> form, and have an individually tailored .ics file delivered.

That is easily enough done. My only real comment is that it begins to 
look like an applet or a perl script rather than a file to download.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 22 Mar 2005 23:36:14 +0100

> look like an applet or a perl script rather than a file to download.

Yes.  It's just that my experience with the .ics file for IETF-62 was
that the time it took to remove those meetings I had no interest in so
that I could get an overview and useful calendar was large enough that
I did *not* want to re-do the import if/when the agenda would change -
which it did after I'd done the import ...

	Henrik

---

From: Baker Fred <[email-masked]>
Date: Thu, 24 Mar 2005 10:00:00 -0800

On Mar 22, 2005, at 1:51 PM, Brett Thorson wrote:
> Sorry to answer your question with a question but; What about a place 
> that houses tools that can be used against IETF data, but doesn't get 
> run by the IETF or make the IETF responsible for them?

I have no problem with that. There is some requirement that we have 
some understandings among us of how that might work.

For example, right now my prototype is an awk script that uses command 
line parameters. In all probability, for a general tool, you would want 
me (or someone) to externalize a web page (that the secretariat can 
point to) that used a java applet to download the agenda from the right 
place, accept some set of text strings (like "v6ops", "BOF", "Plenary", 
etc) as selectors, and create a calsched file using your compute cycles 
and leaving the resulting file on your machine. That's all well and 
good, unless someone has a particular love of perl or any of a list of 
other options.

In the particular case, the changeability of the agenda format also 
poses a problem. In my tool, I make a number of assumptions, like that 
the names of days will be capitalized throughout (but I have seen 
agendas on which Friday was written "Friday" instead of "FRIDAY"), or 
that the location of a general meeting follows a " - " string (as in 
"Reception - Grand Ballroom") on certain lines and is the text 
preceding the area ID (as in "Salon E TSV v6ops ...") on others. OK, 
what if "Reception - Grand Ballroom" gets written "Reception- Grand 
Ballroom"? My tool will miss the location and include the information 
with the name of the event. And how do I parse a hyphenated name, 
should that come up?

There are a number of possible solutions to that. The simplest is to 
ask the Secretariat to own it and handle it; I could imagine them 
building yet-another-output from whatever tool they use, or manually 
managing an Outlook/iCal calendar and exporting the result.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 24 Mar 2005 22:51:10 +0100

on 2005-03-24 7:00 pm Baker Fred said the following:
[...]
> managing an Outlook/iCal calendar and exporting the result.

There's also the additional option of moving in the direction in which
we (the tools team) has desired to move for some little time now, which
is to define XML schema for all information published by the secretariat,
and get the information published in XML format along with any other
textual or html or whatever format.

That would make the basic information the responsibility of the
secretariat, while providing a solid and consistent base on which to
build other tools.

	Henrik