31     Define late binding and determine where late binding is supported

       Expanding recipient list from logical EPR?

       Late binding refers to delaying the resolution of logical EPR
       to physical EPR. That operation has been moved to the advanced
       infod specs document.

       FYI: workaround for based infod specs is to support a list of
       physical EPRs. Similar to existing WSN support.

        - Date: 21 Jul 2005
        - Owner: Shailendra, Cecile
        - Target date: Not in base spec


43     Describe the two approaches:
        (1) Re-pacakaging a message at each hop in a new header
        (2) Removing the header and adding a new appropriate message
            header after transformation

        The following should be incorporated by Cecile into the spec
        which is currently locked.

	  Since the get data call returns just the body of the
	  message. In my understanding we need another call:
	  getMsgInfo,+which will return an opaque message metadata
	  back to the client.  The client can call getAttribute on
	  this opaque data to get the necessary info.  Similiarly the
	  publish call needs to take this opaque data as an Argument
	  which can be populated through setAttribute call.  The
	  getAttribute, setAttribute operate on a descriptor and one
	  of the ways we populate them is as under:

	  SetAttribute(MsgDesc, MsgPropertyNm, MsgPropertyVal);
	  GetAttribute(MsgDesc, MsgPropertyNm, MsgPropertyVal);

       Cecile is not happy with this yet  

       End-users who want to implement non-repudiation checks need to
       be able to access the manifest section of the message, at
       Consume time. So this is a consumer operation.

       Issues like authorization to view the manifest, maybe decoding/
       decrypting need to be considered. For now though, we give the
       raw message to the Consume operation, as described in 3.9.1 of
       the specs (v12).

       So delay the delivery of these new operations to the 'advanced
       infod specs', which will also include the getData operation, so
       will address both getting (pulling) data and getting (pulling)
       metadata.

       - Date 3 Oct 2005
       - Owner: Shailendra, Cecile
       - Target: 20 Oct 2005


48     Define sequence number,operationalCharacteristics more clearly

       The following should be incorporated by Cecile into the spec
       which is currently locked:


          Sequence no is used to group messages based on message/selector
          attributes. The publish and getData api needs to enhanced
	  substantialy to handle grouped messages.

          Here is an example: Consider a set of messages which need to be
          Grouped together:
        
            We call begin_group() which establishes the group context.

            Now call publish() once for each message in the group.

            Call end_group().

            The Api?s implicitly associate sequence no. for each
            message in the group.

          Now on the get side:

            Call get_first_group() which establishes the message group
            context.

            Call get first message using the group context. 

	    Now call get_next message until all messages in a group
            are exhausted.

	    Now call get_next_group and so on.

          This allows a user to manipulate a group of messages.

        Then it will be DONE

        Something we need to spec as this is a differentiator from
        base notifications, however doesn't belong in base infod specs
        (grouping messages' concept).  So needs a place-holder to
        describe in the 'advanced INFOD specs'.

       - Date 3 Oct 2005
       - Owner: Shailendra, Cecile
       - Target: 31 Oct 2005