Subject: [Simple] RFC 4662 Clarification

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 5 Nov 2008 14:23:41 -0500

Hi,

I would like to clarify the meaning of the "fullstate" attribute in RFC 4662
when it is set to true.

Basically the question is the following:
If I am supporting pidf-diff and subscribe to an RLS, can I assume that
whenever I receive an RLMI with fullstate=true that for all "active
instances" of this RLMI I will have full PIDF information (either
"application/pidf+xml" or "application/pidf-diff+xml" with <pidf-full>
element)?
Here "active instances" are <instance> childrens of  <resource> with the
state attribute set to "active"

4662 specifies that when fullstate is set to true, all "state" must be
removed and rebuilt from the information available in the RLMI. Unless I am
confused by "state" (I assume the state being transported by the RLMI, PIDF
as an example, as well as the RLMI list of resources), this only then works
if full state information is transmitted instead of partial state info. The
misleading part comes in section 4.6, where it is stated that if full state
is specified, it applies only to the RLMI document in which it occurs. I
would have expected this to trickle down to "embedded" RLMI as well as any
other type of payload. Now because RLMI with fullstate is allowed to
transport "partial" RLMI, I am wondering if my understanding about the other
type of payloads is right.

As an example, if we take the figure on page 16 (copied for your
convenience), I would have expected Part D (and Part C, E and F) to contain
full state information if Part A specified full state information.

       +-------------------------------------------+
       | Top Level Document: multipart/related     |
       |                                           |
       | +---------------------------------------+ |
       | | Part A: application/rlmi+xml          | |
       | +---------------------------------------+ |
       | | Part B: multipart/related             | |
       | |                                       | |
       | | +-----------------------------------+ | |
       | | | Part D: application/rlmi+xml      | | |
       | | +-----------------------------------+ | |
       | | | Part E: application/pidf+xml      | | |
       | | +-----------------------------------+ | |
       | | | Part F: application/pidf+xml      | | |
       | | +-----------------------------------+ | |
       | |                                       | |
       | +---------------------------------------+ |
       | | Part C: application/pidf+xml          | |
       | +---------------------------------------+ |
       |                                           |
       +-------------------------------------------+

Regards,

EricT
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Thu, 6 Nov 2008 10:51:41 -0000

I agree with your interpretation that the fullState attribute only
applies to the direct RLMI, not to any embedded RLMI relating to any
sub-lists.
 
However per 5.2, in the scenario where this matters most (first NOTIFY),
I interpret the following statement as meaning that all embedded lists
must also provide fullState:
The
   first NOTIFY sent in a subscription MUST contain full state, as must
   the first NOTIFY sent after receipt of a SUBSCRIBE request for the
   subscription.
This rule and interpretation provide the necessary capability and
flexibility.
 
I think the following statement in the RFC is confusing as it refers to
the NOTIFY and not to the list:
The "fullState"
   attribute indicates whether the NOTIFY message contains information
   for every resource in the list.
A future revision of this RFC should replace "the NOTIFY" with "the
list".
 
All the best,
Colm Smyth

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Tremblay
Sent: 05 November 2008 19:24
To: [email-masked]
Subject: [Simple] RFC 4662 Clarification

Hi,

I would like to clarify the meaning of the "fullstate" attribute in RFC
4662 when it is set to true.

4662 specifies that when fullstate is set to true, all "state" must be
removed and rebuilt from the information available in the RLMI. Unless I
am confused by "state" (I assume the state being transported by the
RLMI, PIDF as an example, as well as the RLMI list of resources), this
only then works if full state information is transmitted instead of
partial state info. The misleading part comes in section 4.6, where it
is stated that if full state is specified, it applies only to the RLMI
document in which it occurs. I would have expected this to trickle down
to "embedded" RLMI as well as any other type of payload. Now because
RLMI with fullstate is allowed to transport "partial" RLMI, I am
wondering if my understanding about the other type of payloads is right.

As an example, if we take the figure on page 16 (copied for your
convenience), I would have expected Part D (and Part C, E and F) to
contain full state information if Part A specified full state
information.

Regards,

EricT

---

From: "Jeff King" <[email-masked]>
Date: Mon, 24 Nov 2008 19:21:23 -0700