[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] RFC 4662 Clarification
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
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
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple