Subject: [Tools-team] Minutes from the 7 September 2005 Telechat

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 07 Sep 2005 18:30:15 +0200

Hi,

Here minutes from today's meeting.

------------------------------------------------------------------------

0. Present: Alex, Jeroen, Henrik

1. Agenda bashing

	No comments

2. Comments on the minutes from previous meeting

	No comments

3. IETF-63:

	* IANA meeting - Bill?

4. Status review

   * Event scraping and generation, event xml schema, dashboard
	- Henrik

	"I've started writing the event collection and generation scripts,
	and I'm iterating on the exact XML schema to be used to represent
	each event.  The 3rd major revision appeared last night, and I'm
	now doing some refinement, in particular related to event id,
	making it easier to discover duplicate events, and exactly what
	information is relayed with the event, and which is kept in the
	separate draft meta information (XML) database.

	I currently have the first rough version of that running, ticking
	over and generating events from the rfc editor queue and the 
	ID-tracker, but it needs some refinement of both code and XML
	schema before I'm satisfied with it.  I also want to add event
	generation from the ietf-announce and i-d-announce mailing lists.

	When that's pretty solidly in place, ticking over and generating
	new events, I'll feed in historical data based on the archives of
	the ietf-announce and i-d-announce mailing lists, and Bill's
	archived snapshots of the RFC editor queues.  But that's the next
	work item, once the daily event generation is solid."

	Alex: Do we need a separate element in the event part which tells
	you what object this refers to? - Maybe not, we'll see.
	For the cases where you want to make a summary of events, do we
	want to include a headline in the event - or do we want to derive
	that from the information that changed in the object?  - Probably
	the latter, for consistency.

   * Event notification prototype
	- Jeroen

	"Basically I now have a non-working prototype of a website, which
	gives one a personalized overview of a all the areas, wgs and
	the documents that each draft contains including possibility to
	set notification items.

	A user is able to signup using one (or multiple) email
	addresses, these mail addresses then map to an entity. Such an
	entity could be a 'person' or a 'role' (/group), as such the
	"Tools Team" would be a role entity with multiple email id's
	attached which make up this entity. One email address can be
	associated with multiple entities and at login or using a switch
	one will be able to pick which entity you want to be. This
	allows the entity to be used for ACLs and still keep your
	personal view as your own person entity allowing one to follow
	personal interests but also to do another role.

	A user then is subscribed to documents/wgs/areas that person
	is interested in. For each doc/wg/area one can specify
	notifications.  Broad ones like "notify for anything that
	happens here" and things like "new document in wg X", "new wg
	started in area Y", "document last call for document Z" etc.
	Regexps could even help out in allowing people to get
	notifications about all kinds of documents matching a certain
	title.

	The 'home' page of a user will thus be an overview of all the
	subscriptions that a user made. The site also is going to have
	full knowledge about all existing wgs/areas/docs so users can
	select it.  The tools we already have can easily be integrated
	in that site structure by linking to them in an automated way.

	When then an event comes in over Henrik's event notification
	mechanism, the backend of the site matches all the subscriptions
	that want information about it and notifies these users using
	the methods they specified. Currently I've added possibilities
	for irc/jabber/icq/msn/yahoo (abusing bitlbee) and email. One
	could then also, per subscription, select for diffs, xml markup
	and other modes which we can add later on.

	An event also causes the backend to log this information. Thus
	when you go on vacation you simply disable events, after coming
	back, you enable them again and request a list of what events
	that you are subscribed to where supposed to be triggered during
	that period, or any period actually.

	Toys used to build this up: php backend, code in classes which
	can be called from the 'web' and from command line. Currently a
	mysql database.  Bitlbee for the IM notification part, thus
	simply abusing IRC to interface with them all."

	Henrik: Looks good.  Events will probably come in with only the
	changed information attach - full information will have to be
	fetched from separate meta-information for the draft, wg, etc.

	Alex: Looks good - will have more comments when the prototype
	is up and can be looked at.

   * Draft info draft
	- Alex

	No time, so no progress :-(

   * Scheduling tool
	- Donald?

	No info, Henrik will ping

   * IETF Website re-vamp
	- Andrew?

	No info, Henrik will ping

5. Any other business

	No other business.

6. Next meeting:

  Teleconference Wednesday 21 Sep, 16:00 GMT (same local time 
  as today).

------------------------------------------------------------------------
Connection details:

To join the call, dial +1-734-615-7474 and enter PIN 0151989.

One can also join the call by dialling:
 sip:[email-masked] 
on a SIP-enabled voice communications client. 

If the SIP client cannot dial URLs, you can have the conference
system call you if you have the sip URL for your phone.  Go to
 https://edial.internet2.edu/call/0151989
and type in the URL to your phone, and follow the directions.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Sep 2005 15:55:32 -0400

Hi all,

> 	- Andrew?

Sorry for submerging over the past few weeks.  We've undertaken a
minor re-organisation here, whereby I moved out from daily operations
duties (into the fire of DNS, so it's not like the new assignment is
relaxing :-) ).  Anyway, the work leading up to that, along with the
handover, has meant mostly that I've been looking at these things in
approximately 10-minute increments.  Needless to say, that's not the
most efficient way to work.

In any case, I have had a chance to look at the site some more, and
to attempt a whack at my first proposal.  And while I think that
proposal is still possible, I think we need to think twice about it;
or at least, understand what we're getting.  In the mean time, I've
attached a pathetic little sample I put together this morning.

As I understand the plan, what we're doing is proposing some new
strucutre, but then the Secretariat's paid staff will come in and
handle both the actual implementation, and the ongoing maintenance. 
(If I'm wrong about that, stop me now and correct me -- the rest of
this is a waste of time).

If I'm right, we have a number of design goals here.  They're in no
particular order below:

	* improve the site usability (navigation, &c.)
	* improve the site's recommendations conformance
	* improve, or at least leave the same, the site's
		maintainability
	* allow obsolete browsers to use the site (in some degraded
		mode)
	* allow text-only browsers to work
	* keep to a minimum the technical requirements for the site.
	* make mirroring easy and low-bandwidth

Here's the problem I see:  the actual site files appear to have been
organised according to whatever principle was active at the time; or
at least, the principle isn't obvious.  That means that
implementation of any revamp is going to involve looking at, and
probably manually editing or moving, every file.  I worry about the
liklihood of implementation under that stricture.  (This sort of
depends on the technical sophistication of the staff, and I don't
have a feel for that.)

In spite of our previous rejection of this answer, therefore, I
wonder whether we shouldn't investigate some sort of server-side
publication or templating system, which will allow more cut-and-paste
type migration.  It requires a much greater up front investment in
software and set up; but it couls still generate static sites that
will be relatively easy to mirror (hrm -- I'm assuming this; maybe
none of the publication systems really will do that).

In any case, in the meantime, attached is a little tarball that
includes a basic outline of the approach I'd originally planned. 
This one turns out to be even simpler than my original outline, but I
suspect it's (at least visually) enough, and still simple enough to
cause no trouble when using lynx, &c.  It validates, but it doesn't
do anything very interesting (and most of the links are currently
broken).  If this seems totally the wrong place for a bridgehead, I
guess it's best to move now.

Again, apologies for the slow movement.  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110