Code change:
strings beginning with the letter "Q".  Likewise, Inner Lists are only valid when a field definition explicitly allows them. <del> When parsing fails, the field is ignored (see text-parse); in most situations, violating field-specific constraints should have the same effect.  Thus, if a header is defined as an Item and required to be an Integer, but a String is received, it will by default be ignored. If the field requires different error handling, this should be explicitly specified. However, both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  As a result, field specifications are discouraged from defining the presence of an unrecognized Parameter as an error condition. To help assure that this extensibility is available in the future, </del> <ins> When parsing fails, the entire field is ignored (see text-parse); in most situations, violating field-specific constraints should have the same effect.  Thus, if a header is defined as an Item and required to be an Integer, but a String is received, the field will by default be ignored.  If the field requires different error handling, this should be explicitly specified. Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized Parameter as an error condition. To further assure that this extensibility is available in the future, </ins> and to encourage consumers to use a complete parser implementation, a field definition can specify that "grease" Parameters be added by <del> senders.  For example, a specification could stipulate that all Parameters beginning with the letter "h" are reserved for this use, and then encourage them to be sent on some portion of requests.  This helps to discourage recipients from writing a parser that does not account for Parameters. Note that a field definition cannot relax the requirements of this </del> <ins> senders.  A specification could stipulate that all Parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests.  This helps to discourage recipients from writing a parser that does not account for Parameters. Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of - as well as value and type associated with - unknown members be ignored.  Later specifications can then add additional members, specifying constraints on them as appropriate. An extension to a structured field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met. A field definition cannot relax the requirements of this </ins> specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings and

Related discussion:
text: Some of this is rewording. There are two new paragraphs talking about extensions: one deals with dictionaries, the other deals with extensions to a SH definition. I also removed the "starts with 'h'" example for greasing. We know that X- lead to all sorts of mess, so choosing a bad example here could be just as bad. I'm happy to split that out or be talked into backing it out, of course.