Subject: [Tools-team] Agenda for the 16 Feb 2005 Telechat

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Feb 2005 14:09:52 +0100

Hi,

Here is the proposed agenda for today's meeting.  

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

1. Agenda bashing

2. Comments on minutes from last teleconference.

3. Action item review.

   * Stas: 	Continue working on the Notification Service
		Requirements.

   * Alex:	Continue thinking about Draft Status Page
		Requirements.
	
   * Alex:	Send concrete proposal to the list for text / document
		changes related to item 1) in the comments on the
		notifications draft, in case the changes are more minor
		than thought during the meeting discussion.

   * Bill:	Try to have a sample XML feed ready, with transformation
		to RSS in place, based on the current database.

   * Henrik:	Help with the mapping of notification elements to Atom

   * Henrik:	Continue with WG pages and Agenda pages work

4. Any other business.

5. Next meeting:

  Teleconference Wednesday 23 Feb, 17: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: Alex Rousskov <[email-masked]>
Date: Wed, 16 Feb 2005 10:01:40 -0700 (MST)

> 		than thought during the meeting discussion.

Here it is. Please let me know what parts need further clarification.

              Requirements for IETF Event Notification Service
                   draft-ietf-tools-notification

Abstract

    IETF generates large number of events, including draft posting
    announcements, last calls, working group charter updates, meeting
    schedule changes, and IESG election results. There is no single
    source of events and the number of events make it impractical to
    monitor all of them. Active IETF participants and 3rd parties need
    a mechanism to receive most events of interest and few irrelevant
    events. This document describes such a mechanism and contains
    implementation requirements specific to handling of draft-related
    events. Other documents may extend the same generic mechanism to
    handling other kinds of events.

Table of Contents

    1.  Requirements Notation
    2.  Introduction
    3.  Event Anatomy
          Type
          Serial number
          Date and time
          Title
          Gist
    4.  Overall operation
          Event generation
          Event subscription
          Event delivery
          Event storage
    5.  Internet Draft Events
          Identifying a draft
          Anatomy
            Document tag
            Document name
            Document action
            Document state
          Draft event generation
          Draft event subscription
    6.  Phases of Tool Development
    7.   Security Considerations
    8.   Internationalization Considerations
    8.   IANA Considerations
    10.   References

1.  Requirements Notation

    AS-IS.

2.  Introduction

    AS-IS but start with a paragraph applicable to all types of events,
    in the Abstract spirit.

3.  Event Anatomy

    3.1. Type

      A URI identifying the type or class of the event. For example,
      all draft events documented below will have the same "draft event"
      type.

    3.2  Serial number

      AS-IS except the number is unique for all IETF events, not just
      for events related to a single document.

    3.3 Date and time

      AS-IS

    3.4 Title

      AS-IS

    3.4 Gist

      Mostly AS-IS: merge current "Event abstract" and "Event URL". See
      my original comments for more details.

4.  Overall operation

    4.1 Event generation

      List a few known sources of events. Document where all IETF events
      should be sent for processing/filtering/storage.

    4.2 Event subscription

      Briefly describe how users can subscribe to events (clicking on
      some buttons or sending an email). List interface types (web,
      email) to be supported for subscriptions. Emphasize automation.
      Talk about subscription confirmations (AAA).

    4.3 Event delivery

      Current "Notification Dissemination Mechanisms", mostly AS-IS.
      List supported delivery interfaces (email, RSS, Atom).
      Mention that event rendering is type- and delivery-interface-specific.
      Mention event storage browsing/searching as a delivery method?

    4.4 Event storage

      Require all events to be stored. Indefinitely?

5.  Internet Draft Events

    5.1 Identifying a draft

     Use current "Document Definition and Document Tags" AS IS.
     We can argue what "this draft" means to a user later.

    5.2 Anatomy

        5.2.1 Document tag (AS-IS)
        5.2.2 Document name (AS-IS)
        5.2.3 Document state (AS-IS plus move current "Document States" here?)
        5.2.4 Document action (current "Event type", AS-IS)

    5.3 Draft event generation

        Describe what generates draft events (the ID publication tool, other?)

    5.4 Draft event subscription

        Move current "Kinds of Notification" here

...

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Feb 2005 21:34:29 +0100

Thanks, Alex.

    I'll let Stas comment on most of this, to me it seems less
radical than the impression I got during the call.  There's one
point I'd like to comment on though; below:

On 2005-02-16 6:01 pm Alex Rousskov said the following:
[...]
>       for events related to a single document.

Is there any particularly good reason for requiring this?  
(As opposed to per-feed serial numbers?)  

As I see it, it is not as useful as a per-document (or other
event-type) serial number for anyone who subscribes to a feed
and wants to check that they have seen all the events, or for
anybody debugging some part of the chain.

It also enforces one central point of numbering, which means
that a lot of otherwise interesting implementations could be
excluded because of this requirement; and it would be harder
to iteratively test and prototype new feeds and event types,
I think.

Note that for a per-feed serial number, I'd still expect the
feed to have some unique identifier - URL, URI or something -
which when combined with the serial number would give a globally
unique identifier for the event.

If there is a strong reason for making this number overall
unique, I would ask for a secondary per-feed serial number,
anyway, as that would seem more immediately useful to me on
both the generating and consuming end of a feed...

	Henrik

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 16 Feb 2005 14:08:46 -0700

> (As opposed to per-feed serial numbers?)

I hope so. IMO, one should be able to refer to any event (regardless of  
type) by the event ID.Event storage and other management algorithms would  
make use of it. Even humans will use it for bug reporting and such. Note  
that the cost of producing a unique ID is negligible in this context. No  
complex schemes are needed. For example, an MD5 checksum over all other  
event fields would suffice.

The world certainly moves into that direction, with IPv6 addresses for  
every device or RF tags for every human :-).

> anybody debugging some part of the chain.

Per-document numbers might be useful as well. One does not preclude the  
other.

> to iteratively test and prototype new feeds and event types,

I would not generate that number centrally (see the MD5 example above). I  
should have mentioned that, but I decided that increasing-without-gaps  
versus just-unique debate can wait until later. That was probably a  
mistake.

BTW, I am also not convinced yet that there will be a single source or  
single sink for all document-related events. If there is no single  
source/sink, then there cannot be an increasing-without-gaps ID, even for  
document events. This is just a question for a future discussion,  
secondary to the subject of this thread.

I do find the "did I miss any events?" feature interesting. However, with  
all the filters, I am not sure it would be practical to support it based  
on a single event number. Imagine, for example, that I only receive "last  
call" events for a given document. Did I miss any last calls? The proposed  
serial number will not tell me. One can argue that Last Call should have  
its own event type, of course. That solution will lead to many event  
types, which perhaps is a natural path to take. However, I can construct a  
more complex filter where a new event type is not appropriate.

> unique identifier for the event.

This ID must not be specific to event type for it to be useful for general  
purposes. General algorithms will not know about document-specific fields.

> both the generating and consuming end of a feed...

Yes, except I am worried about your "single feed for a given event type"  
assumption. It sounds too centralized to me and, as the examples above  
illustrate, does not seem to solve the problem of detecting "missing  
events" in case of a non-trivial subscription filter. We need to discuss  
this further, and the restructured document should state our single-source  
or multiple-source assumptions clearly.

Again, this issue is secondary to the overall generic-versus-specific  
restructuring I am advocating. I agree that we must decide how to identify  
events, but that decision may come later as both approaches can accomodate  
various event identity schemes.

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Feb 2005 22:58:26 +0100

> every device or RF tags for every human :-).

Ok. I don't mind something like an MD5 checksum - however this
is not strictly a _serial_ number; which was the base of my
objection (producing a global event serial number).

> Per-document numbers might be useful as well. One does not preclude the  

Agreed.

> versus just-unique debate can wait until later. That was probably a  

Ok, cleared up now.

> secondary to the subject of this thread.

I agree there will almost certainly be multiple sources; I'm not sure
we can't arrange to have a single source per serially numbered events.

> more complex filter where a new event type is not appropriate.

Agreed.  I'm only thinking in terms of serial numbers for base events.

> purposes. General algorithms will not know about document-specific fields.

Agreed.

> or multiple-source assumptions clearly.

I guess.  Although I'm not this obviates the usefulness of serial
numbers for base events.

> various event identity schemes.

Fair enough, in this context.

	Henrik