> From: Joel M. Halpern, October 05, 2015 5:40 PM
> 
> I think I am missing something in the discussion of this first point about
> separation.
> While lots of implementation strategies are possible, the communication
> pattern I would anticipate for I2RS is that an I2RS client is communicating 
> with
> an I2RS Agent who handles some piece(s) of information.  The client would send
> its subscription to that agent.  The client would expect the information 
> resulting
> from its subscription to come back on a communications channel from the same
> entity.
> 
> So unless we add a lot of extra mechanisms to the protocol, I don't see how 
> the
> effective manager of the subscription service for I2RS can be separate from 
> the
> effective producer as seen by I2RS.

I agree with you.   I was trying to convey that I see no reason that the 
Requirements for the Subscription Service cannot be augmented (not changed) to 
allow for additional internal interface specifications.   

In this case, both incremental requirements and protocols would be needed.  
There certainly wouldn't be one protocol.  I have no desire to pursue this 
myself.  Others might.

> You can have brokers who accept subscriptions from multiple parties, subscribe
> on their own behalf to the I2RS agent, and then fan the results out to other
> parties.  But that would seem to represent a
> (legitimate) reuse of the subscription mechanism in a different context.

Yes.

Eric

> Yours,
> Joel
> 
> On 10/5/15 5:22 PM, Eric Voit (evoit) wrote:
> > Hi Joe,
> >
> > -----Original Message-----
> > From: i2rs, October 05, 2015 12:59 PM
> >
> > I'm reading through the latest draft, and I have a few questions/comments.
> >
> > In section 3, could the Subscription Service be an external broker?
> > Said another way, it reads like the Subscription Service is/could be an 
> > external
> entity.  Is that the case, or will this always be a component of the 
> Publisher?
> > <Eric> I don't know of any reason why the Subscription Service must be a
> component of the Publisher.

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to