RE: proposal for 7478

I think the features offered by this kind of approach can work - however 
the syntax worries me a little.  From a new reader's perspective, IMO, 
when someone sees:
        <expires> 5hrs </expires>
the default they will expect will be "exactly 5 hrs".  Having the default 
be a "hint" is not something I think newies will think of and therefore 
will cause confusion.  So what about this:
·       No expiry ? <Expires> wse:infinite </Expires>   (or no Expires 
element could work too)
·       Exact ? <Expires> 5hrs </Expires>
·       Range ? <Expires @min=3hrs @max=7hrs> 5hrs </Expires>
·       Hint ? <Expires @min=0hrs @max=wse:infinite> 5hrs </Expires>

Basically, w/o any attributes the value specified is 'exact'.  Once an 
attribute is present it turns the value into a hint.  I think this has the 
exact same semantics but leaves the simple case simple.  It also makes it 
very clear when people want the less precise notion of a 'hint' or 'range' 
and didn't ask for it by accident.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
10/01/2009 06:26 PM

To
Gilbert Pilz <gilbert.pilz@oracle.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: proposal for 7478






Hi Gil, 
 
Here are my detailed comments on this (
http://www.w3.org/Bugs/Public/attachment.cgi?id=760) proposal. This does 
not adequately address the use case I have in mind. The reason is because 
this proposal does not allow the event source to grant an expiry time that 
is larger than the requested time. 
 
Let me explain my use case. The event subscriber asks for a certain 
expiration time and the event source grants either the exact time or some 
time close enough (either smaller or larger time). For example, the 
service may choose to reap subscriptions at specific periodic intervals. 
Assuming that an event subscriber allows for flexibility, meaning, it is 
willing to accept a range of values that are smaller or larger than what 
has been requested, the event source may pick a time (that is either 
smaller or larger than the requested time but close enough) that better 
suits its internal processing. 
 
I think it is possible to amend Gil?s proposal to address my use case. 
Using @min and @max attributes on the Expires element would solve the 
problem. The @min and @max attributes offers a sliding scale to specify a 
time window for the requested expiration time. If the event source cannot 
grant an expiration time within the time window it MUST fault. The default 
value for @min attribute is zero and the @max attribute is indefinite (no 
expiry). This allows an event subscriber to specify a range around the 
requested expiry time. If the attributes are not specified, the range 
extends from zero to infinite time.
 
This amendment supports all the following requirements:
·       No expiry ? <Expires @min=wse:infinite> wse:infinite </Expires>
·       Exact ? <Expires @min=5hrs @max=5hrs> 5hrs </Expires>
·       Range ? <Expires @min=3hrs @max=7hrs> 5hrs </Expires>
·       Hint ? <Expires> 5hrs </Expires>
 
Hi Dave. I suggest considering my amendments [1] to Gil?s proposal as you 
put together a modified proposal.
 
Thank you.
 
[1] Proposed amendments
 
[Body] /wse:Subscribe/wse:Expires
 
This optional element can be used by the Subscriber to negotiate the 
expiration time of the requested Subscription. The value of this element 
indicates the desired expiration time for the subscription. If the event 
source is not able to  grant an expiry time within the specified range 
(denoted by the @min and @max attributes), it MUST generate a 
wse:ExpirationTimeExceeded fault. If this element does not appear, then 
the request is for a subscription that will not expire.
 
[Body] /wse:Subscribe/wse:Expires@min
 
The implied default is zero. This specifies the minimum expiration time 
that the event subscriber is willing to accept.
 
[Body] /wse:Subscribe/wse:Expires@max
 
The implied default is infinite (no expiry). This specifies the maximum 
expiration time that the event subscriber is willing to accept.
 
A Subscriber MAY indicate that it is willing to accept a Subscription with 
any
expiration time by omitting this element from the Subscribe request.
A Subscriber MAY request a Subscription with a specific expiration time by
including this element in the Subscribe request. If the Event Source 
creates a
Subscription from such a Subscribe request, the expiration time of the 
Subscription
MUST be equal to time indicated by the value of this element, or the 
Subscription
MUST NOT expire. The Subscriber MAY modify its request for a specific 
expiration
time via the inclusion of the optional wse:Minimum attribute. The presence 
of the
wse:Minimum attribute indicates that the Subscriber is willing to accept a
expiration time that is less than the value of the Expires element, but 
that this
expiration time must not be less than the value of the wse:Minimum 
attribute. If
the Event Source does not honor the requested expiration time, the request 
MUST
fail, and the Event Source MUST generate a wse:ExpirationTimeExceeded
fault.
A Subscriber MAY request a Subscription that never expires by including 
this
element with an xs:duration value of wse:infinite zero ("P0Y0M0DT0H0M0S"). 
If the Event
Source creates a Subscription from such a Subscribe request, the 
Subscription
MUST NOT expire. If the Event Source does not honor a request for a 
Subscription
that does not expire, the request MUST fail, and the Event Source MUST 
generate
a wse:ExpirationTimeExceeded fault.
 
  <xs:simpleType name="NonNegativeDurationType">
    <xs:restriction base="xs:duration">
      <xs:minInclusive value="P0Y0M0DT0H0M0S" />
    </xs:restriction>
  </xs:simpleType>
 
   <xs:simpleType name="Infinite">
    <xs:restriction base="xs:double">
      <xs:enumeration value=INF />
    </xs:restriction>
  </xs:simpleType>
 
  <xs:simpleType name="ExpirationType">
      <xs:union memberTypes="xs:dateTime 
                tns:NonNegativeDurationType tns:Infinite" />
  </xs:simpleType>
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Ram 
Jeyaraman
Sent: Wednesday, September 30, 2009 4:28 PM
To: Gilbert Pilz
Cc: public-ws-resource-access@w3.org
Subject: RE: proposal for 7478
 
Ø  <gp>I don't see how this is any different from simply requesting a 
Subscription with "whatever expiration" the Event Source sees free to 
assign. As a Subscriber I have no idea what sort of caching policies, 
resource limits, etc. the Event Source might be dealing with so why worry 
about providing a "hint" that the Event Source is under no obligation to 
pay any attention to? If you really want to code defensively, just ask for 
(via the absence of the Expiration element) and deal with whatever 
expiration the Event Source gives you.</gp>
 
Even if an event source cannot grant what is being asked, it may have 
range of possible expiry times it can grant. Knowing the preferences of 
the event subscriber helps the event source offer an expiry time that is 
close enough.
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert 
Pilz
Sent: Wednesday, September 30, 2009 3:25 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: proposal for 7478
 
Comments inline . . .

On 9/30/2009 2:44 PM, Ram Jeyaraman wrote: 
In general we notice that in such complex (unmanaged) environments, the 
event subscribers are coded defensively, since there are no guarantees. 
For example, a mobile client (laptop) moving from one location to another 
and attempting to connect to printers available in an office building. In 
such situations, event subscribers typically tend to use the least common 
denominator approach of requesting for a desired expiration time and yet 
be prepared to live with what is granted (assuming if it is reasonable of 
course). The event sources in such environments generally make a best 
attempt to grant the expiry time that is requested unless there are good 
enough reasons such as caching policies, running against resource limits, 
etc. In such situations, the event subscriber providing a desired expiry 
time is useful information for the event source to pick the best possible 
expiry time to offer the event subscriber. It is my opinion that the 
protocol should allow for that functionality.
<gp>I don't see how this is any different from simply requesting a 
Subscription with "whatever expiration" the Event Source sees free to 
assign. As a Subscriber I have no idea what sort of caching policies, 
resource limits, etc. the Event Source might be dealing with so why worry 
about providing a "hint" that the Event Source is under no obligation to 
pay any attention to? If you really want to code defensively, just ask for 
(via the absence of the Expiration element) and deal with whatever 
expiration the Event Source gives you.</gp>
In more controlled (managed) environments with better guarantees or 
pre-established policies, event subscribers may want to take advantage of 
that fact, and be configured to request for well-known minimum amount of 
expiry time. In the current model, the event subscriber does this by 
asking for a desired expiry time and the event source would likely grant 
the requested time since it?s behavior is predictable. In spite of the 
controlled environment, if it turns out that the event subscriber does not 
receive the requested minimum expiry time, it can unsubscribe.
<gp>"Likely to grant the requested time" doesn't cover the use case I am 
talking about. If the Subscriber/Event Sink were able to deal with 
"likely" expirations, it would just ask (again) for a Subscription with 
"whatever expiration" and deal with that. What is needed is a way to say 
"I need a Subscription with this specific expiration time and, if you 
can't give me that, I don't want the Subscription at all."</gp>
If the specification were to clarify that event sources must make a best 
attempt to grant the requested expiry time, would it work for you?
<gp>Absolutely not; "best attempt" is an untestable concept.</gp>
In spite of the suggested clarification above, if you still feel strongly 
about providing a mechanism to explicitly ask for a minimum expiry time as 
part the request, perhaps we can resolve this issue by using the approach 
suggested by Doug earlier. Here is a concrete version of that proposal 
[1]. That proposal [1] would address both the use cases (unmanaged and 
managed).
<gp>No disrespect intended, but Doug's proposal seems overly complicated 
to me. The whole "hint" thing seems particularly useless. As an 
Subscriber/Event Sink am I either capable of adjusting to the expiration 
that the Event Source assigned or I am not. If I am, it doesn't really 
make much difference, from a programming perspective, whether or not that 
expiration is or isn't "close" to my "hint".

If you really can't live with the idea of the Subscriber/Event Sink 
constraining the Subscribe request, perhaps we could simply remove the 
Expiration element from the Subscribe request and simply state that all 
Subscribers must simply deal with whatever the Event Source decides 
upon.</gp>

- gp
 
Thanks.
 
[1] Concrete version of earlier proposal from Doug
 
Introduce an attribute that indicates whether the specified expiry time is 
a hint or a minimum required time.
 
<Expires preference="http://www.w3.org/2009/02/ws-evt/expiry/AtLeast">
P1Y2M3DT10H30M12.3S</Expires> indicates that the specified expiry time 
must at least be granted.
 
<Expires preference="http://www.w3.org/2009/02/ws-evt/expiry/Hint">
P1Y2M3DT10H30M12.3S</Expires> indicates that the specified expiry time is 
a hint and the event source is free to provide more of, less of, or 
exactly the requested time. This is also the default value if the 
attribute is not specified. 
 
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, September 30, 2009 1:09 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: proposal for 7478
 
Such a constrained device probably wouldn't work correctly in a complex 
environment in which there was no expectation that any of the Event 
Sources of interest could support the desired expiration time, but that's 
not a valid constraint for this use case.

- gp

On 9/30/2009 12:10 PM, Ram Jeyaraman wrote: 
The use case for minimum expiry time's is an Event Sink on a constrained 
device that seeks to optimize the number of Subscriptions that it can 
support. If you imagine such an Event Sink attempting to support hundreds 
of Subscriptions it is clear that, if each Subscription requires the Sink 
to renew every 30 seconds, most of the device's bandwidth will be taken up 
in issuing and processing Renew/RenewResponse messages
 
What would such a constrained device do when it lives in a complex 
environment where there are no prior controls or knowledge of event 
sources in that environment? Specifically, what would it do when it does 
not find any event source that is willing to offer the requested expiry 
time? 
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Ram 
Jeyaraman
Sent: Wednesday, September 30, 2009 11:40 AM
To: Gilbert Pilz
Cc: public-ws-resource-access@w3.org
Subject: RE: proposal for 7478
 
<gp>This simply isn't true. A Subscriber can always choose to send a 
Subscribe message without an Expires element. To quote the proposal:
A Subscriber MAY indicate that it is willing to accept a Subscription with 
any expiration time by omitting this element from the Subscribe request.
</gp>
 
Indeed. I was incorrect in my characterization about the event subscriber 
being rigid in the newly proposed approach. Thanks for the correction.
 
However, unless I am misinterpreting the proposal ? it does NOT provide a 
way for the event subscriber to provide a hint to the event source about 
how much expiry time it desires. This is useful information that will help 
the event source decide on how much expiry time to grant. This is because 
the granted expiry time is a function of the requested time and what could 
be reasonably granted by the event source in real-time.
 
Thanks.
 
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, September 30, 2009 9:52 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: proposal for 7478
 
Comments inline . . .

On 9/30/2009 1:26 AM, Ram Jeyaraman wrote: 
Here are some pros and cons of the existing and newly suggested 
approaches.
 
Existing approach:
 
Pros
Allows for building event subscribers in a complex environment where the 
quality of service or capabilities of the event source are not known a 
priori. That is, the event subscriber is adaptive and can survive in 
complex environments where there is no control over or knowledge of what 
the event source can offer in real-time.
Cons
The event subscriber does not receive the requested expiry time and it 
cannot live with a shorter expiry time, it would need to unsubscribe. This 
is not a functional issue but incurs an extra message.
 
Newly suggested approach:
 
Cons
This does not adequately support the non-managed use case where the event 
subscriber does not know about the quality of service or capabilities of 
the event source a priori. This has the side-effect of creating event 
subscribers that are very rigid and demanding in their behavior.
<gp>This simply isn't true. A Subscriber can always choose to send a 
Subscribe message without an Expires element. To quote the proposal:
A Subscriber MAY indicate that it is willing to accept a Subscription with 
any expiration time by omitting this element from the Subscribe request.
</gp>
Pros 
The subscription request fails-fast, that is, it is rejected when the 
requested expiry time cannot be granted. This is an optimization. This 
means that the event subscriber need not have to unsubscribe if it decides 
not to keep the offered subscription with a less than requested expiry 
time.
 
Observations:
 
The proposed new approach while it optimizes for the case where the event 
subscriber does not want to keep a subscription with a 
lesser-than-requested expiry time, it takes away the adaptability of the 
event subscribers to complex environments.
<gp>In the proposal for 7478, the Subscriber is allowed three choices: (1) 
I don't care what the expiration is, (2) I would like a specific 
expiration period, (3) I would like a Subscription that never expires. 
Since this provides more flexibility than the Member Submission, I fail to 
see how this "takes away" adaptability.</gp>
 
Question:
 
It is not clear to me why an event subscriber must always want at least 
the minimum request expiry time to be granted. What is wrong with sending 
an unsubscribe if the granted expiry time is not sufficient or renewing to 
ask for more time? What is the need to require such exact expiry times?
<gp>Again, it's not true the Subscriber "must always want at at least the 
minimum request expiry time to be granted". The fact that you think this 
is the case leads me to believe that you really don't understand the 
proposal. The proposal allows the Subscriber to ask for a minimum request 
expiry time, but that is only one of the three options outlined above.

The use case for minimum expiry time's is an Event Sink on a constrained 
device that seeks to optimize the number of Subscriptions that it can 
support. If you imagine such an Event Sink attempting to support hundreds 
of Subscriptions it is clear that, if each Subscription requires the Sink 
to renew every 30 seconds, most of the device's bandwidth will be taken up 
in issuing and processing Renew/RenewResponse messages.</gp>
 
While I appreciate the thought and effort behind the proposed new 
approach, my preference is to retain the existing approach.
 
On the other hand, if there is a compelling use case for optimizing the 
protocol for the case where the event source does not want to keep a 
subscription with less-than-requested expiry time, I am willing to 
consider the approach that Doug suggested earlier:
 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0047.html 

 
2 - we need to make sure that the subscriber tells the source what it 
expects w.r.t. the new subscription.  This means that when it asks for an
expires time it needs to not only tell it the duration/dateTime, but it 
should also indicate whether this is an upper limit or a lower limit, or
even just a suggestion.  Perhaps a new attribute on the Expires element to 
indicate this would do it.  W/o this flag I don't think we can get the
level of interop we want by sticking with the current "random" expires 
time approach.
 
This allows the event subscriber to be adaptive while simultaneously 
providing the opportunity to fail-fast a subscription.
 
Thanks.
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Friday, September 11, 2009 7:09 PM
To: public-ws-resource-access@w3.org
Subject: proposal for 7478
 
Notes:

1.) We've removed the use of xs:dateTime for specifying expiration time. 
The reason for this is that the submission spec allowed Event Sources that 
didn't have a wall clock to fail on the use of xs:dateTime. This creates 
an interoperability problem because a Subscriber has no way of knowing 
whether or not an Event Source can or can't support xs:dateTime. An 
interoperable Subscriber must always be capable of falling back to the use 
of xs:duration, so we might as well just use that. Furthermore, some 
members of the WG have indicated that they would prefer xs:duration over 
xs:dateTime because the former was simpler to deal with (one example cited 
the problems of xs:dateTime's that lack any timezone designation, etc.) 
This simplifies the parsing for wse:Expires since it is now just a 
restriction of a xs:duration and no longer a xs:union. The 
InvalidExpirationTime fault is no longer necessary and has been removed.

2.) The existing text for /wse:SubscribeResponse/wse:Expires implies that 
this element is optional ("if this element does not appear") whereas the 
schema indicated that this element is mandatory. This proposal changes the 
schema to indicate that Expires is an optional element for 
SubscribeResponse.

3.) The presence/absence of wse:Expires has a different meaning for 
wse:Subscribe then in does for wse:SubscribeResponse. For wse:Subscribe it 
means "I don't care what expiration value you give me". For 
wse:SubscribeResponse it means "the newly created Subscription does not 
expire". Although this may seem little weird at first, it is consistent 
with the negotiation model.

4.) This proposal includes the appropriate changes to Renew, 
RenewResponse, GetStatusResponse as well as changes to examples.

- gp

Change the outline of Subscribe to the following:

[Action]
  http://www.w3.org/2009/02/ws-evt/Subscribe

[Body]
  <wse:Subscribe ...>
    <wse:EndTo> endpoint-reference </wse:EndTo> ?
    <wse:Delivery ...> xs:any* </wse:Delivery>
    <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
    <wse:Expires> xs:duration </wse:Expires> ?
    <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
    xs:any*
  </wse:Subscribe>

Change the description of /wse:Subscribe/wse:Expires to the following:

[Body]/wse:Subscribe/wse:Expires
This optional element can be used by the Subscriber to negotiate the 
expiration time of the requested Subscription.

A Subscriber MAY indicate that it is willing to accept a Subscription with 
any expiration time by omitting this element from the Subscribe request.

A Subscriber MAY request a Subscription with a minimum expiration time by 
including this element in the Subscribe request with a positive 
xs:duration value that specifies the minimum time between the 
Subscription's creation time (based on the Event Source's clock) and the 
time of its expiration. If the Event Source creates a Subscription from 
such a Subscribe request, the expiration time of the Subscription MUST be 
equal to or greater than the time indicated by the value of this element, 
or the Subscription MUST NOT expire. If the Event Source does not honor 
the requested minimum expiration time, the request MUST fail, and the 
Event Source MUST generate a wse:ExpirationTimeExceeded fault.

A Subscriber MAY request a Subscription that never expires by including 
this element with an xs:duration value of zero ("P0Y0M0DT0H0M0S"). If the 
Event Source creates a Subscription from such a Subscribe request, the 
Subscription MUST NOT expire. If the Event Source does not honor a request 
for a Subscription that does not expire, the request MUST fail, and the 
Event Source MUST generate a wse:ExpirationTimeExceeded fault.

Change the outline of SubscribeResponse to the following:

[Action]
  http://www.w3.org/2009/02/ws-evt/SubscribeResponse

[Body]
  <wse:SubscribeResponse ...>
    <wse:SubscriptionManager>
      wsa:EndpointReferenceType
    </wse:SubscriptionManager>
    <wse:Expires> xs:duration </wse:Expires> ?
    xs:any*
  </wse:SubscribeResponse>

Change the description of /wse:SubscribeResponse/wse:Expires to the 
following:

[Body]/wse:SubscribeResponse/wse:Expires
This optional element is used to communicate the assigned expiration time 
of the newly created Subscription. The absence of this element in a 
SubscribeResponse indicates that the Subscription will not expire; i.e. 
the Subscription has an indefinite lifetime.

If the Subscribe request did not contain a wse:Expires element and this 
element occurs in the SubscribeResponse, it MUST have a positive 
xs:duration value.

If the Subscribe request contained a wse:Expires element with a positive 
xs:duration value and this element occurs in the SubscribeResponse, it 
MUST have a xs:duration value that is equal to or greater than the request 
value.

If the Subscribe request contained a wse:Expires element wtih the a zero 
value ("P0Y0M0DT0H0M0S"), this element MUST NOT appear in the 
SubscribeResponse.

Note that, regardless of its expiration time, a Subscription MAY be 
terminated by the Event Source at any time for reasons such as resource 
constraints, or system shut-down.

Fix Example 4-1 and Example 4-2 to use an xs:duration value for their 
respective wse:Expires elements making sure that the above restrictions 
are adhered to.

Change the outline of Renew to the following:

[Action]
  http://www.w3.org/2009/02/ws-evt/Renew

[Body]
  <wse:Renew ...>
    <wse:Expires> xs:duration </wse:Expires> ?
    xs:any*
  </wse:Renew>

Change the outline of RenewResponse to the following:

[Action]
  http://www.w3.org/2009/02/ws-evt/RenewResponse

[Body]
  <wse:RenewResponse ...>
    <wse:Expires> xs:duration </wse:Expires> ?
    xs:any*
  </wse:RenewResponse>

Change the description of /wse:RenewResponse/wse:Expires to the following:
This optional element is used to communicate the assigned expiration time 
of the newly renewed Subscription. The start of this duration is the time 
when the Subscription Manager started processing the Renew request.

Fix Example 4-3 and Example 4-4 to use an xs:duration value for their 
respective wse:Expires elements.

Change the outline of GetStatusResponse to the following:
[Action]
  http://www.w3.org/2009/02/ws-evt/GetStatusResponse

[Body]
  <wse:GetStatusResponse ...>
    <wse:Expires> xs:duration </wse:Expires> ?
    xs:any*
  </wse:GetStatusResponse>

Fix Example 4-6 to use an xs:duration value for the wse:Expires element. 

Change the schema definition of the "ExpirationType" to the following:

  <xs:simpleType name="ExpirationType">
    <xs:restriction base="xs:duration">
      <xs:minInclusive value="P0Y0M0DT0H0M0S" />
    </xs:restriction>
  </xs:simpleType>

Change the definition of SubscribeResponse to:

  <xs:element name="SubscribeResponse">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="SubscriptionManager" 
                    type="wsa:EndpointReferenceType" />
        <xs:element name="Expires"
                    type="tns:ExpirationType" 
                    minOccurs="0" />
        <xs:any namespace="##other" processContents="lax" 
                minOccurs="0" maxOccurs="unbounded" />
      </xs:sequence>
      <xs:anyAttribute namespace="##other" processContents="lax" />
    </xs:complexType>
  </xs:element>

Add the following fault to Section 6:

6.x ExpirationTimeExceeded

This fault is generated when a Subscribe request specifies a minimum 
expiration time that exceeds what the Event Source is willing to support. 
This includes requests that use a zero xs:duration value to specify an 
infinite expiration time.

[Code]
s12:Sender
[Subcode]
wse:ExpirationTimeExceeded
[Reason]
The requested expiration time exceeds internal limits
[Code]
Optional xs:duration which specified the maximum expiration time supported 
by the Event Source.
 

Remove Section 6.2 "InvalidExpirationTime".

Remove Section 6.3 "UnsupportedExpirationType".