Subject: SDP "category" or "thread" field

From: Mark Handley <[email-masked]>
Date: Wed, 03 May 95 13:02:32 +0100

One suggestion made at Danvers was to add a "category" or "thread"
field.  The intention is to make it easier for a client to display
only sessions a user is interested in (ie, to use it to filter
announcements).

I think this is a good idea, but I've been trying to decide what form
it should take, and come to the conclusion that I'm not really sure
how it would be used.

My thoughts were that this would be hierarchical in a similar fashion
to usenet newsgroup names (didn't Jon Crowcroft suggest this back in
1992?).  Thus when a new session is announced, it gets displayed if
you've expressed an interest in that category.  If you didn't express
an interest in that category, then the highest level of the hierarchy
which you haven't expressed an interest either way would be displayed.
If you expressed a disinterest in any level of the hierarchy then the
session is simply not displayed.  (This is not necessarily the same
issue as Ross's subdirectories, although it might look similar to a
user)

Now, this could work, but conference sessions aren't really like
usenet news groups - they usually don't need the hierarchy to tie a
thread together, and there's much more of a problem with hierarchy
bloat (it's not so easy to set up a new news group as it is to create
a new session with a new category).  It's not clear how someone new to
the game is presented with a suitable categorisation for their
session.  It seems that if we do this, we risk the categorisation
degenerating into chaos and becoming of little use.  Any ideas how we
could manage this?

Other options are available. For instance, we could just have a set of
keywords.  However, it's not clear to me whether this solves much.

Ideas?

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 May 1995 15:21:30 +0200

First, I'd avoid specifying in detail how an application might display 
sessions (or not). As was said before, this is a protocol, not an 
application. (Which doesn't mean that we shouldn't be thinking about 
how things might get implemented, naturally.) Applications may decide 
that wildcard filtering (*.beatles), implicit hierarchical filtering 
(comp.protocols matches any comp.protocols.*), etc. are the right thing.

There's actually a strong disincentive to creating random categories if 
you want widespread distribution/visibility, as receivers will likely 
have to know about your category to have your announcement show up. On 
the other hand, I'd expect 'affinity groups' to create the equivalent 
of local hierarchies. e.g., gmd.radio within GMD.

The algorithm is simple: whichever newsgroup you post announcements to, 
you use in your SDP field :-) It seems to me that the existing Usenet 
hierarchy could serve reasonably well; people also tend to have a good 
idea as to what's generally appropriate for the existing groups 
(spammers etc. excluded), avoiding having to come up with new group 
descriptions.

I assume you were also thinking about 'cross-posting'? (Once you allow 
multiple groups for the same announcement, keywords become a kind of 
degenerate hierarchy).

Henning