From: Mary Barnes [mailto:mary.ietf.bar...@gmail.com] Minor issues: 1. Last paragraph in 16.1: In cases where an entity that is compliant to this document, receives a request that contains hi-entries compliant only to RFC4244 (i.e, the hi-entries do not contain any of the new header field parameters), the entity should not make any changes to the hi-entries - i.e., the entries should be cached and forwarded as any other entries are. As with RFC4244 compliant entities, applications must be able to function in cases of missing information. The same applies to this document as specified in Section 11. I am a little confused by the language used here. It's OK if it is not capitalized if the functionality is described someplace else. However, why ' should not make any changes to the hi-entries' and ' the entries should be cached and forwarded '? Are there any exception cases that prevent writing just 'does not make any changes' and 'the entries are cached and forwarded'? [MB] The intent was to state that the entity MUST NOT add any of the new header parameter values to the hi-entry to make it look like a 4244bis hi-entry. But, rather the hi-entry is processed in the exact same manner as 4244bis compliant entries. I think we do need normative behavior as I don't think we have specified the behavior for this scenario elsewhere. [/MB] Also - I did not understand to what the last sentence refers (the same applies to this document...) [MB] It was trying to refer to section 11 which specifies that applications must be able to function in cases of missing information. Really, we could probably just delete that sentence and add the section 11 reference to the previous sentence. [/MB] [MB] Based on my comments above, I would propose the following rewording for that text: In cases where an entity that is compliant to this document, receives a request that contains hi-entries compliant only to RFC4244 (i.e, the hi-entries do not contain any of the new header field parameters), the entity MUST NOT add any of the new header field parameters to the hi-entries. The hi-entries MUST be cached and forwarded as any other entries are as specified in section 9.1. As with RFC4244 compliant entities, applications must be able to function in cases of missing information, as specified in Section 11. [/MB] [[DR]] This looks fine to me. Thanks for addressing the comment. Regards, Dan
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
