Subject: RE: [Simple] A comment to draft-olson-simple-publish-01

From: [email-masked]
Date: Mon, 18 Nov 2002 15:19:17 +0200

Hi,

Comments inline.

[...]
>  > Although the draft says that 489 (Bad Event) should be sent in case
>  > the composer doesn't understand the published event state, there is
>  > no mention of Allow-Events used in that case. Allow-Events is
>  > mandatory in 489 according to RFC 3265. If it is also mandatory for
>  > 489 to a PUBLISH, it would seem logical that it is also 
> (optionally)
>  > used with OPTIONS (for one). Would then Allow-Events in a 2xx to
>  > OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both?
> 
> Neither. The Allow header indicates whether SUB/NOT and/or 
> PUBLISH are 
> supported. Allow-Events indicates the event packages 
> supported. It may 
> be that a UA doesn't permit outside elements to PUBLISH for a 
> specific 
> event package it supports, but thats really a policy issue, 
> not an issue 
> of whether some package or method is implemented.

Well, the way RFC3265 reads to me suggests that Allow-Events indicates exactly that the node can process the SUBSCRIBEs and NOTIFYs for that particular event package. For clarity's sake I think we need a similar capability specifically for PUBLISH.

I agree that the authorization policy for a PUBLISH is not in any way related to the contents of Allow-Events, and may in fact be quite similar to an auth policy for a SUBSCRIBE. We might even consider that some sort of publish-winfo could be reused for reactive authorization of publications.

However, this somehow suggests that publish be its own framework, and not an additional part of the events framework.

>  > Why not a new pair of headers, which share the event-type (for
>  > packages) namespace with Event/Allow-Events, something like what's
>  > described in
>  >
>  > 
http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framew-
 > ork-00.txt
 >
 > AFAIK, we are not running out of space with header names ;)
>
> No. However, I really don't see the need for defining another entire 
> package concept for publications. I would propose that any "publication" 
> not tied to events (such as uploading a CPL) is probably not going to 
> have the same requirements that event publication has, and probably is a 
> better fit for the data manipulations being discussed in the data 
> requirements document and Markus's semantics draft.

I agree that CPL uploads fall well out of the scope. And I also agree that there isn't maybe a huge need for an entire package system. Having a package would be useful if/when we start defining things like default expiration of state for a particular package, publish payloads that are distinct from NOTIFY bodies, etc. But again, this isn't real concrete yet, nor is it a big issue for me if there isn't a package concept, but things are left for composer policy. Either way works.

But there are many degrees to what I'm proposing, and I'll try to bring this into the discussion in the SIMPLE session today.

Cheers,
Aki