Subject: [MMUSIC] RE: Comments on IMG framework -02

From: [email-masked]
Date: Sun, 25 Jan 2004 14:27:23 +0200

Hi All

Thanks Pekka for the proposal. Since the discussion on whether a new UNSUBSCRIBE _operation_ is needed seems to remain open, I'll add my two cents...

(I'm CC'ing MMUSIC as there may be wider opinion worth taking in before the 03 ID submission)

This is basically echoing Yuji's remarks that the SUBSCRIBE operation inherently includes subscribe and unsubscribe features (regardless of the number of and types of messages). We discussed this in San Francisco and did consider that the "subscribe" operation it does not "only and forever subscribe", but also resleases/unsubscribes. I've been working on the notion that IMG SUBSCRIBE is pretty much analogous to IGMP REPORT, so that the protocol messages allow differential subscribes and unsubscribes (i.e. not just "subscribe to all notifications", but differentiating between them. Also, that the messages would provide the unsubscribe functionality from the same basic operation). In this sense the name "IMG SUBSCRIBE" eclipses this issue, maybe "IMG SUBSCRIPTION" or "IMG SUBSCRIPTION REPORT" would be more appropriate.

Thus, (IMHO) the subscribe operation is sufficient to include subscribe and unsubscribe functionality / message types when it is "applied to reality" in a protocol specification.

However, this is rather academic since whether or not we add "unsubscribe" as a separate operation or keep the functionality within the subscribe operation: we have exactly the same result in protocol design based on the IMG framework - so whatever is easiest to accept is OK for me.

To help balance the two options, here's "competing text" against Pekka's giving a clarification of "unsubscribe" being a part of subscribe so we can basically implant this text or Pekka's depending on consensus (Pekka's text is below). (Note, although this does not require any other changes elsewhere in the document, Pekka's requires bare minimal changes too so neither are much different in terms of minimising effort).

> 3.2.4 IMG SUBSCRIBE
> 
>    If an IMG receiver wants to be notified when the IMG metadata it
>    holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
>    in advance in order to solicit notify messages from an IMG sender.
> 
   This operation may provide the IMG sender with specific details of which
   metadata or notification services it is interested in (in the case where the
   IMG sender offers more than the simplest "all data" service. The operation 
   implicitly provides the functionality of unsubscribing to inform an IMG
   sender that an IMG receiver wishes to stop getting certain (or all)  
   notifications. It should be noted that the unsubscription may be provided  
   implicitly by the expiry (timeout) of a subscription before it is renewed.  
   However, these details belong to the messaging protocol and are beyond the 
   scope of this document.

>    Since the IMG receiver doesn't know when metadata will be updated and
>    the notify message will arrive, this operation does not synchronize
>    with the notify messages. The IMG receiver may wait for notify
>    messages for a long time. The IMG sender may authenticate the IMG
>    receiver to investigate whether an IMG SUBSCRIBE operation is from an
>    authorized IMG receiver.
> 
Thoughts?

For completeness, it seems that this is the list of actions needed for the framework:
* solve "unsubscribe is/is not a different operation" issue an implant text (Yuji) from either Rod or Pekka (if Pekka's also modify operation set figure)
* delete mention of CDI (as it does not add value) - Yuji
* add text on RTSP applicability - Yuji
* add IANA considerations and IPR boilerplates -Yuji (which ones do we select?)
* a handful of typo/minor text Tuesday this week?)...
* Submit 03 (WGLC-ready version?) - note although IETF-59 deadline is in Feb, I expect the end of this week would be feasible?

Cheers, Rod.

-----Original Message-----
From: Luoma Juha-Pekka (Nokia-NRC/Tampere) 
Sent: Friday, January 23, 2004 10:16 AM
To: [email-masked]; [email-masked];
[email-masked]; Walsh Rod (Nokia-NRC/Tampere)
Cc: 'ext Colin Perkins'; [email-masked]
Subject: RE: Comments on IMG framework -02

Hi all,

There's a few minor issues that we should resolve in both Framework and Requirements. In theory this process could be optimized by different people tackling different issues, so I tried picking one item from the list and doing some editing. This item was adding an IMG UNSUBSCRIBE operation to IMG Framework. It would have been a good idea to indicate that I'm going to work in this area, so hopefully I did not repeat anybody else's work - would be a good idea to announce that you are going take on a work item.

The resulting draft-ietf-mmusic-img-framework-03a is attached as two HTML documents, one with changes tracked and another without tracking. Figures might still need updating as a result of adding an unsubsribe message, I can finish those. Please share your comments.
<Rod inserts this text from the attachment...>

3.2.1 IMG ANNOUNCE

   When an IMG receiver participates in unidirectional communications
   (e.g. over satellite, terrestrial radio and wired multicast networks)
   an IMG receiver may not need to send any message to an IMG sender
   prior to IMG metadata delivery. In this case, an IMG sender can
   initiate unsolicited distribution for IMG metadata and an IMG sender
   is the only entity which can maintain the distribution (this includes
   scenarios with multiple and co-operative IMG senders). This operation
   is useful when there are considerably large number IMG receivers or
   IMG receiver(s) do not have a guaranteed uplink connection to the IMG
   sender(s). The IMG sender may also include authentication data in the
   announce operation so that IMG receivers may check the authenticity
   of the metadata. This operation is able to carry any of the IMG data
   types.

   Note, there is no restriction to prevent IMG ANNOUNCE from being used
   in an asynchronous solicited manner, where a separate operation
   (possibly out of band) is able to subscribe/register IMG receivers to
   the IMG ANNOUNCE operation. Similarly, a separate operation may be
   provided to unsubscribe/deregister from the IMG ANNOUNCE operation.

...
 
3.2.4 IMG SUBSCRIBE
 
   If an IMG receiver wants to be notified when the IMG metadata it
   holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
   in advance in order to solicit notify messages from an IMG sender. The
   IMG SUBSCRIBE operation triggers the transmission of a subscribe
   message from the IMG receiver to the IMG sender. 
 
   A subscription created as a result of IMG SUBSCRIBE is active for a 
   period of time that is well-known or indicated in the subscribe 
   message, or possibly signaled out of band. The subscription expires at
   the end of this period, causing the IMG sender to stop sending notify 
   messages pertaining to this subscription. The active time of a
   subscription can be extended/changed by re-using IMG SUBSCRIBE or
   terminated prematurely by using IMG UNSUBSCRIBE.

   Since the IMG receiver doesn't know when metadata will be updated and
   the notify message will arrive, this operation does not synchronize
   with the notify messages. The IMG receiver may wait for notify
   messages for a long time. The IMG sender may authenticate the IMG
   receiver to investigate whether an IMG SUBSCRIBE operation is from an
   authorized IMG receiver.

3.2.5 IMG UNSUBSCRIBE

   An IMG receiver can use the IMG UNSUBSCRIBE operation to cancel an
   active subscription initiated by IMG SUBSCRIBE. The use of IMG UNSUBSCRIBE
   triggers the transmission of an unsubscribe message from the IMG receiver 
   to the IMG sender. Receiving this message instructs the IMG sender to
   ignore any remaining active time of the subscription and treat the 
   subscription as expired.

-Pekka

> -----Original Message-----
> From: ext Colin Perkins [mailto:[email-masked]]
> Sent: 06 January, 2004 19:06
> To: [email-masked]
> Cc: Luoma Juha-Pekka (Nokia-NRC/Tampere);
> [email-masked]; [email-masked]; Walsh Rod
> (Nokia-NRC/Tampere)
> Subject: Re: Comments on IMG framework -02
> 
> 
> Hi,
> 
> --> Yuji Nomura <[email-masked]> writes:
> >  On Wed, 31 Dec 2003 17:50:18 +0000 
> >  Colin Perkins <[email-masked]> wrote:
> > 
> > > Is an IMG UNSUBSCRIBE message needed? Or is this 
> considered merely an
> > > implementation detail?
> > 
> > I think UNSUBSCRIBE is an implementation option, although 
> it is useful
> > in some cases. Since Section 3.2 introduces abstract functions, 
> > SUBSCRIBE message may have the function as UNSUBSCRIBE.
> > 
> > It may be better to mention that in section 3.2.4.
> 
> I'd suggest that UNSUBSCRIBE is logically separate, so would 
> need a new
> message type. 
> 
> ...
> > > In Sections 5.1 and 5.2, I see no mention of RTSP. I 
> don't think RTSP
> > > is an appropriate protocol for the IMG, but it does 
> support some IMG
> > > functions in a limited way. May be appropriate to include 
> it in the
> > > draft, to explain why it's not suitable.
> > 
> > Yes, it is right.
> > 
> > As far as I know, RTSP has some methods, such as ANNOUNCE and
> > DESCRIBE, which supports some IMG functions. However, these methods
> > can carry information for just one session, therefore RTSP supports
> > the function in very limited situation.
> > 
> > Is it correct? Any other thing to be mentioned?
> 
> I believe that's correct. RTSP is a very limited IMG 
> protocol, but should
> be mentioned for completeness.
> 
> Cheers,
> Colin
>  << File: draft-ietf-mmusic-img-framework-03a.htm >>  << File: draft-ietf-mmusic-img-framework-03a_changes_tracked.htm >> 

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