Subject: RE: [rohc] Local state advertisements and the implementer's guide

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 12 Sep 2006 16:45:24 +0100

Hi All,

I haven't had any response to this so far.  I'm out of the office for
the rest of the week but it would be really good if there were some
responses to come back to on Monday ;-) 

Best regards,

Abbie 

> -----Original Message-----
> From: Surtees, Abigail [mailto:[email-masked]] 
> Sent: 30 August 2006 16:12
> To: [email-masked]
> Subject: [rohc] Local state advertisements and the implementer's guide
> 
> Hi All,
> 
> Back in February and March we were having a discussion about 
> locally available state items and the semantics of their 
> advertisement.
> 
> We didn't conclude the discussion for the last version of the 
> implementer's guide so I included an editor's note.  The 
> discussion seems to have stalled at that point, so here's 
> where I think we are, and a proposal for how to progress.
> 
> (The previous email thread starts with the third part of this 
> email 
> <http://www1.ietf.org/mail-archive/web/rohc/current/msg04146.h
> tml> and continues till Fri 3rd March and the resulting ID is here
> <http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-i
> mpl-guide-
> 06.txt> (section 10.3).)
> 
> 1) The definition of advertisement of locally available state 
> (such as dictionaries and well-known pieces of bytecode) is 
> relatively clear in RFC 3320.  The assumptions are that:
> 
>   a) such state is local to the endpoint and will not be 
> deleted (ignoring I-bit, see below)
> 
>   b) such state does NOT count towards the SMS of a compartment
> 
> [as an implementation choice, locally available states may be 
> mapped onto compartments, but this must not affect (a) and 
> (b), above.]
> 
> 2) Section 6.2 of RFC 3320 discusses mapping locally 
> available state to a compartment.  I believe that this 
> concept (as specified in RFC 3320
> only) is not well-defined (e.g. does it count towards SMS, if 
> so, how does the I-bit work? If not, why define the use of 
> minimum retention
> priority?)  
> 
> Can anyone (authors?) explain to me the intention of this for 
> a basic (RFC 3320) implementation?
> 
> If not, then I suggest that the clarification for the 
> implementer's guide is that the concept of mapping locally 
> available state to a compartment can only be considered as an 
> implementation choice and one that cannot interfere with the 
> statements in (1), above.
> 
> A locally available state item that is advertised can be 
> assumed to be available for the lifetime of the compartment.
> 
> 3) If the advertised state is to be used in any other way, 
> then its use and semantics (including the concept of mapping 
> state to a compartment) must be fully and completely specified.
> 
> There are currently three uses (or proposed uses) of state
> advertisements:
> 
> (a) Shared-mode (defined in Section 5.2 in RFC 3321) -
> 
> I believe that shared-mode (as clarified by section 5.3 of 
> the implementer's guide) is well-defined, covering 
> state-creation, priority, state-advertisement and deletion 
> rules within a specified compartment mapping.
> 
> (b) Endpoint-initiated acks (defined in Section 5.1.2 in RFC 3321) -
> 
> Endpoint B advertises the hash of a state item that Endpoint 
> A has requested B to create (within a compartment).  Given 
> these discussions, this does not seem to be a well-defined 
> concept.  There are various possible interpretations at 
> Endpoint A on receipt of the advertisement from B:
> 
>    i) ignore it because the hash doesn't match any locally 
> available state known by the 
>       endpoint (basic 3320);
> 
>   ii) as an 'ack', it simply means that B has successfully 
> created the state
>      (this is a stronger statement than receipt of requested 
> feedback, which means only 
>       that the message was successfully decompressed);
> 
>   iii) Endpoint B already has a piece of locally available 
> state with this hash, so
>       creation has failed (not useful);
> 
>   iv) Endpoint B is treating the state in a manner similar to 
> a piece of locally 
>       available state (i.e. increasing its lifetime)
>        (whether the state still counts towards SMS at this 
> point is unclear).
> 
> (c) State lifetime extension (beyond compartment lifetime) 
>     (from section 6.2 of
> <http://tools.ietf.org/wg/rohc/draft-ietf-rohc-sigcomp-sip/dra
> ft-ietf-ro
> hc-sigcomp-sip-02.txt>) -
> 
> This is similar to endpoint initiated acks but this document 
> specifies that advertisements mean that the endpoint will 
> keep the state for an unspecified amount of time beyond the 
> closure of the compartment.
> 
> Since this clearly overlaps with (b), I believe this concept 
> is also NOT well defined.
> 
> 
> My proposal for the implementer's guide is to clarify that:
> 
> *) For 'basic' RFC 3320 implementations locally available state is
>    - not mapped to compartments
>    - is local to the endpoint and persists for the duration 
> of the compartment
>    - does not impact compartment SMS
> 
> *) SigComp 'extended' mechanisms may use state advertisements 
> provided that their use
>    is clearly defined and does not conflict with any other usage
> 
>    - shared-mode is one such well-defined usage
>      (although its definition in a non-standards-track 
> document is still rather odd!)
> 
>    - endpoint initiated acknowledgements should be further clarified.
> 
> The suggested clarification for the advertisement semantics 
> with respect to endpoint-initiated acks is as follows (this 
> merges interpretations
> ii) and iv); interpretation i) must always be valid):
> 
> "Where Endpoint A requests state creation at Endpoint B, 
> Endpoint B may subsequently advertise the hash of the created 
> state item to Endpoint A.
> This conveys to Endpoint A (i) that the state has been 
> successfully created within the compartment; and (ii) that 
> the state will be available for *at least* the lifetime of 
> the state as defined by RFC 3320.  If the state is available 
> at Endpoint B after it would be deleted from the compartment 
> according to RFC 3320, then the state no longer counts 
> towards the SMS of the compartment.  Since there is no 
> guarantee of such state being available beyond its normally 
> defined lifetime, endpoints should only attempt to access the 
> state where NACK is available."
> 
> This seems to allow for all currently proposed behaviours and 
> does not conflict with the basic RFC 3320 definition.
> 
> Finally, if this clarification is made in the implementer's 
> guide, then it is only addressing general SigComp behaviour.  
> If a stronger promise of keeping state is wanted (e.g. beyond 
> the end of the compartment) then this can be specified in 
> 'Sigcomp for SIP' or other equivalent documents in the same 
> way as the minimum DMS or support of a dictionary is specified.
> 
> What do you think?  
> 
> Best regards,
> 
> Abbie
> 
> --
> Abbie Surtees
> Consultant Engineer
> Roke Manor Research Ltd
> +44 1794 833131
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Richard Price" <[email-masked]>
Date: Mon, 18 Sep 2006 16:03:34 +0100

> 2) Section 6.2 of RFC 3320 discusses mapping locally available state to
> a compartment.  I believe that this concept (as specified in RFC 3320
> only) is not well-defined (e.g. does it count towards SMS, if so, how
> does the I-bit work? If not, why define the use of minimum retention
> priority?)  

If locally available state is defined as being mapped to a compartment,
then it does indeed count towards the SMS of the compartment. I believe
that this is clear from point 5.) of Section 6.2 - as you noted, the
state could not have a minimum retention priority otherwise.

I don't see how Section 6.2 contradicts the definition of the I-bit,
could you expand on this one?

> Can anyone (authors?) explain to me the intention of this for a basic
> (RFC 3320) implementation?

The reason for providing this mechanism is purely to give implementers
of shared mode the ability to optimise their memory usage, by allowing
them to store their locally available state items in the same memory
as is reserved for the compartment. If we did not have this mechanism
then implementers of shared mode would need to store their locally
available state items in separate memory, which could potentially be
very inefficient as the total size of the locally available state items
created by shared mode is equal to the uncompressed size of all
messages transmitted in one direction.

For a basic implementation of RFC3320 (not implementing shared mode),
there is no impact save for the fact that the special state retention
priority of 65535 is reserved and causes a decompression failure if
the bytecode tries to use it.

> If not, then I suggest that the clarification for the implementer's
> guide is that the concept of mapping locally available state to a
> compartment can only be considered as an implementation choice and one
> that cannot interfere with the statements in (1), above.

The only support required in RFC3320 is the special state retention
priority.

> A locally available state item that is advertised can be assumed to be
> available for the lifetime of the compartment.

Yes, given the caveat that if it is defined to be mapped to a compartment
as in shared mode, then it can be pushed out of the compartment's
memory by other states.

> Endpoint B advertises the hash of a state item that Endpoint A has
> requested B to create (within a compartment).  Given these discussions,
> this does not seem to be a well-defined concept.  There are various
> possible interpretations at Endpoint A on receipt of the advertisement
> from B:

Once a state has been advertised to the compressor in a compartment,
it must remain available to the compressor until the compartment
closes or one of the following occurs:

i) The state item is pushed out of the compartment's memory by other
state items.

ii) The compressor uses the I-bit to indicate that it no longer wants
the state.

RFC3321 should not contradict this! In particular, just advertising
a state should not increase its lifetime, unless this is standardised
somehow (e.g. in the SigComp/SIP draft).

> <http://tools.ietf.org/wg/rohc/draft-ietf-rohc-sigcomp-sip/draft-ietf-ro
> This is similar to endpoint initiated acks but this document specifies
> that advertisements mean that the endpoint will keep the state for an
> unspecified amount of time beyond the closure of the compartment.
> 
> Since this clearly overlaps with (b), I believe this concept is also NOT
> well defined.

Indeed it isn't - more needs to be said on the lifetime of the
state if it is greater than that of a compartment, or the relevant
paragraph should be deleted.

>    - is local to the endpoint and persists for the duration of the
> compartment

Ok with the caveat that in order to support shared mode, the special
state retention priority of 65535 must still be reserved by
"basic" RFC3320 implementations, even if they happen to not
create any locally available state that is mapped to a compartment.

> *) SigComp 'extended' mechanisms may use state advertisements provided
> that their use
>      (although its definition in a non-standards-track document is still
> rather odd!)

The IETF provides "hooks" in RFC3320 to allow implementations to
support shared mode, but does not standardise shared mode itself.

> The suggested clarification for the advertisement semantics with respect
> to endpoint-initiated acks is as follows (this merges interpretations
> "Where Endpoint A requests state creation at Endpoint B, Endpoint B may
> subsequently advertise the hash of the created state item to Endpoint A.
> This conveys to Endpoint A (i) that the state has been successfully
> created within the compartment; and (ii) that the state will be
> available for *at least* the lifetime of the state as defined by RFC
> 3320.  If the state is available at Endpoint B after it would be deleted
> from the compartment according to RFC 3320, then the state no longer
> counts towards the SMS of the compartment.  Since there is no guarantee
> of such state being available beyond its normally defined lifetime,
> endpoints should only attempt to access the state where NACK is
> available."
> 
> This seems to allow for all currently proposed behaviours and does not
> conflict with the basic RFC 3320 definition.

Sounds good.

> Finally, if this clarification is made in the implementer's guide, then
> it is only addressing general SigComp behaviour.  If a stronger promise
> of keeping state is wanted (e.g. beyond the end of the compartment) then
> this can be specified in 'Sigcomp for SIP' or other equivalent documents
> in the same way as the minimum DMS or support of a dictionary is
> specified.
> 
> What do you think?  

All fine, with the caveat that the special state retention priority
of 65535 is still special in RFC3320.

Cheers,

Richard

---

From: "Richard Price" <[email-masked]>
Date: Mon, 18 Sep 2006 16:05:28 +0100

> I agree with this. Though I see it as a correction rather than a
> clarification. The concept of mapping locally available state items to a
> compartment is to my mind a mistake by the authors of RFC3320, a
> confusion of a possible private implementation strategies with
> definitions of externally visible behaviours.

It would certainly be nice if the storage of all locally available state
could be considered an implementation issue at the decompressor. In fact
this was exactly how early versions of RFC3320 were intended to work.

However, an objection was raised that memory-intensive mechanisms such as
shared mode would be throwing away a large amount of memory advertising
states that the remote endpoint might not even want to use. In response,
we added to RFC3320 a mechanism for storing locally available state inside
the UDVM's own per-compartment memory. This allowed implementations to
use mechanisms like shared mode without worrying about wasting memory
unnecessarily.

I don't think we can put the above into the implementer's guide as a
"clarification", as it would be a technical change to RFC3320 to delete
the ability to use the per-compartment memory to store locally available
states. But nothing stops us from getting rid of this mechanism in the
next version of RFC3320 if it is determined that implementers do not
wish to make use of it.

> Going a bit off topic here, I'd just add that the authors of such
> documents should not only specify requirements as to state items which
> must mandatorily be made available for specific environments, but should
> also make it clear whether or not those state items need to be
> advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must
> always be available but it isn't stated whether or not it also needs to
> be advertised or whether its presence should just be assumed.

If an item of state is mandatory in a particular environment, its
presence can by definition be assumed by the compressor. So there's
no need to advertise the state - you can advertise it anyway but I
can't see any benefit to doing this.

Cheers,

Richard

---

From: "Richard Price" <[email-masked]>
Date: Mon, 18 Sep 2006 16:03:34 +0100

Sounds good.

Cheers,

Richard

---

From: "John Barber" <[email-masked]>
Date: Thu, 14 Sep 2006 18:19:42 +0100

Hi,

> state where NACK is available."

I'm happy with all of this.

Regards, John

---

From: "John Barber" <[email-masked]>
Date: Tue, 19 Sep 2006 11:06:20 +0100

> From: Richard Price [mailto:[email-masked]] 
> Sent: 19 September 2006 10:01
> To: John Barber; Surtees, Abigail; [email-masked]
> Cc: Lajos Zaccomer (IJ/ETH); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Local state advertisements and the implementer's guide
> 
> >> It would certainly be nice if the storage of all locally available 
> >> state could be considered an implementation issue at the 
> >> decompressor. In fact this was exactly how early versions 
> of RFC3320 
> >> were intended to work.
> >> 
> >> However, an objection was raised that memory-intensive mechanisms 
> >> such as shared mode would be throwing away a large amount 
> of memory 
> >> advertising states that the remote endpoint might not even want to 
> >> use. In response, we added to RFC3320 a mechanism for 
> storing locally 
> >> available state inside the UDVM's own per-compartment memory. This 
> >> allowed implementations to use mechanisms like shared mode without 
> >> worrying about wasting memory unnecessarily.
> 
> > I think this is unneccessary. An implementation would (even in the 
> > absence of such a mechanism) be free to use spare per-compartment 
> > memory for any purpose it sees fit, including shared-mode 
> state items, 
> > so long as it makes this usage transparent to the other end 
> of the conversation.
> > Just because (for example) a SIGCOMP endpoint advertises 8K 
> of SMS it 
> > does not necessarily mean that it needs to allocate 8K of memory 
> > permanently for each compartment and dedicate it exclusively to 
> > storing state items at the request of the remote. I would in fact 
> > guess that most implementations will choose to use a "new" 
> or "malloc" 
> > for each state item and manage the SMS limits by summing 
> their sizes.
> 
> The problem with this approach is that once a locally 
> available state item is offered, in general it must remain 
> available for the duration of the compartment. This is fine 
> for items like the static dictionary, which are shared 
> between many compartments, but in the case of shared mode 
> there is a large amount of per-compartment state that might 
> end up just lying around in the memory. We need a method for 
> bounding the total per-compartment memory that the 
> decompressor must make available, otherwise it will end up 
> needing to store the full 8K SMS, plus all of the shared mode 
> states as well (which could easily dwarf the 8K SMS if left 
> unbounded).
>
OK. I think you've just explained the true purpose of the distinction
between per-compartment mapping and non-per-compartment mapping of state
items. It's a distinction in the lifetime for which the state item is
guaranteed to remain available and hence is indeed a part of the
contract between the endpoints and not just an implementation detail.

Unfortunately, this is not actually stated in the SIGCOMP RFC:

1) You state that a locally available state item must in general remain
available for the duration of the compartment. I don't think the RFC
actually states this. It could equally be assumed that locally available
state items are permanently available, even surviving the closing of the
compartment  (greater persistence than stated by you) or that they are
available only for the current message (less persistence than stated by
you.)

2) The SIGCOMP RFC itself does not provide a means for an endpoint to
know which lifetime applies to any given locally available state item
advertised by the remote. This makes it essential for the whichever
document specifies the usage of the locally available state item to
state which type of mapping must be used. I believe this is well-defined
for shared mode operation in RFC3321. But the SIP/SIGCOMP document for
example needs to explicitly state that the SIP/SIGCOMP static dictionary
must be mapped on a non-per-compartment basis and therefore not risk
being pushed out of state memory by state items created at the request
of the UDVM code running in the decompressor.

This area has caused considerable confusion in interpretation. See for
example the following thread:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04176.html
  
> > I agree with this interpretation but would like to see it made 
> > explicit in the relevant documents since I believe the contrary 
> > interpretation is also possible and this could cause 
> difficulties in interoperability.
> 
> I don't see any problems with this - it costs nothing to 
> clarify that a particular locally available state item is 
> mandatory and therefore does not need to be advertised.
> 
> Cheers,
> 
> Richard
>

---

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 19 Sep 2006 17:07:22 +0100

Hi Richard,

Thanks for your response.  I've replied to your orignal response, and
probably won't reply directly to your exchange with John, but some of
the information in it has been useful in writing this reply :-)
 
> Sent: 18 September 2006 16:04
> available state 
> > to a compartment.  I believe that this concept (as specified in RFC 
> > 3320
> If locally available state is defined as being mapped to a 
> compartment, then it does indeed count towards the SMS of the 
> compartment. I believe that this is clear from point 5.) of 
> Section 6.2 - as you noted, the state could not have a 
> minimum retention priority otherwise.
> 
> I don't see how Section 6.2 contradicts the definition of the 
> I-bit, could you expand on this one?
> 
If you map state to the compartment, then it follows the normal deletion
rules (according to SMS).  In which case surely it should only be
deleted according to those rules, so what does receiving the I-bit set
mean/do?

I guess, given a state model with Malloc as mentioned by John, you could
delete the state and reclaim the memory if you received the I-bit set,
but then you have two ways of deleting state which seems a bit dangerous
to me.

> The reason for providing this mechanism is purely to give 
> implementers of shared mode the ability to optimise their 
> memory usage, by allowing them to store their locally 
> available state items in the same memory as is reserved for 
> the compartment. If we did not have this mechanism then 
> implementers of shared mode would need to store their locally 
> available state items in separate memory, which could 
> potentially be very inefficient as the total size of the 
> locally available state items created by shared mode is equal 
> to the uncompressed size of all messages transmitted in one direction.
> 
OK.

> For a basic implementation of RFC3320 (not implementing 
> shared mode), there is no impact save for the fact that the 
> special state retention priority of 65535 is reserved and 
> causes a decompression failure if the bytecode tries to use it.
> 
Almost (see below), but I agree that whatever you do, as a UDVM and as a
compressor creating state you have to obey the rules of minimum
retention priority.

> assumed to be 
> Yes, given the caveat that if it is defined to be mapped to a 
> compartment as in shared mode, then it can be pushed out of 
> the compartment's memory by other states.
> 
But how does a base 3320 implementation receiving an advertisement know
whether it's a piece of state that is available for the lifetime of a
compartment or for less than that (as in shared mode).

Conduct a (albeit slightly warped) thought experiment - an
implementation receives an advert for state it knows nothing about and
decides to find out what's in it, by requesting it in 128 byte chunks as
requested feedback.  The implementation knows the state is there
(because it was advertised), but actually has no knowledge of its
lifetime.

Based on the information in your email and your email exchange with
John, I think I would update my original proposal to be:

*) For 'basic' RFC 3320 implementations the lifetime of locally
available state is not defined; however, the implementation must take
account of the rules for use of minimum retention priority.  

*) If an implementation chooses to access a piece of state for which it
received an advertisement that it doesn't recognise (where recognition
can include determining that it's shared-mode state) must do so only
with extreme caution (or NACK).

*) Any use of locally available state must be clearly defined and not
conflict with any other usage.

*) The most basic use is the advertisement of a dictionary or piece of
bytecode.  These pieces of state are in general assumed to:
   - not be mapped to compartments
   - be local to the endpoint
   - persist for the duration of the compartment
   - not impact compartment SMS
However, for a given piece of state the exact lifetime must be defined
e.g. in public specifications such as SigComp for SIP or PoC to mandate
SIP/SDP static dictionary or in implementation/operator documentation
e.g. for advertisements of implementation/operator specific
dictionaries/bytecode.

   - shared-mode is one such well-defined usage (as defined in 3321 AND
section 5.3 in the implementer's guide)

The suggested clarification for the advertisement semantics with respect
to endpoint-initiated acks is as follows (this merges interpretations
ii) and iv) from
<http://www1.ietf.org/mail-archive/web/rohc/current/msg04424.html>;
interpretation i) must always be valid):

What do you think?  

It feels like we're getting closer.  If we can conclude this, then I'll
propose some text for the implementer's guide.

Best regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 20 Sep 2006 17:51:59 +0100

Hi Richard, 

> 
> Actually there are at least three - the compressor can also 
> use STATE-FREE to explicitly delete individual state items 
> that it no longer requires.
> 
> But remember that all of the lifetime control mechanisms 
> (I-bit, compartment SMS, STATE-FREE etc.) just serve to offer 
> hints to the decompressor that particular state items are no 
> longer required. How these states are removed from physical 
> memory is entirely up to the implementation.
> 
True. 

> > But how does a base 3320 implementation receiving an advertisement 
> > know whether it's a piece of state that is available for 
> the lifetime 
> > of a compartment or for less than that (as in shared mode).
> 
> It does not know, and nor should it care!

It does need to know if it wants to access the state.
> 
> Shared mode has been carefully designed so that the states 
> which it creates and saves have no impact on a compressor 
> that does not implement shared mode. If the compressor 
> receives advertisements for states that it doesn't recognise, 
> it just assumes that they are for an optional mechanism that 
> it doesn't support, and ignores the states completely.

Yes, that's the assumption, but there's nothing that explicitly states
that.
> > decides to find out what's in it, by requesting it in 128 
> byte chunks 
> > as requested feedback.  The implementation knows the state is there 
> Well, if the implementation wants to access a locally 
> available state it doesn't understand, then it is perfectly 
> able to do so. It will be rewarded with exactly what it 
> should expect - some bytes it doesn't understand.
> 
> If it tries to access a locally available state that no 
> longer exists, it will get a decompression failure - what 
> else could it expect?
> 
Indeed.  However, I think an explicit statement of this would be useful.

> Yes. But in fact, all a basic implementation needs to do is 
> to reserve the special state retention priority of 65535. If 
> it hasn't implemented shared mode then at the decompressor it 
> will never save any shared mode states so there is nothing 
> else to do, and at the compressor it just needs to ignore any 
> advertised shared mode states.

It needs to ignore advertised states that it doesn't recognise (because
it has no way of knowing whether they're shared mode or anything else!)
> 
> > *) If an implementation chooses to access a piece of state 
> for which 
> > it received an advertisement that it doesn't recognise (where 
> > recognition can include determining that it's shared-mode 
> state) must 
> > do so only with extreme caution (or NACK).
> 
> Or we could just tell implementers not to do this! Why would 
> they want to access states from mechanisms that they haven't 
> implemented?

I don't know (apart from my warped thought experiment of trying to find
out what's in the state to use it in future, but it is somewhat
cumbersome).
However, there's nothing in RFC 3320 that explicitly states that an
implementation shouldn't access state that has been advertised but about
which it know nothing.

> Yes.
> Yes. Note that if the state happens to be mandatory for all 
> endpoints, its lifetime is infinite and it does not need to 
> be advertised.

Agreed.
> > e.g. in public specifications such as SigComp for SIP or PoC to 
> > mandate SIP/SDP static dictionary or in implementation/operator 
> > documentation e.g. for advertisements of implementation/operator 
> > specific dictionaries/bytecode.
> 
> Yes.
> 
> Yes.
> >    - shared-mode is one such well-defined usage (as defined in 3321 
> > AND section 5.3 in the implementer's guide)
> 
> Yes.
> 
> > The suggested clarification for the advertisement semantics with 
> > respect to endpoint-initiated acks is as follows (this merges 
> > interpretations
> > ii) and iv) from
> > "Where Endpoint A requests state creation at Endpoint B, Endpoint B 
> > may subsequently advertise the hash of the created state 
> item to Endpoint A.
> > 3320.  If the state is available at Endpoint B after it would be 
> > deleted from the compartment according to RFC 3320, then 
> the state no 
> > longer counts towards the SMS of the compartment.  Since 
> there is no 
> > guarantee of such state being available beyond its normally defined 
> > lifetime, endpoints should only attempt to access the state 
> where NACK 
> > is available."
> 
> Yes. Endpoint initiated acknowledgements do not change the 
> lifetime of the state they advertise.

No, your sentence above contradicts the clarification.  An ack should
not be assumed to change the lifetime of the state item but this is not
precluded because it is a mechanism which is being considered for the
SigComp for SIP draft.  However, unless an implementation knows that the
extended lifetime is in use then it can only assume that the
advertisement is an ack that doesn't change the lifetime of the state
item.

> Looking good so far.
> > It feels like we're getting closer.  If we can conclude this, then 
> > I'll propose some text for the implementer's guide.
> 
> We'll also need to ensure that the upcoming SIP/SigComp draft 
> contains all of the required normative text regarding the 
> lifetime of the SIP- specific states (static dictionary!).
> 
And the lifetime extension use of the advertisement/endpoint initiated
ack (if the authors decide to use this mechanism).

Best regards,

Abbie